[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Managed Build Macros proposal - Feedback
|
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.
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.
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.
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