I sent a larger set of requirements for option
support (copied at the end of this message) last October. At that time, I
could not devote any of my own time to it and so I think other Build System
functionality took priority for 2.0. I agree with you that there is some
significant work yet to be done in the option support. At this point, I’m
trying to suggest small changes for 2.0. I think that for the following
release we need to define a schema that provides all of the option
functionality that we need. I’m not sure that I would still agree
with everything I wrote last fall, but at some point after 2.0 I think that
Sean, I, you and your team, and anyone else with an interest/opinion regarding
the option support should begin a discussion on this.
There seems to be some functionality missing from the Option support:
* defaultValue attribute: There are 2 default values of interest
(not including a user specified value in the .cdtbuild file). They
are the Tool default value and the Configuration default value.
The Tool default value defines the default from the tool's
perspective. That is, what is the value of the option if the option
is absent from the command line. This information is important when
generating the tool command line. Putting options that specify
default values onto the command line is unnecessary and obscures the
important information (i.e. the non-default options).
The Configuration default value is the default from the
configuration's perspective. This is sometimes different than the
Tool default. For example, a Debug configuration requests the
generation of debug information and this is typically not the Tool
Knowing Tool and Configuration default values enables other desirable
UI features (both of these are supported in MS Visual Studio):
o Bolding (or some other highlighting) of properties
in the UI that currently contain non-default values.
o A "reset to default value" option when editing an
option with a non-default value.
* command attribute: The current rules for when this attribute
is used or ignored seem complicated and inconsistent. The command
value should be used for all option types when the option has a
o String Options: The specified value should be
concatenated to the command value to form the command option. The
command value can be empty if there is no "fixed" command option
value. For example, in the case of an "Additional Options" field
where the user can enter tool options that are not supported in the
UI. But there are cases where the command value is necessary.
Here are 2 examples. Tools produce output files and often have
command options for overriding the default names of these files.
'-o' appears to be currently special cased, but there are other
possibilities including listing files (e.g. -l filename). The user
should only specify the filename - the command option, '-l ',
should be specified by the tool provider. As another example, the
MS linker includes a /stack:nnn option. The user should enter the
nnn value and the command value contain '/stack:'.
There is another interesting twist with string options,
particularly options that take filenames or paths. On Windows,
these names can contain embedded spaces and, when specified with a
command line option, they need to be enclosed in quotes. This could
be solved by another Option schema attribute named quotedValue.
o Boolean Options: Currently the command value is
only used if the value is true. The default value of all Boolean
options is not true. This should be changed to use the command
value when the option has the non-default value.
o Enumerated Options: Currently the command and
defaultValue attributes are ignored and the values in the Enumerated
Option Value schema are used instead. This will not allow for the
identification of the Tool and Configuration default values. The
defaultValue for an Enumerated Option should specify the name of the
default choice. The command value should be treated as with a
String Option. That is, the selected Enumerated Option Value
command should be concatenated to the Enumerated Option command
value to form the command option.
o List Options: OK, I think...
Three other option support features are desirable:
* The ability to "validate" the value entered for an option.
This is necessary for string and string list options because only
certain strings may be valid. It is also necessary for all option
types in order to check for "conflicting" (e.g. mutually exclusive)
* The ability to specify a "custom editor" for an option. For
example, if a tool option took an RGB color value, you would want
to be able to present the user with a color editor to use in
setting the value.
* The ability to support a "dynamic" default value for an
option. That is, when the default for the option changes because
of other options that are set. An example is that the Intel compiler
supports optimization levels, but also supports setting individual
optimizations. A particular level (e.g. 3) may automatically set a
specific set of individual optimizations. If the user has specified
a level < 3, then the default for these individual optimizations is
false and we want the user to be able to set them individually to
true. If the user has specified level 3, then the default is true
and we want the user to be able to set then individually to false.
It may be that an option "extension point" is needed to handle
these more complicated option features.
[mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf
Of Recoskie, Chris
Sent: Friday, March 05, 2004 2:51
Subject: RE: [cdt-dev] Suggested
enhancement for Boolean options
Well we need to do
something eventually… and not just for this…
Down the road there are
still such things to consider as per file build options, and conditional build
options (i.e. you have options A and B, and B is only a valid option to
manipulate if A is already turned on). These are the kinds of things that are
going to have to be considered if we want to unify around a generic Managed
Make rather than having everyone doing their own.
Anyway, back to the issue
at hand :-) Maybe I’m confused… I don’t see how
Leo’s option 2 would be a problem for old manifest files. The
BooleanCommand would be an optional tag, so if it wasn’t there, no big
deal, you would just get the behaviour we have now. Am I missing
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx]
On Behalf Of Sean Evoy
Sent: Friday, March 05, 2004 2:24
Subject: RE: [cdt-dev] Suggested
enhancement for Boolean options
the first "option" Leo proposed best. OK, that was a lame attempt at
a pun, but it's been a long week. Frankly, I would like to keep the set of
option types as small as possible. If all we need to do is tweak an existing
type to make its semantic meaning richer, I would rather do that and deal with
the logic of reading in older manifests/project files.
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
RE: [cdt-dev] Suggested enhancement for Boolean options
good to me as we were talking about this yesterday and today here
at TI as well. Great minds think alike?
I guess we'll see what Sean says.
IDE Frameworks Group
Texas Instruments, Toronto
> -----Original Message-----
> From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx]
> Behalf Of Treggiari, Leo
> Sent: Thursday, March 04, 2004 4:38 PM
> To: cdt-dev@xxxxxxxxxxx
> Cc: Treggiari, Leo
> Subject: [cdt-dev] Suggested enhancement for
> I'd like to suggest another enhancement to
the managed build, option
> support. This suggestion is for Boolean
options. Currently, the
> attribute is only used whe the value of the
option is True. This
> the common case where the option needs to be
passed to the tool when
> check box is selected. But, there are 2
other cases not currently
> The first is the case where the option needs
to be passed to the tool
> the check box is unselected. This case
can be transformed into the
> currently supported case by changing the
wording of the option, but
> sometimes this is undesirable from a human
factors perspective. For
> example, the Intel compiler has a number of
/warn:xxx options (for
> uninitialized variables, unreferenced
variables, uncalled routines,
> I would like all of the check boxes to read
"Warn for xxxx", but some
> these warnings are defaulted to
"on" by the compiler and some are
> defaulted to "off". This
leaves me with some "Warn for xxx" check
> and some "Do not warn for xxx"
check boxes. I don't like it...
> The second case is where there is a True
version of the option and a
> separate False version of the option.
For example, there are many GCC
> foption options that also support
-fno-option. Supporting this is
> particularly important when the default
value of the option may be
> dependent as is the case with
Currently, a GCC compiler
> that supported '$' in indentifiers by default
would have a "Do not
> '$' in identifiers" check box, while a
GCC compiler that did not allow
> by default would have a "Allow '$' in
identifiers" check box. I don't
> like that either...
> The suggestion is to enhance Boolean option
support to allow a command
> be generated when the option is True and/or
when the option is False,
> to do this in an upward compatible way so
that existing Boolean
> continue to work as they currently do.
I have 2 ideas on how to
> the support:
> 1. Add a commandFalse attribute to the Option
Schema to be used, if
> specified, when the value of a Boolean option
is False. This is
> straightforward, but adds an attribute that
is exclusively for the
> Option Type.
> 2. Add a Boolean Command object that is a
child of a Boolean Option
> has a command attribute to be used when the
value of a Boolean option
> If we can agree on this, I am willing to work
on the patch.
> Leo Treggiari
> Intel Corp.
> cdt-dev mailing list
cdt-dev mailing list