[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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.
**********************************************************************