Imagine el siguiente escenario: el Proyecto A es una biblioteca compartida que tiene varias dependencias (LibA, LibB y LibC). El proyecto B es un ejecutable que depende del proyecto A y, por lo tanto, también requiere todas las dependencias del proyecto A para poder construir.

Además, ambos proyectos se construyen usando CMake, y el Proyecto A no debería necesitar ser instalado (a través del destino 'instalar') para que el Proyecto B lo use, ya que esto puede convertirse en una molestia para los desarrolladores.

¿Cuál es la mejor manera de resolver estas dependencias usando CMake? La solución ideal sería lo más simple posible (aunque no más simple) y requeriría un mantenimiento mínimo.

Fácil. Aquí está el ejemplo de la parte superior de mi cabeza:

El nivel superior CMakeLists.txt:

cmake_minimum_required(VERSION 2.8.10)

# You can tweak some common (for all subprojects) stuff here. For example:

set(CMAKE_DISABLE_IN_SOURCE_BUILD ON)
set(CMAKE_DISABLE_SOURCE_CHANGES  ON)

if ("${CMAKE_SOURCE_DIR}" STREQUAL "${CMAKE_BINARY_DIR}")
  message(SEND_ERROR "In-source builds are not allowed.")
endif ()

set(CMAKE_VERBOSE_MAKEFILE ON)
set(CMAKE_COLOR_MAKEFILE   ON)

# Remove 'lib' prefix for shared libraries on Windows
if (WIN32)
  set(CMAKE_SHARED_LIBRARY_PREFIX "")
endif ()

# When done tweaking common stuff, configure the components (subprojects).
# NOTE: The order matters! The most independent ones should go first.
add_subdirectory(components/B) # B is a static library (depends on Boost)
add_subdirectory(components/C) # C is a shared library (depends on B and external XXX)
add_subdirectory(components/A) # A is a shared library (depends on C and B)

add_subdirectory(components/Executable) # Executable (depends on A and C)

CMakeLists.txten components/B:

cmake_minimum_required(VERSION 2.8.10)

project(B C CXX)

find_package(Boost
             1.50.0
             REQUIRED)

