3、构建与运行：out-of-source构建、cmake命令与构建工具的关系、Debug与Release模式
这一章我们聊聊构建这件事。说白了，就是把你的源代码变成可执行文件的那一步。很多新手在这上面栽跟头，我当年也没少吃亏。今天我把几个关键点掰开揉碎了讲清楚。
3.1 为什么一定要用 out-of-source 构建？
先问一个问题：你见过有人直接在源码目录里跑 cmake 吗？
嗯，我见过。而且我自己刚开始学 CMake 时就这么干过。结果呢？源码目录里混了一堆 CMakeFiles、CMakeCache.txt、Makefile……想清理都无从下手。这就是所谓的 in-source 构建。
out-of-source 构建，就是另建一个目录来放构建产物。比如：
mkdir build
cd build
cmake ..
make这样你的源码目录干干净净。所有临时文件、目标文件、可执行文件，全在 build 里。想重来？直接 rm -rf build 就行。
核心原则：永远不要在源码目录里构建。这是 CMake 社区的共识，也是我踩坑后的血泪教训。
我在项目中遇到过一位同事，他把 build 目录建在了项目根目录下，但忘了加 .gitignore。结果 git status 一看，几千个文件待提交……嗯，从那以后他再也不敢 in-source 了。
3.2 cmake 命令到底干了什么？
cmake 命令本身不编译代码。它只做一件事：生成构建系统的配置文件。
你执行 cmake .. 时，它读取 CMakeLists.txt，然后根据你的平台和工具链，生成对应的构建文件。比如在 Linux 上默认生成 Makefile，在 Windows 上可能生成 Visual Studio 的 .sln 文件。
我个人习惯把 cmake 命令分成两步理解：
- 配置阶段（Configure）：cmake 解析 CMakeLists.txt，检查依赖，生成构建规则。
- 生成阶段（Generate）：根据配置结果，写出具体的构建文件（Makefile 或 build.ninja）。
你可以用 -S 和 -B 参数来指定源码目录和构建目录，这样更清晰：
cmake -S . -B build这等价于先 mkdir build 再 cd build && cmake ..。我个人更推荐这种写法，少敲两行命令。
3.3 Makefile 与 Ninja：谁更快？
cmake 生成完构建文件后，真正的编译工作交给构建工具。最常见的是 Make 和 Ninja。
Make 是经典工具，几乎每个 Linux 系统都自带。Ninja 是后起之秀，设计目标就是快。
| 特性 | Make | Ninja |
|---|---|---|
| 生成速度 | 较慢（解析 Makefile 有开销） | 极快（二进制格式） |
| 增量构建 | 依赖时间戳，有时不准 | 依赖文件内容哈希，更可靠 |
| 并行构建 | 支持（-j 参数） | 默认自动并行 |
| 跨平台 | Linux 原生，Windows 需额外安装 | 全平台支持 |
| 调试友好 | 错误信息可读性一般 | 错误信息更简洁 |
我曾经在一个大项目里用 Make，增量构建要等 40 秒。换成 Ninja 后，降到 5 秒以内。你想想看，每次改一行代码都要等半分钟，一天下来浪费多少时间？
用 Ninja 也很简单，cmake 时指定生成器就行：
cmake -S . -B build -G Ninja
cmake --build build注意：Ninja 需要单独安装。不过现在很多 IDE（比如 CLion、VS Code）默认就用 Ninja 了。
小技巧：如果你不确定当前系统有哪些生成器，可以执行 cmake --help，列表里会显示所有可用的生成器。
3.4 Debug 与 Release 模式：不只是优化级别
很多新手以为 Debug 和 Release 只是 -O0 和 -O2 的区别。其实远不止这些。
CMake 提供了几个预设的配置类型：
- Debug：无优化，包含调试符号（-g），适合断点调试。
- Release：高优化（-O3），去掉调试符号，适合发布。
- RelWithDebInfo：优化 + 调试符号，适合线上问题排查。
- MinSizeRel：优化体积（-Os），适合嵌入式或存储受限场景。
设置方式很简单：
cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build或者用 --config 参数（多配置生成器如 Visual Studio 需要）：
cmake --build build --config Release这里有个坑：单配置生成器（Makefile、Ninja）只能同时存在一种构建类型。你如果想同时保留 Debug 和 Release 的构建产物，就得建两个 build 目录：
cmake -S . -B build_debug -DCMAKE_BUILD_TYPE=Debug
cmake -S . -B build_release -DCMAKE_BUILD_TYPE=Release多配置生成器（Visual Studio、Xcode）则可以在同一个 build 目录里切换配置。
我曾经踩过的坑：在 Linux 上用 Ninja，忘了设 CMAKE_BUILD_TYPE，默认是空字符串。结果编译出来的东西既没有优化也没有调试符号，两边不讨好。后来我养成了习惯，每次 cmake 都显式指定构建类型。
3.5 构建类型对代码的影响
构建类型不只是影响编译器参数，还会影响代码本身。CMake 会根据构建类型定义一些宏：
NDEBUG：Release 模式下定义，会禁用 assert()。_DEBUG：某些编译器在 Debug 模式下定义。
你可以利用这些宏做条件编译：
#ifdef NDEBUG
// Release 模式下执行的代码
printf("Release build\n");
#else
// Debug 模式下执行的代码
printf("Debug build, assertions enabled\n");
#endif我个人习惯在 Debug 模式下加一些额外的日志和检查，Release 模式下去掉。这样既保证了开发效率，又保证了发布性能。
3.6 一个完整的构建流程示例
把上面讲的串起来，一个典型的构建流程是这样的：
# 1. 配置阶段，指定生成器和构建类型
cmake -S . -B build_debug -G Ninja -DCMAKE_BUILD_TYPE=Debug
# 2. 构建阶段，实际编译
cmake --build build_debug
# 3. 运行测试（如果有）
cd build_debug && ctest
# 4. 发布时，用 Release 模式重新构建
cmake -S . -B build_release -G Ninja -DCMAKE_BUILD_TYPE=Release
cmake --build build_release你想想看，这样是不是很清晰？源码目录始终干净，不同构建类型互不干扰，想删哪个 build 目录直接 rm 就行。
总结一下本章要点：
- 永远用 out-of-source 构建，建一个 build 目录
- cmake 只负责生成构建文件，真正的编译交给 Make 或 Ninja
- Ninja 比 Make 快，建议优先使用
- Debug 和 Release 不只是优化级别，还影响宏定义和调试信息
- 单配置生成器需要为每种构建类型建单独的 build 目录
下一章我们会聊 CMake 的变量系统。说实话，变量是 CMake 里最容易让人迷惑的部分之一。我当年花了不少时间才理清楚作用域和缓存变量的关系。到时候我会把那些坑一个个指出来。