Hi Lars,
Thank you for your
explanation.
>Yes. The intention is to use an environment
variable or better a build macro as a means to passing options that are shared
between several tools into the build process. An example where this may be
needed are -I's and -Ds that are passed to compiler, resource compiler
and other tools. Our toolchain has several other situations where this is the
case.
>Now I may have slightly gotten confused because of the split
between the build macros propsal and the proposal you sent already. I thought
the two proposals were one. But the idea is to allow an MBS option that is a
child of a toolchain to be used to pipe values into a build variable/macro and
vice versa.
I suppose that you will
need to use build macros to implement this functionality. The below comments
are made with respect to Build Macros instead of Environment variables
We are planning to do exactly this. Although, if the
UI is re-queried every time the "Environments Variable" tab gets into
focus, we may return a different set of (read-only) objects via the variable
supplier, instead of manipulating the values of IBuildEnvironmentVariable
objects.
The Build Macros design
assumes that the macro suppliers will be re-queried every time the build macros
are needed. This includes:
- When displaying an UI
for viewing/editing build macros
- When displaying the “All
Options:” box in the Tool option page
- When generating the
buildfile
Please see the Build Macros
Proposal I posted to the Bugzilla (bug 89210: ( https://bugs.eclipse.org/bugs/show_bug.cgi?id=89210
)).
Thank you
Mikhail
From:
cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Wednesday, March 23, 2005
9:44 PM
To: cdt-dev@xxxxxxxxxxx
Cc: cdt-dev@xxxxxxxxxxx;
cdt-dev-admin@xxxxxxxxxxx
Subject: RE: [cdt-dev] Re: Managed
Build Process Environment and Build Paths proposal
Mikhail,
I am about to go on holidays ... thus only a very brief
answer. I will get back with more detail when I am back.
Why do you need to directly reference the
IBuildEnvironment variable interface in the option? I suppose that only the
user-defined variables will be editable and that they should be edited using
only one entry in the UI – in the “Build Environment” tab. The
tool-integrator way for providing the build variables is through using the
supplier. Do you mean that changing some option value may involve changing the
variable value provided by the tool-integrator?
Yes. The intention is to use an environment variable or
better a build macro as a means to passing options that are shared between
several tools into the build process. An example where this may be needed are
-I's and -Ds that are passed to compiler, resource compiler and other
tools. Our toolchain has several other situations where this is the case.
Now I may have slightly gotten confused because of the split
between the build macros propsal and the proposal you sent already. I thought
the two proposals were one. But the idea is to allow an MBS option that is a
child of a toolchain to be used to pipe values into a build variable/macro and
vice versa.
In this case I suppose that each time
before displaying the “Environent Variables” tab the Environment
Variable Provider should be re-queried for the complete set of the environment
variables, because the tool-integrator might not just change the value of some
variable, but also add/remove some variables.
That is correct.
But I’m not sure whether changing
the option value should involve changing the variable values provided by the
tool-integrator. What do you think?
We are planning to do exactly this. Although, if the UI is
re-queried every time the "Environments Variable" tab gets into
focus, we may return a different set of (read-only) objects via the variable
supplier, instead of manipulating the values of IBuildEnvironmentVariable
objects.
I’ve got almost the same comment
regarding the build macros: why do you need to directly access the interface
representing some particular build macro. I suppose that all string-type
options will contain the option values with build macros unresolved and will be
displayed in the UI with macros unresolved also (build macros will be
referenced in the strings using the syntax: ${macro_name}) and will be
displayed in the UI with macros unresolved also. In case you would want to know
the actual option value that will be passed to the tool during the build
process you will be able to use the resolve* methods provided by the
BuildMacroProvider.
I will try and explain our use-case a bit more. In Symbian
OS we have a few cases where command line arguments for individual tools are
related to each other.
Example (1): some
-D's must be passed into several tools (e.g. resource compiler, compiler,
various other tools) ... if the set of -D's that is passed to each individual
tool is not consistent the built binary will either fail to build or not work
properly at run-time.
Example (2): we have
a few other cases where a system-wide property, that is changeable by the user,
determines command line options for individual tools. For example we have
system wide security attributes. For simplicity assume that the security
attribute can be LOW, MEDIUM or HIGH. Further assume we have the tools Tool1,
Tool2 and Tool3. If the security attribute was LOW, then the options for Tool1
may be "-Security=Low", the options for Tool2 may be
"-DSECURITY_LOW" and the options for Tool3 may be
"-Security=Enabled -Level=Low". If inconsistent options are passed
into any tool, thebuilt binary will not behave correctly at run-times.
So the idea in example 1 would be to use an MBS option that
is tied to a toolchain to allow the user to provide system-wide -D's, pass its
value into a build macro say SystemDefs and use ${SystemDefs} in all tools that
need it. In example 2 we would use such an MBS option to allow the user to
choose whether security was LOW, MEDIUM or HIGH. A call-back would be used to
process and populate the processed values. So in example two, we would define
tool-integrator provided build macros (e.g. Tool1_Security, Tool2_Security,
etc) and have the call-back set up the values of the build macros depending on
the value of the security MBS option.
This means we can use the MBS UI and retain the MBS look and
feel of the project properties, we can use the build macros back-end to pass in
options to the makefile, while ensuring that the end-user cannot create an
inconsistent set of command line options..
Best
Regards
--
Lars
"Sennikovsky,
Mikhail" <mikhail.sennikovsky@xxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx
23/03/2005
14:53
Please
respond to
cdt-dev@xxxxxxxxxxx
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [cdt-dev] Re: Managed Build
Process Environment and Build Paths proposal
|
|
Hi Lars,
Are you talking about Build Macros or the
Build Process Environment Variables?
The build process environment design
actually describes the capability of specifying the additional set environment
variables to be used when launching the builder process (e.g.
“make”) when building the project.
I suppose that there will be separate
providers: one for providing the build environment variables and an other
– for providing the Build Macros.
There will be the separate design for the
build macros support. I’m going to post it at the beginning of the next
week, or hopefully at the end of this week.
I will try to answer your questions with
respect to both build macros and the builder process environment (please
forgive me if I have got you wrong)
Here are some of the Build Macro design
concepts that could be possibly interesting to you in the context of the Shared
Tool Options (some of those concepts were already posted by Leo Treggiari in
the previous mails to the cdt-dev list, let me just repeat them here)
- Build macros will be
able to be used in all options that accept text by enclosing the macro
name in braces, preceded by a dollar sign. There will be a
IBuildMacroProvider interface defined that will allow getting the list of
macros and resolving the macro values used in the option value.
- All option values
will be displayed in the UI with macros unresolved (except the “All
Options:” box that will contain the complete set of options passed
to the tool with resolved macros)
- Build Macros will be
context-sensitive, that is the macro of a given name could have different
values depending on where it is used.
Several types of context
will be available:
- The currently selected file.
- The currently selected option
- The currently
selected configuration (which includes a tool-chain).
- The currently selected project.
- The current workspace.
- The CDT and Eclipse
installations.
- The process
environment variables defined in the environment passed to Eclipse.
- There will be one or
more supplier for each context, e.g.
- User-defined macros
supplier
- Tool-integrator
provided supplier
- MBS-predefined
macros supplier
Here are my answers/comments to your questions:
> The only area where there might be a problem are in the
interfaces IConfigurationEnvironmentVariableSupplier and the
IProjectEnvironmentVariableSupplier. They both return a set of
IBuildEnvironmentVariable objects which appear to be a constant (name, value)
tuple. In fact all dependencies with regards to build configuration and project
have been moved to the build variable providers.
> The Shared Tools Option proposal is basically providing the
capability to link an MBS option to a class that implements
IBuildEnvironmentVariable and provides extra capabilities, such as the
capability to set the value.
This means that the value returned by
IBuildEnvironmentVariable.getValue() essentially could change when the
"Environments Variables" tab of the "C/C++ build property
tab" looses focus. This means it would have to always re-read the values
when it gets the focus, to ensure that correct values are displayed. So as long
as IBuildEnvironmentVariable objects are assumed NOT to be constant we
should be fine.
Why do you need to directly reference the
IBuildEnvironment variable interface in the option? I suppose that only the
user-defined variables will be editable and that they should be edited using
only one entry in the UI – in the “Build Environment” tab. The
tool-integrator way for providing the build variables is through using the
supplier. Do you mean that changing some option value may involve changing the
variable value provided by the tool-integrator? In this case I suppose that
each time before displaying the “Environent Variables” tab the
Environment Variable Provider should be re-queried for the complete set of the
environment variables, because the tool-integrator might not just change the
value of some variable, but also add/remove some variables. But I’m not
sure whether changing the option value should involve changing the variable
values provided by the tool-integrator. What do you think?
I’ve got almost the same comment
regarding the build macros: why do you need to directly access the interface
representing some particular build macro. I suppose that all string-type
options will contain the option values with build macros unresolved and will be
displayed in the UI with macros unresolved also (build macros will be
referenced in the strings using the syntax: ${macro_name}) and will be
displayed in the UI with macros unresolved also. In case you would want to know
the actual option value that will be passed to the tool during the build
process you will be able to use the resolve* methods provided by the
BuildMacroProvider.
> I have a further question, which is not answered by the
proposal. Will build macros - either user defined or tool integrator defined -
be emitted into the makefile that is generated by GnuMakefileGenerator? The
answer seems to be no as the spec does not say anything, but I wanted to double-check.
The Build Macros Proposal will cover this.
I suppose that all build macros will be expanded in the buildfile, except the
macros representing the build process environment, user will have an option
either to expand them or keep them in the buildfile.
We can not leave all macro references
unresolved in the buildfile because:
a) macros are context-sensitive: there are
file-specific, option-specific macros, etc.
b) macros can hold the list of values
Keeping the environment variable macro
references unresolved will provide the most flexibility in case user wants to
build the project outside of the MBS environment because the environment
variable values are user-specific and user will be able to adjust the build
process behavior by modifying environment and keeping the environment variable
build macros references be synchronized with the current environment.
Thank you
Mikhail
From:
cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Tuesday, March 22, 2005 10:05 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Re: Managed Build Process Environment and Build
Paths proposal
Hi,
I had a look through the proposal and it looks good. I also think it is
compatible with the Shared Tools Option proposal.
The only area where there might be a problem are in the interfaces
IConfigurationEnvironmentVariableSupplier and the
IProjectEnvironmentVariableSupplier. They both return a set of
IBuildEnvironmentVariable objects which appear to be a constant (name, value)
tuple. In fact all dependencies with regards to build configuration and project
have been moved to the build variable providers.
The Shared Tools Option proposal is basically providing the capability to link
an MBS option to a class that implements IBuildEnvironmentVariable and provides
extra capabilities, such as the capability to set the value. This means that
the value returned by IBuildEnvironmentVariable.getValue() essentially could
change when the "Environments Variables" tab of the "C/C++ build
property tab" looses focus. This means it would have to always re-read the
values when it gets the focus, to ensure that correct values are displayed. So
as long as IBuildEnvironmentVariable objects are assumed NOT to be
constant we should be fine.
I have a further question, which is not answered by the proposal. Will build
macros - either user defined or tool integrator defined - be emitted into the
makefile that is generated by GnuMakefileGenerator? The answer seems to be no
as the spec does not say anything, but I wanted to double-check.
Best Regards
-- Lars
[cdt-dev] Managed Build Process Environment and Build Paths proposal
From: "Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx>
Date: Fri, 18 Mar 2005 22:25:08 +0300
Delivered-to: cdt-dev@xxxxxxxxxxx
Thread-index: AcUkmHZEtTi1dU+mSeO0uDvqP3mI7QHU+ofg
Thread-topic: Managed Build Process Environment and Build Paths proposal
--------------------------------------------------------------------------------
Hi All,
I have added that Bugzilla enhancement request with the Managed Build Process
Environment and Build Paths design attached, see the Bug 88497:
( https://bugs.eclipse.org/bugs/show_bug.cgi?id=88497 )
The Managed Build Process Environment and Build Paths 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 ))
I also hope that this design may be not just limited it to the MBS, but could
be also used by other CDT community members to generally improve CDT.
Thank you
Mikhail
**********************************************************************
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. **********************************************************************
**********************************************************************
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. **********************************************************************