[cdt-dev] Suggestions for CDT 2.0 Build Model

["Treggiari, Leo" <leo.treggiari@xxxxxxxxx>]

Now that I (think I) understand the 1.2 build model better, I have
some suggestions for the 2.0 build model.  I'm using the following
definition for a Target in the model: A Target defined in a 
plugin.xml file defines a tool chain for building a particular type
of application for a particular platform(s).  A Target in a 
.cdtbuild file, in addition, defines a specific build artifact for 
the project it is in.

Target Schema:

*	cleanCommand attribute:  Should this be an attribute for the 
Configuration rather than the Target?  Release and debug 
configurations can produce different artifacts and may need different
cleaning commands.

*	osList attribute: There should be 2 lists - one for the host 
systems on which this Target runs and one for the platforms on which 
the artifacts produced by the Target run.

Tool Schema:

*	outputs attribute:  A file extension is not general enough for 
defining the outputs of a tool.  For example, the Visual Studio MIDL 
compiler (compiles Interface Definition Files for RPC, COM, ...), can 
produce .c, .h, and .tlb files, and all of the output names do not 
default to the same filename as the input .idl file.

Option Schema:

There seems to be some functionality missing from the Option support:

*	defaultValue attribute:  There are 2 default values of interest
(not including a user specified value in the .cdtbuild file).  They 
are the Tool default value and the Configuration default value.  

The Tool default value defines the default from the tool's 
perspective.  That is, what is the value of the option if the option 
is absent from the command line.  This information is important when 
generating the tool command line.  Putting options that specify 
default values onto the command line is unnecessary and obscures the
important information (i.e. the non-default options).   

The Configuration default value is the default from the 
configuration's perspective.  This is sometimes different than the 
Tool default.  For example, a Debug configuration requests the 
generation of debug information and this is typically not the Tool 
default.

Knowing Tool and Configuration default values enables other desirable
UI features (both of these are supported in MS Visual Studio):
		o	Bolding (or some other highlighting) of properties 
in the UI that currently contain non-default values.
		o	A "reset to default value" option when editing an 
option with a non-default value.

*	command attribute:  The current rules for when this attribute 
is used or ignored seem complicated and inconsistent.  The command 
value should be used for all option types when the option has a 
non-default value:

		o	String Options:  The specified value should be 
concatenated to the command value to form the command option.  The 
command value can be empty if there is no "fixed" command option 
value.  For example, in the case of an "Additional Options" field 
where the user can enter tool options that are not supported in the
UI.  But there are cases where the command value is necessary.  
Here are 2 examples.  Tools produce output files and often have 
command options for overriding the default names of these files.  
'-o' appears to be currently special cased, but there are other 
possibilities including listing files (e.g. -l filename).  The user
should only specify the filename - the command option, '-l ', 
should be specified by the tool provider.  As another example, the 
MS linker includes a /stack:nnn option.  The user should enter the
nnn value and the command value contain '/stack:'.
		
		There is another interesting twist with string options,
particularly options that take filenames or paths.  On Windows, 
these names can contain embedded spaces and, when specified with a 
command line option, they need to be enclosed in quotes.  This could
be solved by another Option schema attribute named quotedValue.

		o	Boolean Options:  Currently the command value is 
only used if the value is true.  The default value of all Boolean 
options is not true.  This should be changed to use the command 
value when the option has the non-default value.

		o	Enumerated Options:  Currently the command and 
defaultValue attributes are ignored and the values in the Enumerated
Option Value schema are used instead.  This will not allow for the
identification of the Tool and Configuration default values.  The 
defaultValue for an Enumerated Option should specify the name of the
default choice.  The command value should be treated as with a 
String Option.  That is, the selected Enumerated Option Value 
command should be concatenated to the Enumerated Option command 
value to form the command option.

		o	List Options:  OK, I think...

Three other option support features are desirable:

*	The ability to "validate" the value entered for an option.  
This is necessary for string and string list options because only 
certain strings may be valid.  It is also necessary for all option 
types in order to check for "conflicting" (e.g. mutually exclusive) 
options.

*	The ability to specify a "custom editor" for an option.  For 
example, if a tool option took an RGB color value, you would want 
to be able to present the user with a color editor to use in 
setting the value.

*	The ability to support a "dynamic" default value for an 
option.  That is, when the default for the option changes because 
of other options that are set.  An example is that the Intel compiler
supports optimization levels, but also supports setting individual 
optimizations.  A particular level (e.g. 3) may automatically set a 
specific set of individual optimizations.  If the user has specified
a level <  3, then the default for these individual optimizations is
false and we want the user to be able to set them individually to 
true.  If the user has specified level 3, then the default is true 
and we want the user to be able to set then individually to false.

It may be that an option "extension point" is needed to handle 
these more complicated option features.

Leo Treggiari
Intel Corp.
Nashua, NH