RE: [cdt-patch] Outline Open Include patch

["Lott, Jeremiah" <jeremiah.lott@xxxxxxxxxxx>]

-----Original Message-----
From: Thomas Fletcher [mailto:thomasf@xxxxxxx] 
Sent: Wednesday, February 11, 2004 6:16 AM
To: cdt-patch@xxxxxxxxxxx; Alain Magloire
Subject: Re: [cdt-patch] Outline Open Include patch

[beginning of original message snipped]

> Something also came to a discussion with an end user of the CDT today.
Their 
> project of course contains: Neutrino, VxWorks and Windows source all
in one tree.  
> For them a "single" configuration (in this case the configuration I'm
talking 
> about is the Include/Defines for source code
> navigation) isn't desirable, they would need to have multiple
configurations and 
> the ability to switch between them.

Do they have each of the above types of source code is separate
sub-folders within the tree?  If so, it seems to me that it would be
more useful to be able to set Include/Defines on a per-folder basis.  To
me that kind of sounds like "sub-projects" which, I think, was on the
CDT 2.0 plan for investigation at one point.

> Now in a Managed Make scenario ... this would start corresponding to
the concept 
> of toolchains, but there is no such mechanism for the "Standard Make".
I think 
> that this should be something that we take into 
> consideration.

I'm not sure the concept of toolchains as proposed would solve this
problem.  The user will still need to chose a "Target" type for managed
make (for example Gnu executable).  All files within the project are
then assumed to be linked into this target.  Toolchains will let you
switch what tools are used for a particular configuration (i.e.
i586-linux-gcc vs sh-linux-gcc vs sparc-solaris-gcc), but not the output
or input type (i.e. you can't also produce a windows dll).  This would
also probably require something like sub-projects.  I.e. build
everything under this folder into a dll using cygwin gcc, and everything
under this other folder into executable using VxWorks compiler.

This would actually be cool, because you could also imagine a project
which produces an .so and a sub-project which creates an executable for
testing the .so.  However, at this point I'd rather concentrate on other
improvements to the managed make system, since this can be achieved by
creating separate projects.

Of course Sean is the authority on managed make, he might have some
insight I don't.

[end of original message snipped]