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

[Sean Evoy <sevoy@xxxxxxxxxx>]

Chris,
I think there will be an impact on the
manifest/project file in both cases, so I don't see how either solution
is better in this regard. Since you asked, I went back and re-read the
proposals and my initial answer was based on the following "understanding".
The first option seems to involve adding a field to the existing option
schema, tweaking the read-persist logic for an option, and returning the
right command when asked. The second option seems to involve either a new
type of option or the creation of an executable extension, depending on
what Leo means by "Add a Boolean
Command object".

Maybe I am being overly cautious, but
my first instinct is that option #1 adds the least amount of overhead since
the logic for handling boolean options is present. Adding another option
type is more time consuming, due to the way I implemented options. Adding
an executable extension means that a toolchain implementor needs to write
Java code, something I would like to avoid except for special, advanced
cases.

Granted, adding a field that is exclusively
for boolean options might introduce its own difficulties for toolchain
implementors. What that says to me is that we may need to rethink the implementation
of the option implementation, but that's another discussion.

Hope that makes my position a bit more
clear.

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

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

03/05/2004 02:51 PM

Please respond to
cdt-dev

To	<cdt-dev@xxxxxxxxxxx>
cc
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