Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Managed Build Macros proposal - Feedback

Hi Lars,


Thank you for the feedback!


Please see my response embedded below.





Q1: It is not clear to me what the difference and interactions between the Build Macro Provider and a Macro Supplier are. Maybe this question will be answered in a later section of the document.
The Build Macro Provider is actually the public interface used for querying/resolving the build macros. It will internally use several suppliers that obtain and supply build macros form the several “sources”. The Build Macro Provider will “merge” the set ob macros provided by the suppliers in one resulting set returned to the caller. Suppliers are actually internal classes used by the Build Macro Provider. We decided to use the provider-suppliers model because there are several “sources” that provide build macros: macros defined by a user, macros defined by a tool-integrator, macros defined by MBS, etc. Each supplier will know how to obtain the macros from the particular “source”. Please see also my answer on the Q7.

Q2: Got a missing table here
I’m going to update it soon

[Section2.1, item 4 "The Currently selected file....]
Q3: I just wanted to check whether this restriction is a concious decision not to support this for CDT3.0. I believe that in principle you should be able to use the "C/C++ build" property page in this case.
Current design assumes that the set of file-context macros is MBS-predefined, that is neither a tool-integrator nor a user can define file-specific macros. File-specific macros will represent input and output file name, extension, relative path, etc. So I suppose that there is no need in explicitly displaying file macros in the UI. What do you think? Please see my comment on your next question.

Q4: It is not clear how a tool integrator provides file-context macros. Is there a macro provider for this? Or are these read only-macros which I can define only. But if I have attributes of the form "macro<MacroName>Value = <thisValue>" as children of the MBS builder element, how can the macros have different values for different selected files? Maybe I misunderstood what file specific macros are for.
The set of file-context macros is MBS-predefined, neither a tool-integrator nor a user can define new file-context macros, but a tool-integrator can specify the values for the file-context macros using attributes of a builder element. The macro values specified in those attributes should not contain the explicit e.g. file name, but instead should provide the filename definition in terms of the builder automatic variables and text functions. This is needed to allow the makefile generator to generate pattern rules, e.g. in the case of Gnu make, the macro that represents the output file name will contain the “$(notdir $@)” value. The builder definition of the gnu tool-chain will contain attribute specifying the value for that macro. If a tool-integrator does not provide the values for the file-specific macros, MBS will automatically expand them to their actual value when generating the buildfile, e.g. for the foo.c file the macro that represents the input file name will contain “foo.c” in this case. In this case the makefile generator will not be able to use pattern rules for building files with options containing file-specific macros.

Q5: Maybe you want to add a further entry here, e.g. variableAssignment, which defines how a value is assigned to a build macro. In GNU make alone you could either use "macro = value" or "macro := value". The latter option is more efficient. So you may want introduce a syntax which allows defining this.

The design assumes that all macro references will be resolved in the makefile, except for the macros that represent the builder environment: the user may choose to keep these macros unresolved in a makefile in case the builder provides the mechanism for referring environment variables as its own variables, so I suppose that there is no need in defining the variableAssignment attribute because there will be no “macro=value” definitions for the MBS build macros in the buildfile, because all macros except those representing the builder environment always get resolved in the buildfile. See also my comment on the Q9.

[Section 3.6.1 and 3.6.2]
Q6: Are the build macro suppliers called every time the UI and build file generator needs the value of a build macro? Or are these cached somewhere? In the latter case there may be an incompatibility problem with the "Shared Tool Options" proposal (see For example, what happens when (a) the "Build Macros" tab of the "C\C++ build" property page is drawn for the first time, and (b) what happens if focus switches to another tab and then gets back to the "Build Macros" tab? The "Shared Tool Options" proposal would require that the build macro provider is called in both cases as the values of the macros would have changed between loosing and re-gaining focus.

The build macros will not be cached and will be re-queried each time they are needed. This will include:

  • When displaying an UI for viewing/editing build macros
  • When displaying the “All Options:” box in the Tool option page
  • When generating the buildfile

So, each time the “Build Macros” tab is displayed the build macros will be re-queried.

[Section 3.6.4]
Q7: Can classes of type IBuildMacroProvider be defined by the tool integrator? Or are they an internal interface only. I grepped the document for IBuildMacroProvider and it only appears in this section or in section 5. Is it intended to be defined from within an MBS grammar element or through an extension point?

There will be only one instance of the IBuildMacroProvider per MBS and this will be the public interface for querying and resolving macros. The ManagedBuildManager will define a method “IBuildMacroProvider getBuildMacroProvider()” that will return the instance of the build macro provider. So, the tool-integrator will not be able to provide his/her own implementation of the IBuildMacroProvider

Q8: Further, coming back to my earlier suggestion (see Q5), you may also want to create function assignMacro(String macro, String value) which knows how to assign a value to a macro in the build file.

Please see my comment on the Q5.

Q9: The proposal does not make very clear what happens to macros that are not resolved. These would have to be defined as "macro = value" in the makefile. Will they be?
The design assumes that only macros representing the builder environment may be kept unresolved in the buildfile in the case when the builder can refer environment variables as its own variables. In this case the macro reference will be kept unresolved and will be converted to the builder variable reference using the builder “variableFormat” attribute, so there will be no “macro=value” definitions for the MBS build macros in the buildfile, because the environment variable macros will take there values from the builder environment.

"Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx

28/03/2005 10:56

Please respond to
"CDT General developers list."






[cdt-dev] Managed Build Macros proposal




Hi All,
I have added that Bugzilla enhancement request with the Managed Build Macros design attached, see the Bug 89210:
( )
The Managed Build Macros 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" ( ))
Thank you
cdt-dev mailing list

********************************************************************** 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