次のシナリオを想像してください。プロジェクト A は、いくつかの依存関係 (LibA、LibB、および LibC) を持つ共有ライブラリです。プロジェクト B は、プロジェクト A に依存する実行可能ファイルであるため、ビルドするにはプロジェクト A のすべての依存関係も必要です。
さらに、両方のプロジェクトは CMake を使用してビルドされており、プロジェクト B が使用するためにプロジェクト A を ('install' ターゲットを介して) インストールする必要はありません。
CMake を使用してこれらの依存関係を解決する最良の方法は何ですか? 理想的なソリューションは、可能な限り単純で (単純ではありませんが)、最小限のメンテナンスしか必要としません。
簡単。これが私の頭の上からの例です：
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.txtで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.txtで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.txtで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.txtで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)
明確にするために、対応するソース ツリー構造を次に示します。
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
特定のニーズを満たすために、これを微調整/カスタマイズまたは変更できるポイントがたくさんありますが、これで少なくとも開始できるはずです。
注:私はいくつかの中規模および大規模プロジェクトでこの構造をうまく採用しました。
Alexander Shukaev は素晴らしいスタートを切りましたが、改善できる点がいくつかあります。
target_include_directoriesください。ただし、インポートされたターゲットを使用する場合は、おそらくそれを行う必要さえありません。インポートされたターゲットを使用します。ブーストの例:
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
)
これにより、インクルード ディレクトリ、ライブラリなどが処理されます。B のヘッダーで Boost を使用した場合、PRIVATE の代わりに PUBLIC を使用すると、これらの依存関係は B に依存するものに推移的に追加されます。
ファイル グロービングを使用しないでください (3.12 を使用する場合を除く)。ごく最近まで、ファイルのグロビングは構成時にのみ機能するため、ファイルを追加してビルドすると、プロジェクトを明示的に再生成するまで変更を検出できませんでした。ただし、ファイルを直接リストしてビルドしようとすると、構成が古くなっていることが認識され、ビルド ステップで自動的に再生成されます。
ここで良い話があります (YouTube): C++Now 2017: Daniel Pfeifer "Effective CMake"
これは、ルート レベルの CMake がfind_packageORsubdirectoryで動作することを可能にするパッケージ マネージャーのアイデアをカバーしていますが、私はこのイデオロギーを採用しようとしておりfind_package、すべてに使用し、あなたのようなディレクトリ構造を持つことに大きな問題を抱えています。