[CMake] include_external_msproject creating duplicate projects in parent solution

[David.Karr at L-3COM.COM]

Tyler Roscoe [mailto:tyler at cryptio.net]:
> On Thu, Jun 04, 2009 at 05:14:20PM -0400, David.Karr at L-3COM.COM wrote:
> > I wonder if the concept of a PROJECT command in a subdirectory 
> > of your top-level CMake directory is semantically sound.  That is, 
> > it might work sometimes but cause trouble when you hit one of the
> > not-so-well-thought-out consequences of doing it.
> 
> We do this all over the place and everything seems to work as
expected.
> This practice is useful because it means that a developer can visit
any
> node in our tree and run CMake to generate a build system just for the
> modules that she is interested in (and its dependencies).

Actually, with the technique I described, you CAN visit a subdirectory
and run CMake there to generate a build system for the corresponding
subset of your modules.  In fact that's precisely the reason why I
started using that technique.

The idea is essentially to put a kind of "re-entry guard" around the
PROJECT command.  (Ideally, it's a guard that allows the PROJECT command
to be processed only if you started CMake in the same directory.)  Using
that technique, you can put PROJECT commands (properly guarded) in any
directories where you might want to generate a build system, up and down
the directory hierarchy.  What worries me is the use of _unguarded_
PROJECT commands, which can cause multiple build systems to be generated
by one run of CMake: one in the directory where you started, and one in
every subdirectory where you put a PROJECT command.  That seems to be an
invitation for things you set up for one build system to bleed over into
other build systems where you might not want them.

David