Hi Lars,
- One which allows to
retrieve and set up default values of the new optionCategory and option
elements before they are shown. The reason for this is that the user may
manually change the build macros using the build macro UI.
I think that this is Option element functionality.
Currently an Option can have a “static” default value. One of
the “below the line” MBS requirements is:
- An option can
provide a method to be called to return its default value. This
supports the case where the default value of the option changes based upon
the value of another option(s) or some other environment setting.
As with other currently “below the
line” functionality, if you (or your team) is willing to design and
implement this, we could get it in 3.0.
Regards,
Leo
From:
cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Monday, March 14, 2005 5:39
AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Shared Tool
Options
Leo,
this
looks like a workable approach.
>
The
tool-integration would be able to retrieve the option values from
> MBS callbacks.
For
a clean solution we may need two call-backs:
- One which allows to
retrieve and set up default values of the new optionCategory and option
elements before they are shown. The reason for this is that the user may
manually change the build macros using th build macro UI.
- One which allows to query
the values of the new optionCategory and option elements after they
have been set (as you proposed).
They could of course be
implemented as one entry in the MBS grammar. The difficulty is to decide when
the callbacks are called.
Whether
your proposal meets our requirement would depend on the detailed design of the
Build Macros proposal. There would need to be an API which allows setting and
querying of Build Macros.
>
If
you agree that this would meet your requirement, would you be willing
> to submit a design for supporting
OptionCategory and Option children of
> ToolChain elements, and implement the design
for CDT 3.0?
I
will discuss this at Symbian this week and will come back to you later this
week.
Regards
--
Lars
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent
by: cdt-dev-admin@xxxxxxxxxxx
13/03/2005 03:38
Please
respond to
cdt-dev@xxxxxxxxxxx
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
[cdt-dev] Shared Tool Options
|
|
Hi
Lars,
I've been thinking about your requirement below
and have a
counter-proposal.
1.1 Shared Tool Options
A number of Symbian tools require that identical
options are passed into
each individual tool. For example the resource
compiler, AIF file
generator and compiler require a set of shared -D
and -I options.
Platform security options are another example. Here
the user has to
choose from a global set of security attributes
(e.g. CapabilityAll)
which map onto different options for different
tools (e.g. -Security=xyz
for the resource compiler, -DSECURITY=0xabc for
the compiler, etc.). If
inconsistent options are passed to the tools, the
resulting binary will
not work correctly or may fail to build.
MBS supports defining options per tool only. This
means that shared
options have to be replicated in different tools
and that the user has
to keep them in sync manually.
My idea is allow OptionCategory and Option
elements to be children of
the
ToolChain element. ToolChain categories
would display in the Tool
Settings page at the top level, that is, at the
same level as the Tools.
The values set in these options would not be used
in command line
generation - the command, commandFalse, and
resourceFilter attributes
would be ignored.
The tool-integration would be able to retrieve the
option values from
MBS callbacks.
For your usage, you would use build macros in the
options to be set from
the values of the ToolChain options. The
build macros design will be
coming soon. A tool-integration will be able
to define build macros and
their values. You would set your build macro
values from your
tool-chain options.
If you agree that this would meet your
requirement, would you be willing
to submit a design for supporting OptionCategory
and Option children of
ToolChain elements, and implement the design for
CDT 3.0?
Thanks,
Leo
_______________________________________________
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. **********************************************************************