CMake中Include与add_subdirectory对比：相对头文件路径问题

嘿，我来帮你把这个CMake的问题捋清楚！针对你提到的带多子目录的C++项目，以及add_subdirectory和include的选择问题，我给你详细拆解一下：

核心区别与include被标记为遗留用法的原因 #

• add_subdirectory(module1)：这是CMake官方推荐的现代子项目管理方式。它会进入指定子目录执行其中的CMakeLists.txt，并且为子目录创建独立的变量作用域，不会随意污染父目录的变量。这种方式完美适配模块化项目，每个模块的CMake配置独立，后续维护和调试都更清晰。
• include(module1/CMakeLists.txt)：这种方式本质是把子目录的CMake代码直接嵌入当前文件的对应位置执行，和父目录共享同一个变量作用域。比如你代码里的set(SRCS ${SRCS} ...)会直接修改父目录的SRCS变量，很容易引发变量冲突、意外的副作用，项目复杂度提升后会变得极难维护。CMake官方确实将这种用法归类为遗留/不推荐的方式。

适配你项目结构的最佳实践 #

结合你的目录结构：

src/
├── CMakeLists.txt
├── main.cpp
├── module1/
│   ├── CMakeLists.txt
│   ├── code.cpp
│   ├── code.h
└── module2/
    ├── CMakeLists.txt
    ├── code2.cpp

推荐完全采用add_subdirectory+目标导向CMake的写法，具体如下：

1. 根目录（src/CMakeLists.txt）示例 #

cmake_minimum_required(VERSION 3.16) # 根据你的项目需求调整版本
project(YourProjectName)

# 添加子模块，CMake会自动执行子目录里的CMakeLists.txt
add_subdirectory(module1)
add_subdirectory(module2)

# 构建主程序，并链接子模块的库目标
add_executable(main_app main.cpp)
target_link_libraries(main_app PRIVATE module1 module2)

2. module1/CMakeLists.txt的优化写法 #

你原来的代码用了全局的include_directories和SRCS变量，这是旧风格写法，推荐改成目标导向的模式：

# 创建模块的库目标（STATIC为静态库，SHARED为动态库，按需选择）
add_library(module1 STATIC code.cpp code.h)

# 让依赖此模块的目标自动获取头文件路径，无需全局设置include_directories
target_include_directories(module1 PUBLIC ${CMAKE_CURRENT_LIST_DIR})

# 如果模块有额外依赖，可在这里添加，比如：
# target_link_libraries(module1 PRIVATE some_external_library)

3. module2/CMakeLists.txt的类似写法 #

add_library(module2 STATIC code2.cpp)
# 如果module2有头文件，同样添加头文件路径配置：
# target_include_directories(module2 PUBLIC ${CMAKE_CURRENT_LIST_DIR})

这种写法的优势 #

• 模块化隔离：每个模块的CMake配置只负责自身目标，变量不会互相干扰，避免了全局变量带来的隐患。
• 依赖自动传递：通过target_include_directories的PUBLIC参数，主程序在链接module1时会自动继承其头文件路径，无需在根目录重复配置。
• 可扩展性强：后续新增或修改模块时，不会影响其他部分的代码结构，维护成本更低。

如果你之前用include是为了收集所有源文件到SRCS变量统一编译，那这种目标导向的写法其实更灵活——每个模块编译为独立库，主程序仅需链接这些库即可，这也是现代CMake的最佳实践。

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