[CMake] Avoiding error when using add_subdirectory twice on same path (CMake 2.6.4)

[Michael Jackson]

myApp:

project(myApp)

add_subdirectory(commonLib)
add_subdirectory(lib1)
add_subdirectory(lib2)

add_executable(myApp ${files})
target_link_libraries(myApp lib1 lib2)


lib1/lib2:

project(lib1)

add_library(lib1 ${files})
target_link_libraries(lib1 commonLib)

I am doing exactly this currently in a project and it seems to work  
fine. YMMV.

Mike.

On Jun 16, 2009, at 7:06 PM, Tyler Roscoe wrote:

> On Tue, Jun 16, 2009 at 06:49:38PM -0400, David Cole wrote:
>> What is your CMake code for this "diamond dependency" case?
>
> The case as layed out is hypothetical, of course, but I'm thinking
> something like this:
>
> myApp:
>
> project(myApp)
>
> add_subdirectory(lib1)
> add_subdirectory(lib2)
>
> add_executable(myApp ${files})
> target_link_libraries(myApp lib1 lib2)
>
>
> lib1/lib2:
>
> project(lib1)
>
> add_subdirectory(commonLib)
>
> add_library(lib1 ${files})
> target_link_libraries(lib1 commonLib)
>
>> Is there a separate directory for each of the libs involved?
>
> Yes.
>
>> Whichever CMakeLists file glues them all together should be able to
>> add_subdirectory just once on each of them.... Why do you need two
>> add_subdirectory calls for commonLib?
>
> 1. It makes sense to me if lib1 and lib2, both of which have
> dependencies on commonLib, both make that dependency explicit in their
> CMakeLists. It is less clear to me if some other orchestrator "happens
> to" add_subdirectory(commonLib) and lib1 and lib2 "happen to" be  
> invoked
> from that orchestrator.
>
> 2. It allows lib1 and lib2 to be independent projects. Imagine that
> myApp is something big and complex; call it KDE (Komplex Development
> Environment :)). Just because I want to build lib1 doesn't necessarily
> mean that I want to build all of KDE. Or at least I may not want to  
> let
> CMake build the build system for all of KDE since this is
> time-consuming.
>
> In my project, we use a sort of object model where each directory (we
> call them "buildables") is its own independent thing that knows how to
> build itself and its dependencies. I am coming to understand that this
> model is a little strange for CMake but it makes sense to us and for  
> now
> (on CMake 2.6.2) it works.
>
> I hope this illustrates where I'm coming from.
>
> Thanks,
> tyler
> _______________________________________________
> 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