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

[Floca Ralf Omar]

Hello and thanks for the response

> Not sure if it will work with your specialized system, Floca, but you might try something like:
>
> if (NOT TARGET ${target_defined_in_subdir})
>    add_subdirectory(subdir)
> endif ()
No, because it is not about avoiding the directory or that we were lazy and don't care about include guards. We *want* to go into the directories to scan for configuration information. But thank you very much for trying.

> 2. It allows lib1 and lib2 to be independent projects. Imagine that
> myApp is something big and complex; call it KDE (Komplex Development
> Environment :)). [...]
> [...] 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. [...]
That somehow hits the mark. I think there are huge similarities between the scenario of Tyler and mine. My troubling project is composed of several more or less independent parts. It is a MeVisLab package group. Such a group can consist of an arbitrary number of packages, which in turn can have an arbitrary numbers of VS projects. Each package has a so called pri-file, defining includes, libraries, etc. for a package. This pri-file is used by MeVisLab to create correct VS projects and must be compiled before the VS project creation starts. CMake/CTest is used to drive our BCS and Testing system and some of our projects are MeVisLab package groups, which cannot directly be build CMake for several reasons.

Because there are about 8 people working on different projects in one package, we want to give each VS project the possibility to define and configure its pri-file snippet (e.g. regarding local directories and location of other libraries). It is like Tyler's buildables. Also each developer can choose while the CMake configuration process which packages and VS projects (buildables) should be active in his local binary tree (see the KDE argument of Tyler). Thus the local pri-file of a package may vary and cannot be added fixed to the source tree of the package group.

This approach minimizes the orchestrating effort and allows developers to work on their part of an package without worrying about unrelated projects.

I agree on the fact that for the majority of projects the new (2.6.4) way of handling add_subdirectory is safer and sufficient. Therefore I understand Bill's point. But I also accord with Tyler that there are reasonable use cases where this new handling is a drawback. The old way requires more prudence when creating complex CMake scripts, but it can be handled by analogy with c++ headers and their include guards. In my opinion the new way should be default, but e.g. a policy-based possibility to switch back would be very welcome in order to give developers more freedom if they are willing to take care about the "consequences". The old behavior doesn't generate errors by default. It is only more error prone (due to its degree of freedom) and thus less suited for beginners or "normal" projects.


Kind regards,

Ralf

------------------------------------------------------------------
Ralf Floca
DKFZ
German Cancer Research Center (Deutsches Krebsforschungszentrum) 
Member of the Helmholtz Association
E071 Research Group
Software Development for Integrated Diagnostics and Therapy (SIDT)

Im Neuenheimer Feld 280
D-69120 Heidelberg

Telefon: +49 (6221) 42 3021
E-Mail: r.floca at dkfz-heidelberg.de
Web: www.dkfz.de
------------------------------------------------------------------

> -----Ursprüngliche Nachricht-----
> Von: Tyler Roscoe [mailto:tyler at cryptio.net]
> Gesendet: Mittwoch, 17. Juni 2009 01:06
> An: David Cole
> Cc: Bill Hoffman; Brad King; Floca Ralf Omar; cmake at cmake.org
> Betreff: Re: [CMake] Avoiding error when using add_subdirectory twice
> on same path (CMake 2.6.4)
> 
> 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