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

I had a look at the proposal and it looks good. Sorry I am relatively late with this. I have a few questions for clarification.
-- Lars

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.

Q2: Got a missing table here

[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.

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.

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.

[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.

[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?

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.

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?

"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@xxxxxxxxxxx>

[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