Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Re: Managed Build Process Environment and Build Paths proposal

Hi Lars,

 

Are you talking about Build Macros or the Build Process Environment Variables?

The build process environment design actually describes the capability of specifying the additional set environment variables to be used when launching the builder process (e.g. “make”) when building the project.

I suppose that there will be separate providers: one for providing the build environment variables and an other – for providing the Build Macros.

 

There will be the separate design for the build macros support. I’m going to post it at the beginning of the next week, or hopefully at the end of this week.

 

I will try to answer your questions with respect to both build macros and the builder process environment (please forgive me if I have got you wrong)

 

Here are some of the Build Macro design concepts that could be possibly interesting to you in the context of the Shared Tool Options (some of those concepts were already posted by Leo Treggiari in the previous mails to the cdt-dev list, let me just repeat them here)

 

  • Build macros will be able to be used in all options that accept text by enclosing the macro name in braces, preceded by a dollar sign. There will be a IBuildMacroProvider interface defined that will allow getting the list of macros and resolving the macro values used in the option value.
  • All option values will be displayed in the UI with macros unresolved (except the “All Options:” box that will contain the complete set of options passed to the tool with resolved macros)
  • Build Macros will be context-sensitive, that is the macro of a given name could have different values depending on where it is used.

Several types of context will be available:

    • The currently selected file.
    • The currently selected option
    • The currently selected configuration (which includes a tool-chain).
    • The currently selected project.
    • The current workspace.
    • The CDT and Eclipse installations.
    • The process environment variables defined in the environment passed to Eclipse.
  • There will be one or more supplier for each context, e.g.
    • User-defined macros supplier
    • Tool-integrator provided supplier
    • MBS-predefined macros supplier

 

 

Here are my answers/comments to your questions:

 

> The only area where there might be a problem are in the interfaces IConfigurationEnvironmentVariableSupplier and the IProjectEnvironmentVariableSupplier. They both return a set of IBuildEnvironmentVariable objects which appear to be a constant (name, value) tuple. In fact all dependencies with regards to build configuration and project have been moved to the build variable providers.

>
The Shared Tools Option proposal is basically providing the capability to link an MBS option to a class that implements IBuildEnvironmentVariable and provides extra capabilities, such as the capability to set the value.

This means that the value returned by IBuildEnvironmentVariable.getValue() essentially could change when the "Environments Variables" tab of the "C/C++ build property tab" looses focus. This means it would have to always re-read the values when it gets the focus, to ensure that correct values are displayed. So as long as  IBuildEnvironmentVariable objects are assumed NOT to be constant we should be fine.

Why do you need to directly reference the IBuildEnvironment variable interface in the option? I suppose that only the user-defined variables will be editable and that they should be edited using only one entry in the UI – in the “Build Environment” tab. The tool-integrator way for providing the build variables is through using the supplier. Do you mean that changing some option value may involve changing the variable value provided by the tool-integrator? In this case I suppose that each time before displaying the “Environent Variables” tab the Environment Variable Provider should be re-queried for the complete set of the environment variables, because the tool-integrator might not just change the value of some variable, but also add/remove some variables. But I’m not sure whether changing the option value should involve changing the variable values provided by the tool-integrator. What do you think?

 

I’ve got almost the same comment regarding the build macros: why do you need to directly access the interface representing some particular build macro. I suppose that all string-type options will contain the option values with build macros unresolved and will be displayed in the UI with macros unresolved also (build macros will be referenced in the strings using the syntax: ${macro_name}) and will be displayed in the UI with macros unresolved also. In case you would want to know the actual option value that will be passed to the tool during the build process you will be able to use the resolve* methods provided by the BuildMacroProvider.

 

> I have a further question, which is not answered by the proposal. Will build macros - either user defined or tool integrator defined - be emitted into the makefile that is generated by GnuMakefileGenerator? The answer seems to be no as the spec does not say anything, but I wanted to double-check.

The Build Macros Proposal will cover this. I suppose that all build macros will be expanded in the buildfile, except the macros representing the build process environment, user will have an option either to expand them or keep them in the buildfile.

We can not leave all macro references unresolved in the buildfile because:

a) macros are context-sensitive: there are file-specific, option-specific macros, etc.

b) macros can hold the list of values

Keeping the environment variable macro references unresolved will provide the most flexibility in case user wants to build the project outside of the MBS environment because the environment variable values are user-specific and user will be able to adjust the build process behavior by modifying environment and keeping the environment variable build macros references be synchronized with the current environment.

 

Thank you

Mikhail

 


From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Tuesday, March 22, 2005 10:05 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Re: Managed Build Process Environment and Build Paths proposal

 


Hi,
I had a look through the proposal and it looks good. I also think it is compatible with the Shared Tools Option proposal.

The only area where there might be a problem are in the interfaces IConfigurationEnvironmentVariableSupplier and the IProjectEnvironmentVariableSupplier. They both return a set of IBuildEnvironmentVariable objects which appear to be a constant (name, value) tuple. In fact all dependencies with regards to build configuration and project have been moved to the build variable providers.

The Shared Tools Option proposal is basically providing the capability to link an MBS option to a class that implements IBuildEnvironmentVariable and provides extra capabilities, such as the capability to set the value. This means that the value returned by IBuildEnvironmentVariable.getValue() essentially could change when the "Environments Variables" tab of the "C/C++ build property tab" looses focus. This means it would have to always re-read the values when it gets the focus, to ensure that correct values are displayed. So as long as  IBuildEnvironmentVariable objects are assumed NOT to be constant we should be fine.

I have a further question, which is not answered by the proposal. Will build macros - either user defined or tool integrator defined - be emitted into the makefile that is generated by GnuMakefileGenerator? The answer seems to be no as the spec does not say anything, but I wanted to double-check.

Best Regards
-- Lars






[cdt-dev] Managed Build Process Environment and Build Paths proposal  

From: "Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx>
Date: Fri, 18 Mar 2005 22:25:08 +0300
Delivered-to: cdt-dev@xxxxxxxxxxx
Thread-index: AcUkmHZEtTi1dU+mSeO0uDvqP3mI7QHU+ofg
Thread-topic: Managed Build Process Environment and Build Paths proposal

--------------------------------------------------------------------------------
Hi All,

 

I have added that Bugzilla enhancement request with the Managed Build Process Environment and Build Paths design attached, see the Bug 88497:

( https://bugs.eclipse.org/bugs/show_bug.cgi?id=88497 )

 

 

The Managed Build Process Environment and Build Paths support is one of the MBS enhancements planned to be implemented in the Managed Build System (MBS) for the CDT 3.0 release (see also "Proposed Managed Build System functionality for CDT 3.0" ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=81450 ))
 

I also hope that this design may be not just limited it to the MBS, but could be also used by other CDT community members to generally improve CDT.

 

Thank you

Mikhail

 
 


********************************************************************** Symbian Software Ltd is a company registered in England and Wales with registered number 4190020 and registered office at 2-6 Boundary Row, Southwark, London, SE1 8HP, UK. This message is intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify postmaster@xxxxxxxxxxx and delete the message and any attachments accompanying it immediately. Neither Symbian nor any of its subsidiaries accepts liability for any corruption, interception, amendment, tampering or viruses occurring to this message in transit or for any message sent by its employees which is not in compliance with Symbian corporate policy. **********************************************************************


Back to the top