On Sun, Nov 6, 2011 at 5:23 PM, Michael Hertling <mhertl...@online.de> wrote: > On 11/06/2011 07:49 PM, J Decker wrote: >>> >>> Of course, the CMakeLists.txt in examples (or example0 and example1) depends >>> on the actual library, so, from that level, we would like to call >>> ADD_SUBDIRECTORY() to the *higher level* library directory... which is >>> unacceptable for ADD_SUBDIRECTORY() (and probably conflicts with the whole >>> CMake structure). >>> >>> If we would move examples "up" the hierarchy there wouldn't be a problem, >>> but that doesn't give a nice distribution package. >>> >>> Any hints on a proper way to do this? >> >> I include higher level projects all over; you just have to specify an >> additional directory which is where that is built in the final output >> so you can do >> add_subdirectory( ../../whatever/example __/__/whatever/example) >> which builds into the __/__ path in the build directory... > > The explicit build directory for ADD_SUBDIRECTORY() is not the actual > problem; the problems which arise with this practice are rather, IMO: > > (1) Without a top-level CMakeLists.txt, you've usually no bullet-proof > information about the other project's location, e.g. you can not refer > to CMAKE_SOURCE_DIR or the like. Instead, you must use a relative path > upwards from CMAKE_CURRENT_SOURCE_DIR like ../../whatever/example, and > the "../.." is a hard-coded assumption on the other project's relative > location w.r.t. the current project one's. If the latter or the other > project is once moved, this assumption proves wrong, and you will have > to edit possibly quite numerous ADD_SUBDIRECTORY() commands to fix up > things. Alternatively, you might provide the other project's location > via a cached variable, preferably with a reasonable default value. >
Thats true even if you change where a project is in a forward going direction. > (2) If you additionally have an overall project as an entry point for > the configuration, the other project's CMakeLists.txt file might have > already been processed via an ADD_SUBDIRECTORY() command on behalf of > the overall project, so you must ensure that your current project's > CMakeLists.txt file doesn't invoke ADD_SUBDIRECTORY() on the other > one's source tree again. > > Both problems can be easily avoided if one does strictly organize the > projects in a top-down manner with a top-level CMakeLists.txt as the > sole entry point for the configuration. So, each CMakeLists.txt file > except for the top-level one is processed by one ADD_SUBDIRECTORY() > only, and you don't have to process any higher-level CMakeLists.txt > file because the superordinate one takes care of the correct order. > So, by not having the problem in the first place, is your solution? > In other words: If a project uses ADD_SUBDIRECTORY() on a project's > directory other than a descendent one, this usually indicates that > these projects are tightly coupled parts of an overall project, so > it should be the job of the overall project's CMakeLists.txt to call > - or have call - the sub-projects' CMakeLists.txt files in a correct > order. Hence, each sub-project can be sure that all its prerequisite > projects have been configured before. OTOH, if two projects are not > tightly coupled parts of the same overall project, the one should > not invoke ADD_SUBDIRECTORY() on the other, but FIND_PACKAGE(). > > Note that the above-mentioned points are just my personal liking; > certainly, there are different opinions, and there might very > well be setups which require a different approach. > > Regards, > > Michael > -- > > 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
