Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Suggested enhancement for Boolean options


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


Back to the top