Hi Lars,
Please see my comments
embedded below.
Thanks,
Mikhail
Mikhail,
I think this answers all my questions and it also looks
that I wont have any difficulties implementing the Shared Tool Options
proposal. You may want to update bits of your document to
clarify the area with the file-context macros at some point.
OK, I will update the
document next week. Hopefully I will also add definitions of the MBS-predefined
macros (section 1.5)
Further, I wanted to ask whether you have a
rought idea when you are going to commit your changes (Pretty much at M7 or
before? Will you deliver all in once or have several
submissions to CVS?) . My implementation is not directly dependant on yours,
but I was planning to do some testing using the Build Macros mechanism. If I
had a rough idea about your time-scales I can tell my project manager and plan
our testing better.
I am planning currently
to have several submissions to CVS. My rough estimation is:
Core patch ~ ww 20
UI patch ~ ww 21
Test & Doc patch ~ ww
25-26
Is it OK for you?
In the long run (i.e. post CDT 3.0), it would be nice
if it were possible to leave build macros unresolved and insert
"macro=value" entries into the build file. Maybe
the builder could specify a preference as to whether it wants to handle the macros
itself or whether the MBS resolves them.
The main advantage of this approach is that the
build files (makefiles) that are generated by MBS would be more readable and
maintanable. This then opens the possibility that a CDT user
can ship his/her project to somebody who does not use CDT. It may also make
maintaining the MBS a bit more easy: for example if there was a bug in the
macro expansion mechanism, the bugs would be more easy to spot by just looking
at the makefile.
This sound like a good idea, so let us discuss it
in the future for the post-3.0 CDT. Currently I see the following issues with
leaving macros unresolved in the buildfile: simple specifying the “macro=value”
in the buildfile will not work for the string-list macros (the macros that can
hold a list of values), also since file-specific and option-specific macros are
not the buildfile-wide, specifying “macro-value” in the buildfile
for those macros will not work also.
Best Regards
--
Lars
"Sennikovsky,
Mikhail" <mikhail.sennikovsky@xxxxxxxxx>
Sent
by: cdt-dev-bounces@xxxxxxxxxxx
07/04/2005 19:06
Please
respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx>
|
|
To
|
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [cdt-dev] Managed Build Macros proposal -
Feedback
|
|
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.
********************************************************************** _______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev