On Mon, Sep 17, 2018 at 8:49 AM Peter Dimov via Boost
Alexander Grund wrote:
Besides that: Don't use upward-references ("../some/foo") but rather e.g. "PROJECT_SOURCE_DIR" etc.
How would that work?
Easiest thing to do here is in each project's CMakeLists.txt file, use a standard naming convention to hoist the public include directory up to the superproject. I would macro-ize the dependency definition and building of the dependency header list, like: in libs/uuid/CMakeLists.txt: boost_depends_on ( serialization throw_exception ) Which would in turn set: set ( BOOST_UUID_DEPINCS ${BOOST_SERIALIZATION_HEADERS} ${BOOST_THROW_EXCEPTION_HEADERS} ) (and if those had link libraries, which would be identified by another variable of some sort, it would add to the link library list needed) The project itself would set the variable BOOST_UUID_HEADERS as: set ( BOOST_UUID_HEADERS ${CMAKE_CURRENT_SOURCE_DIR}/include ${BOOST_UUID_DEPINCS} PARENT_SCOPE ) This defines BOOST_UUID_HEADERS one level up - in the "libs" project. This variable now contains all of the include paths needed build anything that depends on uuid. In each dependent project, adding the following allows for access to the headers: boost_depends_on ( uuid ) which as part of the macro would run: include_directories ( ${BOOST_UUID_HEADERS} ) And obviously back in uuid where it says "boost_depends_on" that also added include directories for serialization and throw_exception for the uuid build. Now here's the really neat thing: the list of subdirectories in libs/CMakeLists.txt MUST be in dependency order which FORCES you to remove any cyclic dependencies in the overall project, which is a big plus! - Jim