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