从”图纸”到”砖瓦”：把代码交给CMake
上一节，我们认识了CMake里的各种”建筑蓝图”——目标（Target）。知道了CMake能帮我们建造可执行文件、静态库、动态库等多种建筑。但光有图纸没用，接下来最实际的问题是：建筑材料（源文件）从哪来？怎么运进工地？怎么堆才不会乱？
在本节中，我们将聚焦于源文件管理。这是从”Hello World”迈向真实项目的第一道门槛。你会学到如何优雅地组织.cpp和.h文件，如何告诉编译器去哪找头文件，以及如何利用现代CMake的一些”黑科技”来加速编译。别担心，哪怕你的项目现在只有两三个文件，这一节的内容也会帮你打下坚实的工程化基础。
显式列出源文件：最朴素也最可靠的方式
让我们先从最”笨”也最推荐的方法说起：手动把每个源文件列出来。
很多初学者第一次写CMake时，会这样写：
add_executable(my_app main.cpp utils.cpp helper.cpp)当文件变多以后，更好的做法是用一个变量把它们装起来，让CMakeLists.txt更易读：
set(SOURCES
src/main.cpp
src/utils.cpp
src/helper.cpp
src/math/calc.cpp
)
add_executable(my_app ${SOURCES})你可能会问：”文件多了以后，每新增一个文件就要手动改CMakeLists.txt，这多麻烦啊？”
确实麻烦一点，但这种方式有一个巨大的优势：确定性。CMake的构建系统能够精确追踪每个文件的依赖关系。当你修改了calc.cpp，CMake知道只需要重新编译这一个文件，其他文件不受影响。这种”增量构建”在大型项目里能节省大量时间。
小白建议：对于学习阶段和中小型项目，请养成手动列出源文件的习惯。这能帮你清晰地知道项目里到底有哪些代码在参与编译，避免”垃圾文件”混入构建。
自动搜集源文件：通配符的诱惑与陷阱
如果你实在不想手动维护文件列表，CMake也提供了”偷懒”的工具。但记住，偷懒是有代价的。
aux_source_directory：老牌但过时的方法
在早期CMake中，人们常用这个命令自动扫描目录下的源文件：
aux_source_directory(src DIR_SRCS)
add_executable(my_app ${DIR_SRCS})这会把src目录下所有.c和.cpp文件都收集到DIR_SRCS变量中。它的缺点很明显：不会递归子目录，而且一旦目录里有测试代码、临时文件，也会被稀里糊涂地编进去。
file(GLOB)：更灵活的通配符
更现代一点的”偷懒”方式是使用file(GLOB)：
file(GLOB SOURCES "src/*.cpp")
file(GLOB_RECURSE SOURCES "src/*.cpp") # 递归所有子目录
add_executable(my_app ${SOURCES})看着很美好，对吧？新增一个.cpp文件，似乎不用改CMakeLists.txt了。但这里藏着一个大坑：
CMake的构建流程分为配置（Configure）和构建（Build）两个阶段。file(GLOB)只在配置阶段执行一次。这意味着，如果你在构建过程中新增了一个源文件，CMake并不会自动感知到！你必须手动重新运行cmake -B build，新文件才会被纳入编译。如果你忘了这一步，就会遇到”明明加了文件，却链接不上”的诡异问题。
另外，自动搜集可能会把你不希望编译的文件（比如某些平台特定的代码）也抓进来，导致编译失败。
结论：file(GLOB)可以用在快速原型、小型示例或自动生成的项目中，但在正式项目中，显式列出文件仍然是首选。
头文件处理与包含目录
C++项目离不开头文件（.h或.hpp）。编译器需要知道去哪找这些头文件，这就要用到包含目录（Include Directories）。
在传统CMake中，你可能会看到这样的写法：
include_directories(include) # 不推荐！include_directories是一个全局命令，它会为之后定义的所有目标都添加这个头文件搜索路径。这就像在办公室里公放一个音箱，所有人被迫听同样的音乐——不管他们想不想听。
现代CMake推荐的是基于目标的包含目录：
target_include_directories(my_app PUBLIC include)这行代码的意思是：只有my_app这个目标知道要去include目录下找头文件，不会影响其他目标。但是，这里的PUBLIC又是什么意思呢？别急，这正是下一节的核心内容。
PRIVATE、PUBLIC、INTERFACE：CMake的”社交距离”
这是现代CMake中最重要也最容易混淆的概念之一。如果把目标比作人，把头文件/库比作”知识”，那么这三个关键字定义了知识的传播范围。
PRIVATE：我自己的，不告诉别人
假设你写了一个计算器库calc，它在内部实现时用到了一些复杂的数学公式，这些公式的头文件放在src/internal里。你不希望使用calc的人看到这些内部细节。
target_include_directories(calc PRIVATE src/internal)效果：src/internal只对calc自身可见。其他链接了calc的目标，看不到这个目录。
PUBLIC：我自己用，也告诉链接我的人
你的calc库对外提供的接口头文件放在include目录下。用户必须包含这些头文件才能使用你的库。
target_include_directories(calc PUBLIC include)效果：calc自己能找到这些头文件，同时任何链接了calc的目标（比如一个可执行文件app），也会自动获得include这个搜索路径。你不需要再给app单独写一遍。
INTERFACE：我自己不用，但告诉链接我的人
这看起来有点奇怪，什么时候会”自己不用但别人要用”呢？最典型的场景是接口库（Interface Library）。比如你定义了一个纯头文件的库，或者一个统一的编译配置集合：
add_library(my_warnings INTERFACE)
target_include_directories(my_warnings INTERFACE third_party/eigen)效果：my_warnings本身不需要编译，但任何链接了它的目标都会获得third_party/eigen的包含路径。
一张表记住它们
| 关键字 | 当前目标是否使用 | 链接该目标的目标是否继承 |
|---|---|---|
PRIVATE |
是 | 否 |
PUBLIC |
是 | 是 |
INTERFACE |
否 | 是 |
生活化比喻：
- PRIVATE就像你在家吃独食，不外传。
- PUBLIC就像你请朋友吃火锅，你吃，朋友也吃。
- INTERFACE就像你帮朋友点了一份外卖送到他家——你自己不吃，但朋友享受到了。
源文件分组：让IDE不再乱糟糟
当你的项目有几十个甚至上百个源文件时，在Visual Studio或Xcode等IDE里，它们可能会平铺显示在一个列表里，找起来非常痛苦。CMake提供了source_group命令，可以告诉IDE：”请按文件夹结构来显示这些文件”。
最方便的用法是配合TREE关键字（CMake 3.8+），让它自动根据磁盘目录结构生成IDE里的虚拟文件夹：
file(GLOB_RECURSE SOURCES "src/*.cpp" "include/*.h")
# 让IDE里的文件树和磁盘目录保持一致
source_group(TREE ${CMAKE_CURRENT_SOURCE_DIR} FILES ${SOURCES})
add_executable(my_app ${SOURCES})这样，你在Visual Studio的解决方案资源管理器里，就能看到清晰的src、include子目录结构，而不是一锅粥。
注意：这里只是用file(GLOB_RECURSE)来收集文件列表给source_group做展示用。你依然可以在add_executable中手动列出文件，两者并不冲突。
预编译头：给编译装上”加速器”
在大型C++项目中，你可能遇到过这样的烦恼：每个.cpp文件都要重复包含一堆不怎么会变的头文件（比如<iostream>、<vector>、<string>，或者第三方库如boost、Qt的头文件）。编译器每次都要重新解析这些庞然大物，非常浪费时间。
预编译头（Precompiled Headers, PCH）就是解决这个问题的一剂良药。它的思路是：把这些稳定的头文件先编译成一种中间格式，后续所有.cpp文件直接”坐享其成”，不用再重复解析。
在CMake 3.16及以上版本，你只需要一行代码：
target_precompile_headers(my_app PRIVATE
<iostream>
<vector>
<string>
"src/pch.h" # 也可以用自己的头文件
)CMake会自动处理背后的复杂逻辑：生成预编译头文件、确保编译器正确使用它、管理依赖关系。你不需要像旧时代那样手动写Makefile或VS项目配置。
使用建议：
- 只把稳定不常改动的头文件放进去。如果你把频繁修改的项目头文件放进PCH，反而会导致所有文件都被重新编译。
- 对于多目标项目，可以用
INTERFACE预编译头让多个目标共享同一套配置。
统一构建：Unity Build的”大力出奇迹”
如果你的项目编译速度还是太慢，CMake还提供了一个更激进的加速手段：Unity Build（统一构建）。
原理很简单：CMake会自动把多个.cpp文件合并成一个大文件，然后只编译一次。这样做的好处是：头文件只需要被解析一次，模板实例化也能合并，编译速度往往能有数倍提升。
开启方式极其简单（CMake 3.16+）：
set(CMAKE_UNITY_BUILD ON) # 全局开启
# 或者只针对某个目标
set_target_properties(my_app PROPERTIES UNITY_BUILD ON)默认情况下，CMake会把目标下的源文件每8个合并成一个Unity文件。你可以通过以下属性调整：
set_target_properties(my_app PROPERTIES
UNITY_BUILD ON
UNITY_BUILD_MODE BATCH # BATCH模式：按批次合并
UNITY_BUILD_BATCH_SIZE 16 # 每16个文件合并
)警告：Unity Build虽然快，但并不是银弹。由于多个文件被合并，以下问题可能会出现：
- 命名冲突：不同
.cpp文件里定义了同名的静态函数或全局变量，原本分开编译没事，合并后就冲突了。 - 宏污染：某个文件里定义的宏会影响后续被合并的文件。
- ODR（One Definition Rule）违规：内联函数或模板在不同文件中的定义不一致，合并后暴露。
如果某些文件不适合参与Unity Build，可以将它们排除：
set_source_files_properties(special.cpp PROPERTIES
SKIP_UNITY_BUILD_INCLUSION ON
)建议：Unity Build特别适合在CI/CD流水线中开启，用于快速验证代码；日常开发中，如果你的代码规范良好，也可以长期开启。
本节小结
源文件管理是CMake项目组织的基石。让我们回顾一下本节的核心要点：
- 显式列出源文件是最稳妥的做法，虽然稍显繁琐，但可控且利于增量构建。
- 自动搜集（
aux_source_directory、file(GLOB)）虽然省事，但可能导致新增文件需要重新配置的问题，生产环境慎用。 - 使用
target_include_directories代替全局的include_directories，是现代CMake的基本要求。 - 理解PRIVATE/PUBLIC/INTERFACE三种可见性，是掌握现代CMake依赖传播机制的关键。
- 利用
source_group可以让IDE里的文件目录赏心悦目。 - 预编译头和Unity Build是CMake提供的两大利器，能显著缓解大型项目的编译速度焦虑，但要了解其适用场景和潜在问题。
下一节，我们将继续深入”目标”的细节，探讨如何精细控制编译和链接选项——从编译器标志到链接库依赖，让你的CMake控制更加得心应手。
没有回复内容