Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Suggested enhancement for Boolean options

Hi Chris,


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.





Option Schema:
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 
non-default value:
               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.



-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Recoskie, Chris
Sent: Friday, March 05, 2004 2:51 PM
To: cdt-dev@xxxxxxxxxxx
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 something?




Chris Recoskie

Software Designer

IDE Frameworks Group

Texas Instruments, Toronto



-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Sean Evoy
Sent: Friday, March 05, 2004 2:24 PM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Suggested enhancement for Boolean options


I like 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.

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada

"Recoskie, Chris" <crecoskie@xxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

03/04/2004 05:21 PM

Please respond to






RE: [cdt-dev] Suggested enhancement for Boolean options




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


Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto

> -----Original Message-----
> From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
> 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 Boolean options
> 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
> handled.
> 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 -funsigned-char/-fsigned-char and
> in-identifiers/-fno-dollars-in-identifiers.  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
> False.
> If we can agree on this, I am willing to work on the patch.
> Leo Treggiari
> Intel Corp.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
cdt-dev mailing list

Back to the top