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. **********************************************************************