Re: [cdt-dev] Suggested functionality for Build Configurations

[Douglas Schaefer <dschaefe@xxxxxxxxxx>]

Thanks, Leo, this is great! It pretty much lines up with our requirements 
as well.

I have put together an initial feature spec for the managed make 2.0 work 
and have it up on the CDT web site as mentioned in a previous e-mail. 
Please take a look and provide any feedback you may have, especially areas 
that need clarification/adjustment to ensure your requirements are met.

Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada



"Treggiari, Leo" <leo.treggiari@xxxxxxxxx> 
Sent by: cdt-dev-admin@xxxxxxxxxxx
10/17/2003 03:28 PM
Please respond to
cdt-dev@xxxxxxxxxxx


To
<cdt-dev@xxxxxxxxxxx>
cc

Subject
[cdt-dev] Suggested functionality for Build Configurations






Below are our suggestions, to date, for Build Configuration 
functionality.  The suggestions are applicable to the managed make 
builder as well as to any "automatic" builder that CDT should provide 
in the future.  Some of this functionality may already be in 1.2 or 
already planned for 2.0.

A Build Configuration should allow the user to:

o  Specify a target platform:  The build infrastructure should support
   multiple target platforms.  A single project should be able to 
   support configurations that target different platforms.
   As an aside, I haven't been able yet to decide exactly what the
   current CDT concept of "target" refers to.

o  Specify a tool set/chain:  The build infrastructure should support
   multiple tools set per target platform.  A single project should be
   able to support configurations that use different tool sets on the 
   same or different target platforms.  Note that providing project 
   converters to convert an existing project to support another 
   platform or tool set is not the same thing.  You may have a similar
   result to begin with, but thereafter the separate projects are more
   likely to diverge.

o  Override some of the tools in a tool set:  Tool sets define a 
   mapping of file extensions to tools.  The user should be able to 
   override or extend the default mapping and specify a tool, or 
   ordered set of tools, to be used with a file extension (or set of 
   file extensions).  This should be available at the Workspace, 
   Project, and Configuration level.

o  Specify tool command line options:  The user should be able to
   define default command line options per tool at the Workspace, 
   Project, and Configuration level.  The user should also be able to
   override the options for a specific source file.

o  Remove a source file from a configuration:  The user should be able
   to mark a source file as not to be built in a particular configuration.

o  Specify commands to be invoked before the build:  The user should be
   able to specify a script that runs before any of the other build steps.

o  Specify commands to be invoked after the build:  The user should be
   able to specify a script that runs after all of the other build steps.

o  Override building a particular source file:  The user should be able
   to specify that a tool (or set of tools) different than the default be
   used to build a particular source file.  The user should also be able
   to specify a script that runs before, instead of, or after, the 
   default tool for a particular source file.

o  Override the "Clean" script:  The user should be able to specify a
   script that runs before, instead of, or after, the default clean 
   script.

o  Use pre-defined and user-specified Build Macros in string tool options
   and scripts:  Build Macros are replaceable strings used in tool options
   that take a string value and in build scripts.  For example, a macro
   can be used that will be replaced by the configuration's output 
   directory.  In that way, changing the output directory property 
   automatically changes all of the uses of the build marco.
   See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/
   vccore/html/_asug_macros_for_custom_build_commands.asp for an example 
   of the pre-defined build macros used in Microsoft Visual C++.

o  Specify an Intermediate Output directory as distinct from the Output
   directory:  The user may want to separate these outputs.  These two
   directories would default to the same directory.

o  Export the generated make file:  The user should be able to export the
   make file.  For example, to be used on a platform that does not support
   CDT.

o  Derive a new configuration from an existing configuration and have tool
   options carry over to the new configuration.  Since different tools of
   the same kind (e.g. C++ compilers) will likely define unique options,
   this goal is probably not 100% doable (without an n x n solution).  But
   CDT could define a set of "generic" options and values that could be 
   written/read by all tools of a kind and provide a very useful subset to
   the total solution.


Leo Treggiari
Intel Corp., Nashua, NH
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev