Hi Lars,
Thank you for the
feedback!
Please see my response
embedded below.
Thanks,
Mikhail
>[Section1.4]
>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.
>[Section1.5]
>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.
>[Section3.3]
>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.
>[Section3.4]
>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
https://bugs.eclipse.org/bugs/show_bug.cgi?id=90481). 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@xxxxxxxxxxx>
|
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
[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:
( https://bugs.eclipse.org/bugs/show_bug.cgi?id=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" ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=81450 ))
Thank you
Mikhail
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
**********************************************************************
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. **********************************************************************
