如何组合独立Git+CMake项目实现一键构建与混合配置？

问题背景 #

项目A依赖独立Git子模块项目B、C，C又依赖子模块D，所有项目均自带独立CMakeLists.txt，且不想修改B、C、D的CMake配置。曾尝试VS Code cmake-tools，但该工具为依赖创建独立build目录导致构建失败，现需解决多项目构建的一系列需求。

核心需求 #

• 一键编译所有项目：仅通过cd build/ && cmake ../A/ && make完成，无需逐个编译依赖
• 代码热更新：修改任意项目代码后，执行构建可自动重新编译相关内容
• 无安装依赖：直接从源码树读取头文件，从build目录读取库文件，无需安装依赖到系统路径
• 多配置支持：允许不同项目使用不同构建配置（如A用Debug，B用Release）

当前目录结构 #

A/
├── build/
├── CMakeLists.txt
│ 
├── B/
│   └── CMakeLists.txt
├── C/
│   ├── CMakeLists.txt
│   └── D/
│       └── CMakeLists.txt
|
├── include/
├── src/
│   └── CMakeLists.txt
└── test/
    └── CMakeLists.txt

解决方案 #

1. 目标能否实现？ #

完全可以实现，无需修改B、C、D的CMake配置，仅需调整项目A的CMakeLists.txt即可满足所有需求。

2. 当前目录结构是否合理？ #

当前结构合理：

• 子模块嵌套符合Git子模块的常规管理方式
• 项目A根目录下的build/是标准的out-of-source构建目录，便于隔离源码与构建产物
• 若需进一步优化，可将build/移至A的父目录（避免源码目录混入构建文件），但当前结构已能正常工作

3. 具体实现步骤 #

关键思路

利用CMake原生的add_subdirectory指令，为每个依赖项目指定单独的构建子目录，同时通过临时覆盖CMAKE_BUILD_TYPE实现不同项目的构建配置隔离，最终通过目标链接自动处理头文件与库路径。

项目A的CMakeLists.txt示例

cmake_minimum_required(VERSION 3.14)
project(A)

# 保存项目A的原始构建类型，用于后续恢复
set(ORIGINAL_BUILD_TYPE ${CMAKE_BUILD_TYPE})

# 1. 添加项目B，强制使用Release构建
set(CMAKE_BUILD_TYPE Release)
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/B ${CMAKE_CURRENT_BINARY_DIR}/B-build)

# 恢复项目A的构建类型
set(CMAKE_BUILD_TYPE ${ORIGINAL_BUILD_TYPE})

# 2. 添加项目C（自动处理其依赖D，无需额外配置）
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/C ${CMAKE_CURRENT_BINARY_DIR}/C-build)

# 3. 定义项目A的目标（示例为可执行文件，根据实际调整）
add_executable(A src/main.cpp)

# 4. 链接依赖库，CMake自动处理头文件路径与库文件路径
target_link_libraries(A PRIVATE B C)

各需求的满足说明

• 一键编译：执行cd A/build && cmake .. && make时，CMake会递归触发B、C、D的构建，最终编译项目A，无需单独处理依赖
• 代码热更新：CMake会自动跟踪所有依赖项目的源码文件，修改B/C/D的代码后，make会自动重新编译对应模块并链接A
• 无安装依赖：通过add_subdirectory引入的依赖，CMake会直接从其源码目录读取头文件，从指定的构建子目录（如B-build/）读取库文件，无需执行install步骤
• 多配置支持：通过临时修改CMAKE_BUILD_TYPE再添加子目录，可实现不同项目的构建配置隔离（如示例中B用Release，A用Debug）

解决cmake-tools的问题

在上述配置下，cmake-tools会遵循项目A的CMakeLists.txt设置，将所有依赖的构建产物放在A的build/目录下的子文件夹中，不会创建独立的build目录，解决之前的构建失败问题。

内容的提问来源于stack exchange，提问作者featherless biped