CMakeLists怎么拆分子目录？-C++-PHP中文网

add_subdirectory 是 CMake 唯一支持真正作用域隔离的子目录构建方式；include 仅做内容粘贴，导致变量和 target 混杂、链接属性失控，而 add_subdirectory 启动新作用域，保障模块化可控性。

cmakelists怎么拆分子目录？

直接用 add_subdirectory，别想绕开它——这是 CMake 唯一支持的、能真正隔离作用域并构建子目录目标的标准方式。

为什么不能用 `include` 替代 `add_subdirectory`

include 只是把另一个 CMakeLists.txt 文件的内容“粘贴”进当前作用域，所有变量、target 定义都混在一起，根本起不到模块隔离效果。比如你在 src/utils/CMakeLists.txt 里写了 add_library(utils ...)，用 include(src/utils/CMakeLists.txt) 后，这个 utils 库就和顶层定义的 target 处于同一作用域，target_link_libraries 看起来能用，但一旦你加了 PRIVATE 或 INTERFACE，链接属性就全乱套了。

而 add_subdirectory 会启动一个新的作用域，子目录中定义的变量默认不可被父目录读取，target_link_libraries 也只允许链接当前作用域或上层作用域中定义的目标（不能反向跨级引用），这才是可控的模块化。

`add_subdirectory` 的三个参数怎么填才不踩坑

source_dir 必须存在且含 CMakeLists.txt；相对路径是相对于当前 CMakeLists.txt 所在目录，不是源码根目录
binary_dir 几乎不用显式指定——除非你要把构建产物强制落到某个非镜像路径（比如把 third_party/openssl 的构建输出统一放到 build/external/openssl）
EXCLUDE_FROM_ALL 要慎用：加了它，子目录里的 add_executable 或 add_library 默认不会被 make 或 cmake --build . 构建，除非被其他 target 显式依赖（比如 target_link_libraries(myapp PRIVATE openssl) 会触发 openssl 构建）

子目录里怎么暴露头文件和链接接口

子目录的 CMakeLists.txt 必须主动导出自己的接口，否则上层根本不知道怎么用它：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

用 target_include_directories(mylib PUBLIC include) 把头文件路径设为 PUBLIC，这样上层 target_link_libraries(myapp PRIVATE mylib) 后，myapp 就能自动找到 #include "mylib.h"
不要在子目录里写 include_directories(include) —— 这是全局污染，对依赖它的 target 没有约束力
如果子目录只提供头文件（如 fmt 这类 header-only 库），仍需定义一个 INTERFACE library：add_library(fmt INTERFACE)，再配 target_include_directories(fmt INTERFACE include)

常见错误现象和对应检查点

编译时报 Cannot find source file 或 target_link_libraries called with incorrect number of arguments，大概率是下面这几个地方错了：

子目录下漏了 CMakeLists.txt，或者文件名拼错成 CMakeList.txt 或 cmakelists.txt
上层 add_subdirectory(foo)，但实际路径是 src/foo，没写对相对路径
子目录中用了 add_executable，但上层没通过 target_link_libraries 或 add_dependencies 建立依赖关系，又没加 EXCLUDE_FROM_ALL，导致构建时找不到入口
头文件路径写成 #include "../include/mylib.h"，但子目录的 target_include_directories 没设对，或设成了 PRIVATE 而不是 PUBLIC