> The idea is to include several "packages" (one package ~ one project in > Boost) and make those available to the build, exactly as for a regular > CMakeLists.txt that adds several directories or subprojects through a > sequence of calls to "add_directories". > However, the difference here is that "packages" have inter-dependencies, and > the order of the "add_directories" should honor those dependencies.
I solved the issue of including several dirs (via 'add_directories') using guards 'if (TARGET name); return(); endif()' in my pkg manager. See boost libraries there: https://cppan.org/search?q=boost Each library can be included to project separately with autoincluding required deps for it. Config files (CMakeLists.txt, "dependencies.cmake" in you terminology) autogenerated with the pkg manager client iteself - 1 config per 1 library. You could try to look how the generated files organized, maybe you find something useful. On 27 September 2017 at 15:50, Raffi Enficiaud <raffi.enfici...@mines-paris.org> wrote: > Hi CMake, > > I am currently working on a toy cmake prototype for Boost. I am not sure it > will ever be released but I believe it might be useful beyond this project. > > The idea is to include several "packages" (one package ~ one project in > Boost) and make those available to the build, exactly as for a regular > CMakeLists.txt that adds several directories or subprojects through a > sequence of calls to "add_directories". > > However, the difference here is that "packages" have inter-dependencies, and > the order of the "add_directories" should honor those dependencies. > > I developed a rather small CMake script that > * encodes those dependencies in a very simple manner, just by stating parent > projects in the DAG of dependencies in an appropriate cmake variable, > * runs the ordered inclusion of those dependencies inside the master > project, > > It works like this: > 1/ a small "dependencies.cmake" declares the provided components and > dependencies: > * a variable that indicates the provided components (say "core", "doc" > and "test"). Each component defines a CMakeLists.txt > * a variable that indicates the dependencies to another module (with or > without components) > > 2/ a function parses a build tree (not necessarily flat) and detect all > those dependencies.cmake, loads the containing variables and extract the > module and components > > 3/ another function reads the variables set by step 2/ and adds the > components in the right order > > Additional filtering can happen after 2 (already implemented in my project) > to remove all the packages/components that are not needed for the current > build, but 3/ will bring any necessary dependency to the build. > > A possible example, that can of course be adapted, is given below. > > My inquiry there is the following: > * would this be of any interest for the community? I know that some projects > are struggling with this or provide solutions that, as a developer, dislike > * is there already any such mechanism in cmake? I failed to see any, and the > problem statement is a different than the cmake-package facility provided by > cmake. > > I believe it would also be possible to enhance step 3/ by eg. having a logic > that checks out the package sources instead of doing an "add_directory", and > by the possible intermediate filter after step 2/, then checking out only > what is needed for the end-user/developer. > > Thanks! > Raffi > > > > ------------------ Example for Boost.test ---- > > set(_current_package "TEST") > # this declares the components > set(BOOST_LIB_${_current_package}_COMPONENTS "build" "doc" "test") > > # this declares the dependencies for the component "build" > set(BOOST_LIB_${_current_package}_COMPONENTS_BUILD_DEPENDENCY > "system:build" > "core:build" > "config:build" > "predef:build" > ) > > # same for the component "DOC" > set(BOOST_LIB_${_current_package}_COMPONENTS_DOC_DEPENDENCY ) > # same for the component "TEST" (or the module TEST) > set(BOOST_LIB_${_current_package}_COMPONENTS_TEST_DEPENDENCY "test:build") > > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers -- Egor Pugin -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
