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

[Floca Ralf Omar]

> and at the approach the Boost folks use:
> 
>    https://svn.boost.org/trac/boost/browser/branches/release
Thank you for this hint. I will analyze their approach to see if it offers solutions that cover the particular problems of our projects. Otherwise we'll have to bite the bullet and rework the procedures and handling of MeVisLab packages in our repository.

>  > 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.
> Yes, and this same care can be used to avoid hitting the new error.
I think this is only correct assuming that the chosen architecture or use case is supported by CMake design paradigms. In our case the chosen use case is just not wanted/modeled by CMake. Thus just taking care while scripting is not enough in this case. But we will taking the new information into account when designing the next CMake use case.

Also thank you for explaining the CMake policy paradigm to me. Taking this information into account, I agree that policies aren't suitable options.

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: Brad King [mailto:brad.king at kitware.com]
> Gesendet: Mittwoch, 17. Juni 2009 15:07
> An: Floca Ralf Omar
> Cc: Tyler Roscoe; David Cole; Bill Hoffman; cmake at cmake.org
> Betreff: Re: [CMake] Avoiding error when using add_subdirectory twice on same
> path (CMake 2.6.4)
> 
> [approach using package meta-data files to control build]
>  > This approach minimizes the orchestrating effort and allows
>  > developers to work on their part of an package without worrying
>  > about unrelated projects.
> 
> Take a look at this thread:
> 
>    http://www.cmake.org/pipermail/cmake/2009-May/029239.html
> 
> and at the approach the Boost folks use:
> 
>    https://svn.boost.org/trac/boost/browser/branches/release
> 
> https://svn.boost.org/trac/boost/browser/branches/release/tools/build/CMake/Bo
> ostUtils.cmake
> 
> These projects use a meta-data file in each directory with project
> name and dependencies (module.cmake in the case of Boost).  The
> top-level directory loads the files and does a topological sort on the
> dependencies.  Then it adds all the subdirectories in the proper
> order.  No individual developer needs to worry about non-local
> information.
> 
>  > 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.
> 
> Yes, and this same care can be used to avoid hitting the new error.
> 
> We cannot allow CMake to generate the same build tree location twice,
> even if it is from the same source directory.  It is not well-defined.
> Consider:
> 
>    # Top/CMakeLists.txt
>    add_subdirectory(A)
>    add_subdirectory(B)
> 
>    # A/CMakeLists.txt
>    set(foo 1)
>    add_subdirectory(../C ../C)
> 
>    # B/CMakeLists.txt
>    set(foo 0)
>    add_subdirectory(../C ../C)
> 
>    # C/CMakeLists.txt
>    if(foo)
>      # Which of these
>    else(foo)
>      # two options?
>    endif(foo)
> 
> Switching A and B on/off or switching their order can lead to
> surprising changes in behavior.
> 
>  > 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.
> 
> CMake Policies are purely a deprecation and compatibility mechanism.
> They should never be used to choose among multiple desirable
> behaviors.  Eventually support for the OLD policy behavior will be
> removed.
> 
> Perhaps we should have made a policy for this behavioral change.
> However, at the time we made it every case of this happening we had
> seen was producing strange behavior so we didn't expect any real
> projects were using the missing check as a "feature".
> 
> Even if it were a policy, any project that tries to do this would get
> the warning.  Yes, it could temporarily avoid the warning by setting
> the policy to OLD, but it should *still* be updated to the NEW
> behavior!  Again, policies are not used for choosing among desirable
> behaviors.
> 
> -Brad