[CMake] Broken Cmake Behavior using --build VS2010

J Decker d3ck0r at gmail.com
Sat Dec 17 05:00:43 EST 2011


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


More information about the CMake mailing list