[CMake] Broken Cmake Behavior using --build VS2010

[David Cole]

On Sat, Dec 17, 2011 at 5:00 AM, J Decker <d3ck0r at gmail.com> wrote:
> Ya know... that's good and all, and I suppose 'proper' design accounts
> for this, but there are several directories that have multiple targets
> because they don't really merit a subdirectory; the code is less than
> 200 lines, and simple build with all the base rules.... yes, I could
> make subdirectories and put the cmakes there - was doing that for a
> while when I first learned the difficulties with mutiple projects per
> file; but after learning that add_subdirectory projects didn't affect
> the outer project which picked the solution name they got to have a
> single project make many simple targets; and I don't think that having
> mutiple targets to a single project is very elegant when outputting to
> project based generators...
>
>
>
> On Thu, Dec 15, 2011 at 12:10 AM, Rolf Eike Beer <eike at sf-mail.de> wrote:
>>> This is because we should really only allow one project command per
>>> CMakeLists.txt file, but since we do not error out, it's difficult to
>>> change at this point in time...
>>>
>>> --build uses the CMAKE_PROJECT_NAME cache variable to decide what sln file
>>> to use, and that corresponds to the first project command.
>>>
>>> Do you need multiple project commands in your CMakeLists.txt file?
>>>
>>> What benefit do you get from it?
>>>
>>> I'd like to understand how people are using multiple project commands, so
>>> we can fix this the "right" way.
>>
>> At my last employer we used multiple projects, too. But every
>> CMakeLists.txt had at most one project(). We had a large number of
>> libraries that had many dependencies regarding their include directories
>> and so on. Also they could be used to build different parts of the
>> software more or less standalone.
>>
>> So what we did was to use the add_subdirectory_once() macro I posted here
>> a few time which does what add_subdirectory() does but will just do
>> nothing if the given directory is already part of the build.
>>
>> And later we did things like
>> include_directories(${LIB1_SOURCE_DIR}/include) to easily get the includes
>> without too much relative paths.
>>
>> Eike
>> --
>>
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.cmake.org/mailman/listinfo/cmake
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake


Bill committed a fix for this yesterday, including a "two project
commands in a single CMakeLists file" test. Today, the test passes on
all of our dashboard runs submitted so far:

  http://www.cdash.org/CDash/testSummary.php?project=1&name=CMakeDoubleProject&date=2011-12-17

See these commits for the fix and the test:

  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ecf0e06b61327af4be5005281a6a92f9ac6de466
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7523858fdf497a9bc9193b7df5404679fb6008bf

Give the nightly build, or the 'next' branch a try. This should now be
fixed without having any negative side effects.

(Strictly speaking, we did change the behavior, but we don't believe
it should affect anybody other than fixing the negative that cmake
--build didn't work for such projects... The old behavior was to cache
the very first project command's name in the CMAKE_PROJECT_NAME cache
entry. Now we cache the name of the *last* project command in the
top-level CMakeLists file.)

Let us know how it works for you.


Thanks,
David