简介这份资源面向具备一定C基础、希望掌握大型工程构建管理的开发者聚焦CMakeLists.txt在实际项目中的组织与运用。内容围绕项目初始化、子目录划分、目标属性设置、外部依赖查找、CTest测试集成、安装部署及可配置选项等核心环节展开帮助读者理解如何用统一方式管理跨平台构建流程解决工程规模扩大后编译配置混乱、依赖难以维护的问题。资源包共10个文件包含5个txt说明文档、3个cpp源文件与2个h头文件压缩后约5KB体量轻巧便于快速浏览与本地验证。目录按common、io等模块拆分并配有顶层与子级CMakeLists.txt直观呈现多目录工程的构建组织方式。目前已有1423人学习下载适合作为CMake入门到进阶的参考实例也可用于对照梳理自身项目的构建脚本结构。1. 从一份“编译五分钟报错两千行”的工程说起如果你维护过一个超过 200 个源文件的 C 工程大概率经历过这种场景改了一行头文件make跑起来像在抽奖运气好三分钟编完运气不好满屏模板报错翻到第一行才发现是某个子目录的CMakeLists.txt里target_link_libraries顺序写反了。这份资源就是冲着这类问题来的——它是一套用 CMakeLists 管理大型 C 工程的完整实例覆盖多目录分层、库目标拆分、第三方依赖引入、编译选项统一管理这些真实工程里绕不开的环节。适合两类人一是刚接手公司遗留 CMake 工程、被include_directories和target_include_directories搞混的开发者二是想把自己那个“一个 CMakeLists 写到底”的小项目重构成可维护结构的人。下面按“先看清结构、再跑起来、最后动手改”的顺序拆。2. 工程骨架拆解目录分层与 target 依赖关系2.1 顶层 CMakeLists 只做三件事大型工程和玩具工程最大的区别是顶层CMakeLists.txt不该出现任何add_executable的具体源文件列表。这份实例的顶层文件干净得有点反直觉核心就三块声明最低版本与项目名、设置全局编译标准、用add_subdirectory把子目录拉进来。cmake_minimum_required(VERSION 3.16) project(BigProj LANGUAGES CXX) # 全局标准避免每个子目录重复写 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) # 统一输出目录产物不再散落在各子目录 set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) # 只负责“拉人”不负责“干活” add_subdirectory(src) add_subdirectory(third_party)逻辑说明CMAKE_CXX_EXTENSIONS OFF这行容易被忽略它关掉-stdgnu17里的 GNU 扩展保证代码在 GCC 和 Clang 下行为一致。CMAKE_RUNTIME_OUTPUT_DIRECTORY设成绝对路径很关键如果写相对路径CMake 会把它拼到每个子目录的构建目录下最后你在build/里找可执行文件得翻半天。参数上VERSION 3.16是target_link_options等命令比较稳的起点再低会缺一些现代 target 属性。2.2 子目录用 target 而不是全局变量老式写法喜欢在顶层include_directories(include)然后所有子目录共享。这份实例走的是现代 CMake 路线每个模块自己声明对外暴露的头文件路径用target_include_directories带PUBLIC/PRIVATE修饰。# src/core/CMakeLists.txt add_library(core STATIC core.cpp logger.cpp ) # 只有 core 自己需要的头文件用 PRIVATE target_include_directories(core PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/internal ) # 外部使用者需要的头文件用 PUBLIC target_include_directories(core PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include ) target_compile_options(core PRIVATE -Wall -Wextra)逻辑说明PUBLIC和PRIVATE的区别是这份实例最值得抄的地方。PUBLIC会把路径传递给链接core的目标PRIVATE只在本目标编译时生效。常见翻车点是给内部实现头文件加了PUBLIC结果上层模块能直接#include到不该暴露的类编译能过但架构已经烂了。target_compile_options加PRIVATE也是同理警告选项不该污染下游。2.3 依赖关系用 target_link_libraries 显式表达模块之间的依赖不靠目录顺序靠链接关系。app依赖core和network就明确写出来CMake 会自动推导编译顺序。# src/app/CMakeLists.txt add_executable(app main.cpp) target_link_libraries(app PRIVATE core network )逻辑说明这里PRIVATE表示app是最终可执行文件不需要把core的接口再传给谁。如果是库依赖库比如network依赖core那network的CMakeLists里应该写target_link_libraries(network PUBLIC core)因为network的头文件里可能引用了core的类型使用者也得能看到core的头文件路径。这个PUBLIC/PRIVATE的传递规则是大型工程里最容易埋雷的地方写错了要么编译报“找不到头文件”要么链接报“undefined reference”。3. 跑起来从零构建与常见编译配置3.1 标准构建流程与目录约定拿到工程后第一步永远是 out-of-source 构建别在源码目录里直接cmake .否则生成的CMakeCache.txt和CMakeFiles会污染源码树清理起来很烦。# 在工程根目录执行 cmake -S . -B build -DCMAKE_BUILD_TYPERelease cmake --build build -j$(nproc)逻辑说明-S .指定源码目录-B build指定构建目录这是 CMake 3.13 之后推荐的写法比mkdir build cd build cmake ..更清晰。-DCMAKE_BUILD_TYPERelease会带上-O2 -DNDEBUG调试阶段换成Debug会加-g且不优化方便断点。-j$(nproc)在 Linux 下按 CPU 核数并行编译Windows 的 MSVC 用cmake --build build --config Release即可因为 MSVC 是多配置生成器CMAKE_BUILD_TYPE对它无效。3.2 第三方依赖的两种接法大型工程躲不开第三方库。这份实例里third_party目录下演示了两种常见接法一种是库已经装在系统里用find_package找另一种是源码直接放进工程用add_subdirectory编。# third_party/CMakeLists.txt find_package(Threads REQUIRED) find_package(OpenSSL REQUIRED) # 源码内嵌的第三方库 add_subdirectory(jsoncpp)逻辑说明find_package(Threads REQUIRED)是找系统线程库的标准做法之后用Threads::Threads这个 imported target 链接即可不用手写-lpthread。OpenSSL::SSL和OpenSSL::Crypto同理。源码内嵌的方式适合那些没有系统包、或者你需要改源码的库缺点是每次全量编译都会带上它构建时间变长。常见做法是给内嵌库单独设EXCLUDE_FROM_ALL只在被依赖时才编。3.3 编译选项的集中管理不同编译器对警告和优化的支持不一样直接写-Wall在 MSVC 下会报错。这份实例用生成器表达式做了区分。# cmake/CompilerWarnings.cmake function(set_project_warnings target) set(GCC_CLANG_WARNINGS -Wall -Wextra -Wpedantic -Wshadow -Wnon-virtual-dtor ) set(MSVC_WARNINGS /W4 /permissive-) if(MSVC) target_compile_options(${target} PRIVATE ${MSVC_WARNINGS}) else() target_compile_options(${target} PRIVATE ${GCC_CLANG_WARNINGS}) endif() endfunction()逻辑说明把警告选项封装成函数每个模块include后调用set_project_warnings(core)避免重复。-Wshadow能抓出变量遮蔽-Wnon-virtual-dtor能抓出基类析构非虚的问题这两个在大型工程里价值很高。/permissive-是 MSVC 下关闭宽松模式让标准符合度更接近 GCC。参数上如果某个第三方头文件触发大量警告可以用SYSTEM关键字把它标记为系统头target_include_directories(x SYSTEM PUBLIC ...)这样警告就不会从它里面冒出来。4. 避坑与排查CMake 工程里最容易翻车的几件事4.1 改了 CMakeLists 但构建没反应现象修改了某个子目录的CMakeLists.txt重新cmake --build后行为没变。原因CMake 的构建系统会检测CMakeLists.txt的时间戳并自动重新生成但如果你改的是被include()进来的.cmake模块文件且没有在顶层用CMAKE_CONFIGURE_DEPENDS声明它不会触发重配。解决在顶层加set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${CMAKE_SOURCE_DIR}/cmake/CompilerWarnings.cmake)或者干脆删掉build/CMakeCache.txt重新配置。4.2 链接顺序导致的 undefined reference现象target_link_libraries(app PRIVATE core network)报undefined reference to network::foo但network明明编出来了。原因静态库链接顺序敏感如果core依赖network里的符号而core写在network前面链接器扫过core时还没看到network符号就丢了。解决用 target 依赖关系让 CMake 自动排序——在core的CMakeLists里写target_link_libraries(core PUBLIC network)然后app只链接coreCMake 会按依赖图排出正确顺序。这也是现代 CMake 比手写-l顺序强的地方。4.3 头文件路径用相对路径导致 IDE 跳转失效现象target_include_directories(core PUBLIC include)在命令行能编过但在 CLion 或 VSCode 里#include core/logger.h标红。原因相对路径是相对于CMAKE_CURRENT_SOURCE_DIR解析的但 IDE 的索引器有时解析基准不同。解决统一用${CMAKE_CURRENT_SOURCE_DIR}/include这种绝对路径写法虽然啰嗦但稳定。另一个常见原因是PUBLIC和INTERFACE混用如果头文件只在接口层面需要用INTERFACE而不是PUBLIC。4.4 Debug 和 Release 混用导致 ABI 不兼容现象Debug 版的可执行文件链接 Release 版的库运行时报std::string相关的崩溃或_ITERATOR_DEBUG_LEVEL不匹配。原因MSVC 下 Debug 和 Release 的 STL 容器布局不同GCC 下-D_GLIBCXX_DEBUG也会改变 ABI。解决确保所有目标用同一个CMAKE_BUILD_TYPE构建不要手动混用不同配置的产物。如果必须混用target_compile_definitions显式对齐_ITERATOR_DEBUG_LEVEL但这属于下策能统一就统一。4.5 全量重编时间过长现象改一个头文件整个工程重编十分钟起步。原因头文件被大量源文件包含且没有做前置声明或 PIMPL 隔离。解决CMake 层面能做的有限但可以用ccache加速——在顶层加find_program(CCACHE ccache)然后set(CMAKE_CXX_COMPILER_LAUNCHER ${CCACHE})。另外把不常变的第三方库编成静态库后install到本地前缀用find_package引入避免每次全量编。工程结构上把稳定接口的头文件收窄减少传递包含。5. 二次开发把这套骨架改成你自己的工程5.1 替换模块的实操步骤假设你要把这套实例改成一个图像处理工程模块从core/network/app换成image/filter/cli。第一步改顶层add_subdirectory列表第二步在每个新模块目录下建CMakeLists.txt照抄add_librarytarget_include_directoriestarget_link_libraries三件套。关键是依赖方向要单向cli依赖filterfilter依赖image不要出现反向依赖。如果filter需要回调cli里的东西用接口类或std::function注入而不是让filter链接cli。# src/filter/CMakeLists.txt add_library(filter STATIC gaussian.cpp sobel.cpp ) target_include_directories(filter PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include) target_link_libraries(filter PUBLIC image) set_project_warnings(filter)逻辑说明PUBLIC image表示filter的头文件里用到了image的类型使用者也得能看到image的头文件路径。set_project_warnings(filter)是前面封装的函数一行搞定警告配置。新增模块时只要保证add_subdirectory在顶层被调用且依赖关系写对CMake 会自动处理编译顺序。5.2 用 install 和 export 做库的分发如果你想把某个模块单独发给别人用需要加install规则。这份实例里演示了基本的安装配置。# src/core/CMakeLists.txt 末尾追加 install(TARGETS core EXPORT coreTargets ARCHIVE DESTINATION lib PUBLIC_HEADER DESTINATION include/core ) install(FILES include/core/logger.h DESTINATION include/core) install(EXPORT coreTargets FILE coreConfig.cmake NAMESPACE core:: DESTINATION lib/cmake/core )逻辑说明EXPORT会把 target 的接口信息头文件路径、链接依赖写进coreConfig.cmake别人find_package(core)后就能直接用core::core这个 target不用手写include_directories。NAMESPACE core::是惯例避免 target 名冲突。PUBLIC_HEADER需要配合set_target_properties(core PROPERTIES PUBLIC_HEADER include/core/logger.h)使用或者像上面那样单独install(FILES ...)。这一步做完你的库就有了和系统库一样的接入体验。5.3 一个我常踩的坑变量作用域CMake 的变量作用域是目录级的子目录里set(FOO bar)不会影响父目录除非用set(FOO bar PARENT_SCOPE)。我早期重构时在子目录里设了CMAKE_CXX_FLAGS结果只有那个子目录生效其他模块还是老样子排查了半天。从那以后我每次改全局编译选项都强制走target_compile_options而不是CMAKE_CXX_FLAGS因为 target 属性是跟着目标走的不受目录作用域影响。另一个习惯是任何跨目录传递的信息要么用 target 属性要么用PARENT_SCOPE显式声明绝不依赖隐式的变量继承。这套实例里所有编译选项都挂在 target 上就是为了避开这个玄学问题。如果你手头正好有一个结构混乱的 C 工程建议先拿这份实例的目录骨架对照一遍把include_directories全部换成target_include_directories把link_libraries换成target_link_libraries编译报错会逼你把依赖关系理清楚。改完再跑一次全量构建看看时间有没有变化通常会有惊喜。希望帮到你。本文还有配套的精品资源点击获取 CMake大型C++工程实战：多目录分层与target依赖管理
简介这份资源面向具备一定C基础、希望掌握大型工程构建管理的开发者聚焦CMakeLists.txt在实际项目中的组织与运用。内容围绕项目初始化、子目录划分、目标属性设置、外部依赖查找、CTest测试集成、安装部署及可配置选项等核心环节展开帮助读者理解如何用统一方式管理跨平台构建流程解决工程规模扩大后编译配置混乱、依赖难以维护的问题。资源包共10个文件包含5个txt说明文档、3个cpp源文件与2个h头文件压缩后约5KB体量轻巧便于快速浏览与本地验证。目录按common、io等模块拆分并配有顶层与子级CMakeLists.txt直观呈现多目录工程的构建组织方式。目前已有1423人学习下载适合作为CMake入门到进阶的参考实例也可用于对照梳理自身项目的构建脚本结构。1. 从一份“编译五分钟报错两千行”的工程说起如果你维护过一个超过 200 个源文件的 C 工程大概率经历过这种场景改了一行头文件make跑起来像在抽奖运气好三分钟编完运气不好满屏模板报错翻到第一行才发现是某个子目录的CMakeLists.txt里target_link_libraries顺序写反了。这份资源就是冲着这类问题来的——它是一套用 CMakeLists 管理大型 C 工程的完整实例覆盖多目录分层、库目标拆分、第三方依赖引入、编译选项统一管理这些真实工程里绕不开的环节。适合两类人一是刚接手公司遗留 CMake 工程、被include_directories和target_include_directories搞混的开发者二是想把自己那个“一个 CMakeLists 写到底”的小项目重构成可维护结构的人。下面按“先看清结构、再跑起来、最后动手改”的顺序拆。2. 工程骨架拆解目录分层与 target 依赖关系2.1 顶层 CMakeLists 只做三件事大型工程和玩具工程最大的区别是顶层CMakeLists.txt不该出现任何add_executable的具体源文件列表。这份实例的顶层文件干净得有点反直觉核心就三块声明最低版本与项目名、设置全局编译标准、用add_subdirectory把子目录拉进来。cmake_minimum_required(VERSION 3.16) project(BigProj LANGUAGES CXX) # 全局标准避免每个子目录重复写 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) # 统一输出目录产物不再散落在各子目录 set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) # 只负责“拉人”不负责“干活” add_subdirectory(src) add_subdirectory(third_party)逻辑说明CMAKE_CXX_EXTENSIONS OFF这行容易被忽略它关掉-stdgnu17里的 GNU 扩展保证代码在 GCC 和 Clang 下行为一致。CMAKE_RUNTIME_OUTPUT_DIRECTORY设成绝对路径很关键如果写相对路径CMake 会把它拼到每个子目录的构建目录下最后你在build/里找可执行文件得翻半天。参数上VERSION 3.16是target_link_options等命令比较稳的起点再低会缺一些现代 target 属性。2.2 子目录用 target 而不是全局变量老式写法喜欢在顶层include_directories(include)然后所有子目录共享。这份实例走的是现代 CMake 路线每个模块自己声明对外暴露的头文件路径用target_include_directories带PUBLIC/PRIVATE修饰。# src/core/CMakeLists.txt add_library(core STATIC core.cpp logger.cpp ) # 只有 core 自己需要的头文件用 PRIVATE target_include_directories(core PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/internal ) # 外部使用者需要的头文件用 PUBLIC target_include_directories(core PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include ) target_compile_options(core PRIVATE -Wall -Wextra)逻辑说明PUBLIC和PRIVATE的区别是这份实例最值得抄的地方。PUBLIC会把路径传递给链接core的目标PRIVATE只在本目标编译时生效。常见翻车点是给内部实现头文件加了PUBLIC结果上层模块能直接#include到不该暴露的类编译能过但架构已经烂了。target_compile_options加PRIVATE也是同理警告选项不该污染下游。2.3 依赖关系用 target_link_libraries 显式表达模块之间的依赖不靠目录顺序靠链接关系。app依赖core和network就明确写出来CMake 会自动推导编译顺序。# src/app/CMakeLists.txt add_executable(app main.cpp) target_link_libraries(app PRIVATE core network )逻辑说明这里PRIVATE表示app是最终可执行文件不需要把core的接口再传给谁。如果是库依赖库比如network依赖core那network的CMakeLists里应该写target_link_libraries(network PUBLIC core)因为network的头文件里可能引用了core的类型使用者也得能看到core的头文件路径。这个PUBLIC/PRIVATE的传递规则是大型工程里最容易埋雷的地方写错了要么编译报“找不到头文件”要么链接报“undefined reference”。3. 跑起来从零构建与常见编译配置3.1 标准构建流程与目录约定拿到工程后第一步永远是 out-of-source 构建别在源码目录里直接cmake .否则生成的CMakeCache.txt和CMakeFiles会污染源码树清理起来很烦。# 在工程根目录执行 cmake -S . -B build -DCMAKE_BUILD_TYPERelease cmake --build build -j$(nproc)逻辑说明-S .指定源码目录-B build指定构建目录这是 CMake 3.13 之后推荐的写法比mkdir build cd build cmake ..更清晰。-DCMAKE_BUILD_TYPERelease会带上-O2 -DNDEBUG调试阶段换成Debug会加-g且不优化方便断点。-j$(nproc)在 Linux 下按 CPU 核数并行编译Windows 的 MSVC 用cmake --build build --config Release即可因为 MSVC 是多配置生成器CMAKE_BUILD_TYPE对它无效。3.2 第三方依赖的两种接法大型工程躲不开第三方库。这份实例里third_party目录下演示了两种常见接法一种是库已经装在系统里用find_package找另一种是源码直接放进工程用add_subdirectory编。# third_party/CMakeLists.txt find_package(Threads REQUIRED) find_package(OpenSSL REQUIRED) # 源码内嵌的第三方库 add_subdirectory(jsoncpp)逻辑说明find_package(Threads REQUIRED)是找系统线程库的标准做法之后用Threads::Threads这个 imported target 链接即可不用手写-lpthread。OpenSSL::SSL和OpenSSL::Crypto同理。源码内嵌的方式适合那些没有系统包、或者你需要改源码的库缺点是每次全量编译都会带上它构建时间变长。常见做法是给内嵌库单独设EXCLUDE_FROM_ALL只在被依赖时才编。3.3 编译选项的集中管理不同编译器对警告和优化的支持不一样直接写-Wall在 MSVC 下会报错。这份实例用生成器表达式做了区分。# cmake/CompilerWarnings.cmake function(set_project_warnings target) set(GCC_CLANG_WARNINGS -Wall -Wextra -Wpedantic -Wshadow -Wnon-virtual-dtor ) set(MSVC_WARNINGS /W4 /permissive-) if(MSVC) target_compile_options(${target} PRIVATE ${MSVC_WARNINGS}) else() target_compile_options(${target} PRIVATE ${GCC_CLANG_WARNINGS}) endif() endfunction()逻辑说明把警告选项封装成函数每个模块include后调用set_project_warnings(core)避免重复。-Wshadow能抓出变量遮蔽-Wnon-virtual-dtor能抓出基类析构非虚的问题这两个在大型工程里价值很高。/permissive-是 MSVC 下关闭宽松模式让标准符合度更接近 GCC。参数上如果某个第三方头文件触发大量警告可以用SYSTEM关键字把它标记为系统头target_include_directories(x SYSTEM PUBLIC ...)这样警告就不会从它里面冒出来。4. 避坑与排查CMake 工程里最容易翻车的几件事4.1 改了 CMakeLists 但构建没反应现象修改了某个子目录的CMakeLists.txt重新cmake --build后行为没变。原因CMake 的构建系统会检测CMakeLists.txt的时间戳并自动重新生成但如果你改的是被include()进来的.cmake模块文件且没有在顶层用CMAKE_CONFIGURE_DEPENDS声明它不会触发重配。解决在顶层加set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${CMAKE_SOURCE_DIR}/cmake/CompilerWarnings.cmake)或者干脆删掉build/CMakeCache.txt重新配置。4.2 链接顺序导致的 undefined reference现象target_link_libraries(app PRIVATE core network)报undefined reference to network::foo但network明明编出来了。原因静态库链接顺序敏感如果core依赖network里的符号而core写在network前面链接器扫过core时还没看到network符号就丢了。解决用 target 依赖关系让 CMake 自动排序——在core的CMakeLists里写target_link_libraries(core PUBLIC network)然后app只链接coreCMake 会按依赖图排出正确顺序。这也是现代 CMake 比手写-l顺序强的地方。4.3 头文件路径用相对路径导致 IDE 跳转失效现象target_include_directories(core PUBLIC include)在命令行能编过但在 CLion 或 VSCode 里#include core/logger.h标红。原因相对路径是相对于CMAKE_CURRENT_SOURCE_DIR解析的但 IDE 的索引器有时解析基准不同。解决统一用${CMAKE_CURRENT_SOURCE_DIR}/include这种绝对路径写法虽然啰嗦但稳定。另一个常见原因是PUBLIC和INTERFACE混用如果头文件只在接口层面需要用INTERFACE而不是PUBLIC。4.4 Debug 和 Release 混用导致 ABI 不兼容现象Debug 版的可执行文件链接 Release 版的库运行时报std::string相关的崩溃或_ITERATOR_DEBUG_LEVEL不匹配。原因MSVC 下 Debug 和 Release 的 STL 容器布局不同GCC 下-D_GLIBCXX_DEBUG也会改变 ABI。解决确保所有目标用同一个CMAKE_BUILD_TYPE构建不要手动混用不同配置的产物。如果必须混用target_compile_definitions显式对齐_ITERATOR_DEBUG_LEVEL但这属于下策能统一就统一。4.5 全量重编时间过长现象改一个头文件整个工程重编十分钟起步。原因头文件被大量源文件包含且没有做前置声明或 PIMPL 隔离。解决CMake 层面能做的有限但可以用ccache加速——在顶层加find_program(CCACHE ccache)然后set(CMAKE_CXX_COMPILER_LAUNCHER ${CCACHE})。另外把不常变的第三方库编成静态库后install到本地前缀用find_package引入避免每次全量编。工程结构上把稳定接口的头文件收窄减少传递包含。5. 二次开发把这套骨架改成你自己的工程5.1 替换模块的实操步骤假设你要把这套实例改成一个图像处理工程模块从core/network/app换成image/filter/cli。第一步改顶层add_subdirectory列表第二步在每个新模块目录下建CMakeLists.txt照抄add_librarytarget_include_directoriestarget_link_libraries三件套。关键是依赖方向要单向cli依赖filterfilter依赖image不要出现反向依赖。如果filter需要回调cli里的东西用接口类或std::function注入而不是让filter链接cli。# src/filter/CMakeLists.txt add_library(filter STATIC gaussian.cpp sobel.cpp ) target_include_directories(filter PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/include) target_link_libraries(filter PUBLIC image) set_project_warnings(filter)逻辑说明PUBLIC image表示filter的头文件里用到了image的类型使用者也得能看到image的头文件路径。set_project_warnings(filter)是前面封装的函数一行搞定警告配置。新增模块时只要保证add_subdirectory在顶层被调用且依赖关系写对CMake 会自动处理编译顺序。5.2 用 install 和 export 做库的分发如果你想把某个模块单独发给别人用需要加install规则。这份实例里演示了基本的安装配置。# src/core/CMakeLists.txt 末尾追加 install(TARGETS core EXPORT coreTargets ARCHIVE DESTINATION lib PUBLIC_HEADER DESTINATION include/core ) install(FILES include/core/logger.h DESTINATION include/core) install(EXPORT coreTargets FILE coreConfig.cmake NAMESPACE core:: DESTINATION lib/cmake/core )逻辑说明EXPORT会把 target 的接口信息头文件路径、链接依赖写进coreConfig.cmake别人find_package(core)后就能直接用core::core这个 target不用手写include_directories。NAMESPACE core::是惯例避免 target 名冲突。PUBLIC_HEADER需要配合set_target_properties(core PROPERTIES PUBLIC_HEADER include/core/logger.h)使用或者像上面那样单独install(FILES ...)。这一步做完你的库就有了和系统库一样的接入体验。5.3 一个我常踩的坑变量作用域CMake 的变量作用域是目录级的子目录里set(FOO bar)不会影响父目录除非用set(FOO bar PARENT_SCOPE)。我早期重构时在子目录里设了CMAKE_CXX_FLAGS结果只有那个子目录生效其他模块还是老样子排查了半天。从那以后我每次改全局编译选项都强制走target_compile_options而不是CMAKE_CXX_FLAGS因为 target 属性是跟着目标走的不受目录作用域影响。另一个习惯是任何跨目录传递的信息要么用 target 属性要么用PARENT_SCOPE显式声明绝不依赖隐式的变量继承。这套实例里所有编译选项都挂在 target 上就是为了避开这个玄学问题。如果你手头正好有一个结构混乱的 C 工程建议先拿这份实例的目录骨架对照一遍把include_directories全部换成target_include_directories把link_libraries换成target_link_libraries编译报错会逼你把依赖关系理清楚。改完再跑一次全量构建看看时间有没有变化通常会有惊喜。希望帮到你。本文还有配套的精品资源点击获取