[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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