file(GLOB CPP_FILES source/*.cpp)

include_directories(${Boost_INCLUDE_DIRS})

add_library(${PROJECT_NAME} STATIC ${CPP_FILES})

# Required on Unix OS family to be able to be linked into shared libraries.
set_target_properties(${PROJECT_NAME}
                      PROPERTIES POSITION_INDEPENDENT_CODE ON)

target_link_libraries(${PROJECT_NAME})

# Expose B's public includes (including Boost transitively) to other
# subprojects through cache variable.
set(${PROJECT_NAME}_INCLUDE_DIRS ${PROJECT_SOURCE_DIR}/include
                                 ${Boost_INCLUDE_DIRS}
    CACHE INTERNAL "${PROJECT_NAME}: Include Directories" FORCE)

CMakeLists.txten components/C:

cmake_minimum_required(VERSION 2.8.10)

project(C C CXX)

find_package(XXX REQUIRED)

file(GLOB CPP_FILES source/*.cpp)

add_definitions(${XXX_DEFINITIONS})

# NOTE: Boost's includes are transitively added through B_INCLUDE_DIRS.
include_directories(${B_INCLUDE_DIRS}
                    ${XXX_INCLUDE_DIRS})

add_library(${PROJECT_NAME} SHARED ${CPP_FILES})

target_link_libraries(${PROJECT_NAME} B
                                      ${XXX_LIBRARIES})

# Expose C's definitions (in this case only the ones of XXX transitively)
# to other subprojects through cache variable.
set(${PROJECT_NAME}_DEFINITIONS ${XXX_DEFINITIONS}
    CACHE INTERNAL "${PROJECT_NAME}: Definitions" FORCE)

# Expose C's public includes (including the ones of C's dependencies transitively)
# to other subprojects through cache variable.
set(${PROJECT_NAME}_INCLUDE_DIRS ${PROJECT_SOURCE_DIR}/include
                                 ${B_INCLUDE_DIRS}
                                 ${XXX_INCLUDE_DIRS}
    CACHE INTERNAL "${PROJECT_NAME}: Include Directories" FORCE)

CMakeLists.txten components/A:

cmake_minimum_required(VERSION 2.8.10)

project(A C CXX)

file(GLOB CPP_FILES source/*.cpp)

# XXX's definitions are transitively added through C_DEFINITIONS.
add_definitions(${C_DEFINITIONS})

# NOTE: B's and Boost's includes are transitively added through C_INCLUDE_DIRS.
include_directories(${C_INCLUDE_DIRS})

add_library(${PROJECT_NAME} SHARED ${CPP_FILES})

# You could need `${XXX_LIBRARIES}` here too, in case if the dependency 
# of A on C is not purely transitive in terms of XXX, but A explicitly requires
# some additional symbols from XXX. However, in this example, I assumed that 
# this is not the case, therefore A is only linked against B and C.
target_link_libraries(${PROJECT_NAME} B
                                      C)

# Expose A's definitions (in this case only the ones of C transitively)
# to other subprojects through cache variable.
set(${PROJECT_NAME}_DEFINITIONS ${C_DEFINITIONS}
    CACHE INTERNAL "${PROJECT_NAME}: Definitions" FORCE)

# Expose A's public includes (including the ones of A's dependencies
# transitively) to other subprojects through cache variable.
set(${PROJECT_NAME}_INCLUDE_DIRS ${PROJECT_SOURCE_DIR}/include
                                 ${C_INCLUDE_DIRS}
    CACHE INTERNAL "${PROJECT_NAME}: Include Directories" FORCE)

CMakeLists.txten components/Executable:

cmake_minimum_required(VERSION 2.8.10)

project(Executable C CXX)

file(GLOB CPP_FILES source/*.cpp)

add_definitions(${A_DEFINITIONS})

include_directories(${A_INCLUDE_DIRS})

add_executable(${PROJECT_NAME} ${CPP_FILES})

target_link_libraries(${PROJECT_NAME} A C)

Para que quede claro, aquí está la estructura de árbol de origen correspondiente:

Root of the project
├───components
│   ├───Executable
│   │   ├───resource
│   │   │   └───icons
│   │   ├───source
|   |   └───CMakeLists.txt
│   ├───A
│   │   ├───include
│   │   │   └───A
│   │   ├───source
|   |   └───CMakeLists.txt
│   ├───B
│   │   ├───include
│   │   │   └───B
│   │   ├───source
|   |   └───CMakeLists.txt
│   └───C
│       ├───include
│       │   └───C
│       ├───source
|       └───CMakeLists.txt
└───CMakeLists.txt

Hay muchos puntos en los que esto podría ajustarse / personalizarse o cambiarse para satisfacer ciertas necesidades, pero esto al menos debería ayudarlo a comenzar.

NOTA: He empleado con éxito esta estructura en varios proyectos de tamaño mediano y grande.

Alexander Shukaev tuvo un gran comienzo, pero hay varias cosas que podrían hacerse mejor:

1. No utilice include_directories. Por lo menos, use target_include_directories. Sin embargo, probablemente ni siquiera necesite hacer eso si usa los destinos importados.

2. Utilice los objetivos importados. Ejemplo de impulso:

   find_package(Boost 1.56 REQUIRED COMPONENTS
                date_time filesystem iostreams)
   add_executable(foo foo.cc)
   target_link_libraries(foo
     PRIVATE
       Boost::date_time
       Boost::filesystem
       Boost::iostreams
   )
   

   Esto se encarga de los directorios de inclusión, bibliotecas, etc. Si usó Boost en sus encabezados en B, entonces en lugar de PRIVATE, use PUBLIC, y estas dependencias se agregarán transitivamente a lo que dependa de B.

3. No utilice el archivo globular (a menos que utilice 3.12). Hasta hace muy poco, el almacenamiento global de archivos solo funcionaba durante el tiempo de configuración, por lo que si agrega archivos y compila, no podrá detectar los cambios hasta que regenere explícitamente el proyecto. Sin embargo, si enumera los archivos directamente e intenta compilar, debería reconocer que la configuración está desactualizada y regenerarse automáticamente en el paso de compilación.

Hay una buena charla aquí (YouTube): C ++ Now 2017: Daniel Pfeifer "Effective CMake"

Lo que cubre una idea de administrador de paquetes que permite que su CMake de nivel raíz funcione con find_packageOR subdirectory, sin embargo, he estado tratando de adoptar la ideología de esto y estoy teniendo grandes problemas find_packagepara usarlo para todo y tener una estructura de directorio como la suya.

Esto también se puede hacer usando el Cachemecanismo CMake para lograr lo mismo (es decir, compartir variables específicas del proyecto):

establecer (VAR "valor" CACHE INTERNAL "")

Consulte la pregunta de Stack Overflow Cómo compartir variables entre diferentes archivos CMake .