[CMake] include_external_msproject creating duplicate projects in parent solution

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

Randy Hancock <randy.hancock at gmail.com>:
> I'm getting duplicate projects included in my top-level solution
> (*.sln file). I have a cmake project() defined at the top level and in
> the test projects for convenience during development. When I use
> include_external_msproject in the subprojects it also adds the
> external msproject to the parent. This is desirable, but lets say both
> the test/time project and the test/string project include the common
> lib. This makes common show up *twice* in the parent solution and
> causes a bunch of unwanted errors in visual studio.


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.

I also noticed that CMake really wants to have a PROJECT command in its
top-level directory.  If you don't put one there, the VC++ 2008
generator will make an SLN file in that directory anyway, using a
default project name.  This doesn't happen in subdirectories.

Here is a workaround based on a technique that I have actually used.
Let's say your directory structure looks (in part) like this:

/root
    CMakeLists.txt
    /test
        /string/CMakeLists.txt

(omitting other files and subdirectories in the directories shown).
Moreover, let's say /root/CMakeLists.txt contains the command
PROJECT(everything), and /root/test/string/CMakeLists.txt contains the
command PROJECT(string_test).

Then I would enclose PROJECT(string_test) within some conditional
statement that guarantees that the PROJECT(string_test) command will be
ignored when CMake is launched on /root/CMakeLists.txt.  When that
happens, CMake generates everything.sln but not string_test.sln.  On the
other hand, if you launch CMake on root/test/string/CMakeLists.txt, it
will duly generate string_test.sln.

One reason I actually did this was that I figured I would not
necessarily want string_test.sln every time I generated everything.sln.
(Another reason was that I never had confidence that anyone knew what it
really meant for CMake to process a PROJECT command in a subdirectory.)

This doesn't solve your problem yet, but if you put your
INCLUDE_EXTERNAL_MSPROJECT commands inside the same conditional as the
PROJECT commands (or in an equivalent conditional), you won't get
duplicates of the project in everything.sln.  Of course now you have NO
copies of this project in everything.sln, and you actually wanted one,
so put an INCLUDE_EXTERNAL_MSPROJECT command in /root/CMakeLists.txt (or
leave ONE of the commands in the subdirectories outside the conditional,
but that seems to me an inelegant and fragile design).

David