从Make到CMake：一场构建系统的进化之旅
说实话，我接触Makefile已经有十几年了。早期做嵌入式开发时，天天跟Makefile打交道，那时候觉得这东西挺顺手的。直到项目规模越来越大，跨平台需求越来越多，我才意识到——嗯，是时候考虑迁移到CMake了。
这一章，我想跟你聊聊从Make迁移到CMake的那些事。不是单纯地告诉你「CMake更好」，而是从实战角度出发，看看迁移策略、底层原理，以及两者混用的场景。
为什么需要迁移？
先说说我个人的体会。有一次，我接手一个老项目，Makefile有上千行。每个平台都要维护一套独立的规则，Linux一套，Windows一套，macOS还得单独处理。最要命的是，第三方库的依赖管理全靠手写路径，换个环境就崩。
你想想看，这种场景下，Makefile的短板就很明显了：
- 跨平台能力弱——每个平台都得写不同的Makefile
- 依赖管理原始——没有自动发现依赖的能力
- 配置不够灵活——Debug/Release切换要改很多地方
- 可读性差——上千行的Makefile，新人根本不敢动
CMake恰恰解决了这些问题。它不直接编译，而是生成构建文件。说白了，CMake是「构建系统的构建系统」。
迁移策略：别想着一步到位
我曾经犯过一个错误——试图一次性把所有Makefile都改成CMake。结果呢？项目停摆了整整两周，各种问题层出不穷。后来我学乖了，总结出一套渐进式迁移策略：
推荐的四步迁移法：
- 评估阶段——梳理现有Makefile的结构，标记出核心模块和第三方依赖
- 试点阶段——选一个独立模块，用CMake重写，验证流程
- 逐步替换——按模块逐个迁移，每个模块都做回归测试
- 全面切换——所有模块迁移完成后，移除旧的Makefile
这里有个小技巧：迁移期间，可以让CMake和Makefile共存。CMake生成的构建目录和原来的源码目录分开，互不干扰。
CMake生成Makefile的底层原理
很多人以为CMake就是「另一种写构建规则的方式」，其实不是。CMake的核心工作是——元构建。
来看个简单的例子：
# CMakeLists.txt
cmake_minimum_required(VERSION 3.10)
project(MyApp C)
add_executable(myapp main.c utils.c)
target_include_directories(myapp PRIVATE include)
当你执行 cmake -B build 时，CMake做了三件事：
- 解析CMakeLists.txt——构建出内部的依赖图
- 检测环境——找编译器、头文件、库路径
- 生成Makefile——把依赖图翻译成Makefile语法
生成的Makefile里，你会看到大量自动生成的变量和规则。比如 CMAKE_C_COMPILER 被展开成实际的编译器路径，CMAKE_C_FLAGS 包含了所有编译选项。
一个小实验：执行 cmake -B build --trace，你能看到CMake每一步在做什么。我调试复杂项目时经常用这个。
混合使用场景：CMake + Makefile 共存
实际项目中，完全抛弃Makefile并不现实。有些场景下，两者需要配合使用：
- 遗留模块——某些第三方库只提供Makefile，不想动它
- 特殊构建需求——比如某些嵌入式工具链，CMake支持不好
- 渐进迁移——新旧系统并行，互相调用
我常用的做法是：在CMake中通过 add_custom_target 或 ExternalProject_Add 调用外部的Makefile。
# 在CMake中调用外部Makefile
add_custom_target(external_lib
COMMAND $(MAKE) -C ${CMAKE_SOURCE_DIR}/third_party/libfoo
WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/third_party/libfoo
)
这样，CMake负责主项目的构建管理，而第三方库仍然用它们自己的Makefile。两不耽误。
性能对比数据
我整理了一份实际项目的对比数据。项目规模：约200个源文件，依赖5个第三方库。
| 场景 | Makefile（手写） | CMake生成Makefile | 差异 |
|---|---|---|---|
| 首次完整构建 | 45秒 | 48秒 | +6.7% |
| 增量构建（改1个文件） | 3.2秒 | 3.5秒 | +9.4% |
| 增量构建（改头文件） | 12秒 | 13秒 | +8.3% |
| 配置时间 | 0秒（无需配置） | 2.1秒 | 新增开销 |
从数据上看，CMake生成的Makefile比手写Makefile慢5%-10%。这个开销主要来自CMake生成的Makefile中多了很多变量展开和条件判断。
但要注意——这点性能损失，换来了巨大的维护收益。手写Makefile的配置时间虽然是0，但维护成本高得吓人。我见过一个项目，每次加新文件都要改3个地方的Makefile，漏一个就编译不过。
注意：如果你的项目对构建性能极其敏感（比如每秒都要触发构建的CI环境），可以考虑用Ninja替代Make作为CMake的后端生成器。Ninja的增量构建速度比Make快30%-50%。
核心知识体系
下面这张图，是我梳理的从Make迁移到CMake的核心逻辑。你可以看到，整个迁移过程不是简单的「替换语法」，而是构建思维的转变。
避坑指南
最后，分享几个我踩过的坑：
我曾经犯过的错：
- 滥用全局变量——在CMake里用
set(CMAKE_C_FLAGS ...)覆盖全局编译选项，结果不同模块的配置互相干扰。后来改用target_compile_options按目标设置，问题解决。 - 忽略生成器差异——CMake生成的Makefile和手写Makefile在依赖追踪上行为不同。有一次我发现改了头文件后，CMake生成的Makefile没有重新编译所有依赖的文件，排查了半天才发现是
DEPFILE设置的问题。 - 过度抽象——有人喜欢在CMake里写一堆函数和宏，搞得比原来的Makefile还复杂。我的建议是：保持简单，能用
add_library和target_link_libraries解决的，就别自己造轮子。
从Make迁移到CMake，本质上是从「手写构建规则」到「声明式构建描述」的转变。刚开始可能会觉得不习惯，但一旦上手，你会发现——原来管理大型项目的构建可以这么清爽。
下一章，我会深入CMake的语法细节，聊聊那些让你事半功倍的小技巧。
公众号:蓝海资料掘金营，微信deep3321