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

["Treggiari, Leo" <leo.treggiari@xxxxxxxxx>]

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.

 

Regards,

Leo

 

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 

default.

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) 

options.

*       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

 

Hmm…

 

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

 

Gentlemen,
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
cdt-dev

To	<cdt-dev@xxxxxxxxxxx>
cc
Subject	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
command
> attribute is only used whe the value of the option is True.  This
handles
> the common case where the option needs to be passed to the tool when
the
> 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
when
> 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,
etc.).
> I would like all of the check boxes to read "Warn for xxxx", but some
of
> these warnings are defaulted to "on" by the compiler and some are
> defaulted to "off".  This leaves me with some "Warn for xxx" check
boxes
> 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
system
> dependent as is the case with -funsigned-char/-fsigned-char and
-fdollars-
> in-identifiers/-fno-dollars-in-identifiers.  Currently, a GCC compiler
> that supported '$' in indentifiers by default would have a "Do not
allow
> '$' 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
to
> be generated when the option is True and/or when the option is False,
and
> to do this in an upward compatible way so that existing Boolean
options
> continue to work as they currently do.  I have 2 ideas on how to
enhance
> 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
Boolean
> Option Type.
>
> 2. Add a Boolean Command object that is a child of a Boolean Option
and
> has a command attribute to be used when the value of a Boolean option
is
> 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
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev