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

[Sean Evoy <sevoy@xxxxxxxxxx>]

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