CMake vs Autotools：设计理念差异
说实话，我刚开始接触这两个工具时，也觉得它们差不多——不都是用来配置构建项目的吗？但用久了才发现，这两者的设计哲学简直是两个世界的东西。
Autotools 诞生于上世纪90年代，那时候的 Unix 世界百花齐放。不同的机器、不同的编译器、不同的库路径……Autotools 要解决的，说白了就是「让我的代码能在任何 Unix 机器上编译」。它的核心思路是：在编译之前，先探测环境，然后生成适配的 Makefile。
CMake 呢？它诞生得晚一些，2000年左右。那时候跨平台的需求已经不只是 Unix 了，还有 Windows、macOS。CMake 的设计思路是：你描述你的项目结构，我来生成对应平台的构建文件。它不直接编译，而是生成 Makefile、Ninja 文件、Visual Studio 工程……
我个人的理解是：Autotools 是「环境适配器」，CMake 是「构建描述器」。这两个定位，决定了后面所有的差异。
核心差异一句话总结：
- Autotools：探测环境 → 生成 Makefile → 编译
- CMake：描述项目 → 生成构建文件（Makefile/Ninja/VS）→ 编译
配置阶段对比：CMake configure vs autoconf
autoconf 的配置哲学
autoconf 的工作方式，我称之为「暴力探测法」。它会生成一个 configure 脚本，这个脚本会做一大堆检查：
- 检查编译器是否存在（gcc？cc？还是别的？）
- 检查头文件（有没有 stdio.h？有没有 pthread.h？）
- 检查库函数（有没有 sqrt？有没有 dlopen？）
- 检查库路径（libpthread 在哪？）
每次运行 configure，它都会生成一个 config.h 文件，里面全是 #define 宏。你的代码里就充斥着 #ifdef HAVE_PTHREAD_H 这样的条件编译。
我记得有一次维护一个老项目，configure 跑了整整两分钟。两分钟啊！就为了检查一堆我根本用不到的特性。但没办法，Autotools 就是这么设计的——它不知道你需要什么，所以它什么都检查。
小技巧：如果你用 Autotools，可以在 configure.ac 里用 AC_CHECK_HEADERS 只检查你真正需要的头文件。别偷懒写一堆没用的检查，否则每次 configure 都够你喝一壶的。
CMake 的配置哲学
CMake 的 configure 阶段，说白了就是「按需查找」。你告诉 CMake 你需要什么，它就去查什么。比如：
find_package(OpenSSL REQUIRED)
find_package(Python3 COMPONENTS Interpreter Development)
find_library(MATH_LIB m)CMake 不会去检查所有可能的库，它只查你明确指定的。这比 Autotools 高效得多。而且 CMake 的缓存机制也很聪明——第一次配置后，结果会缓存到 CMakeCache.txt 里，下次再跑 cmake 就快多了。
我个人习惯是：在 CMakeLists.txt 里用 find_package 配合 REQUIRED 或 OPTIONAL 关键字，明确告诉 CMake 哪些依赖是必须的，哪些是可选的。这样配置阶段既快又清晰。
注意：CMake 的 find_package 有两种模式：Module 模式和 Config 模式。Module 模式找 FindXXX.cmake 脚本，Config 模式找 XXXConfig.cmake。新手经常搞混，导致找不到包。我建议优先用 Config 模式，因为它是包作者提供的，更可靠。
配置阶段对比表
| 对比维度 | Autotools (autoconf) | CMake |
|---|---|---|
| 配置语言 | m4 宏 + shell 脚本 | CMake 语言（类脚本） |
| 探测方式 | 运行大量测试程序 | 查找文件、执行编译测试 |
| 输出产物 | config.h + Makefile | CMakeCache.txt + 构建文件 |
| 配置速度 | 慢（尤其跨平台时） | 快（有缓存机制） |
| 跨平台能力 | Unix 为主，Windows 勉强 | 原生支持 Windows/macOS/Linux |
| 错误提示 | 晦涩的 shell 错误 | 相对友好，有行号提示 |
生成阶段对比
配置阶段完了，接下来就是生成阶段。这里两者的差异也很大。
Autotools 的生成
Autotools 的生成阶段，其实就是 ./configure 跑完之后，它根据探测结果生成 Makefile。这个 Makefile 是 autoconf 用 Makefile.in 模板生成的。Makefile.in 里有很多 @变量@，configure 会把这些变量替换成实际的值。
比如 Makefile.in 里有：
CC = @CC@
CFLAGS = @CFLAGS@
LDFLAGS = @LDFLAGS@configure 跑完后，这些 @CC@ 就被替换成了 gcc 或 cc 之类的实际值。这个过程是一次性的——你改不了，除非重新跑 configure。
嗯，这里要注意：Autotools 生成的 Makefile 非常复杂。我见过一个项目，生成的 Makefile 有 8000 多行。你想手动改？门都没有。
CMake 的生成
CMake 的生成阶段就灵活多了。它可以根据你指定的生成器，输出不同的构建文件：
-G "Unix Makefiles"→ 生成 Makefile-G "Ninja"→ 生成 build.ninja-G "Visual Studio 17 2022"→ 生成 .sln 工程-G "Xcode"→ 生成 .xcodeproj
而且 CMake 的生成阶段是可重复的。你改了 CMakeLists.txt，重新跑 cmake，它会增量更新构建文件，不会从头再来。这一点比 Autotools 舒服太多了。
我的建议：新项目直接用 Ninja 生成器。Ninja 比 Make 快得多，尤其是增量编译时。CMake 配合 Ninja，简直是绝配。
运行时对比
运行时，说白了就是 make 或 ninja 真正干活的时候。这里两者的差异主要体现在：
Autotools 的运行时
Autotools 生成的 Makefile，依赖关系是静态的。它在 configure 阶段就确定了所有依赖。如果你改了某个源文件，make 会重新编译受影响的文件。但如果你改了 Makefile.am，你得重新跑 autoreconf 和 configure，才能生效。
我曾经在一个大型 C++ 项目里用 Autotools，每次改一个头文件，都要等 5 分钟重新链接。为什么？因为 Autotools 生成的 Makefile 依赖关系太粗了——它把整个库的 .o 文件都链接到一起，哪怕你只改了一个函数。
CMake 的运行时
CMake 生成的构建文件，依赖关系是动态的。尤其是配合 Ninja 时，Ninja 会精确计算每个文件的依赖，只重新编译真正受影响的部分。而且 CMake 支持 add_dependencies 和 target_link_libraries 这样的细粒度控制。
另外，CMake 的运行时还有一个杀手锏：多配置生成器。比如 Visual Studio 和 Xcode 支持 Debug/Release/RelWithDebInfo 等多种配置，你可以在 IDE 里一键切换，不用重新配置。Autotools 呢？你得建三个不同的 build 目录，分别跑 configure --enable-debug 和 configure --disable-debug。
运行时对比总结：
- Autotools：依赖关系静态、配置与构建耦合、多配置麻烦
- CMake：依赖关系动态、配置与构建解耦、多配置原生支持
我的个人经验总结
做了这么多年构建系统，我个人的体会是：
什么时候用 Autotools？ 只有一种情况——你在维护一个已经用 Autotools 的老项目，而且项目只跑在 Linux 上。比如 GNU 工具链的那些项目，像 gcc、binutils、glibc，它们用 Autotools 用得好好的，没必要换。
什么时候用 CMake？ 几乎所有新项目。尤其是：
- 需要跨平台（Windows + Linux + macOS）
- 项目规模大，需要细粒度依赖管理
- 需要 IDE 支持（VS、Xcode、CLion）
- 团队里有不熟悉 shell 的开发者
我曾经把一个中型项目从 Autotools 迁移到 CMake，构建时间从 8 分钟降到了 3 分钟。为什么？因为 CMake + Ninja 的增量编译比 Autotools + Make 高效太多了。而且 CMake 的语法比 m4 宏友好得多，新成员上手也快。
当然，CMake 也不是完美的。它的语法有时候也挺奇葩的，尤其是字符串处理和变量作用域。但比起 Autotools 那一套 m4 宏 + shell 脚本的混合体，CMake 已经算是清流了。
避坑指南：如果你决定从 Autotools 迁移到 CMake，别一次性全改。我建议先在一个子模块里试用 CMake，验证没问题了再逐步推广。我曾经见过一个团队，一口气把整个项目迁移到 CMake，结果编译不过，回退又花了三天……嗯，教训深刻。
好了，这一章我们聊了 CMake 和 Autotools 在设计理念、配置阶段、生成阶段和运行时的差异。下一章我们会深入 CMake 的语法细节，看看那些让人又爱又恨的 CMake 命令到底该怎么用。