1. 1.1 CMake概述与演进历史

4天前发布

为什么我们需要CMake

如果你曾经尝试过将自己的C/C++程序从Windows迁移到Linux，或者从macOS分享给使用不同版本Visual Studio的队友，你一定经历过那种”项目文件不兼容”的绝望：Visual Studio的.sln文件在Linux下毫无用处，手写的Makefile在Windows上需要安装MinGW并小心翼翼地处理路径分隔符，而IDE自动生成的项目配置又总是包含各种绝对路径，换一台电脑就无法打开。

这正是跨平台构建的核心痛点：我们写了一份与平台无关的C++源代码，却因为构建系统的差异，不得不为每个平台、每种编译器、每个IDE单独维护一套构建描述。更糟糕的是，当你的项目开始依赖第三方库（如OpenSSL、Boost、Qt）时，不同平台上这些库的安装位置千差万别，手动指定头文件路径和库文件路径很快就会变成一场噩梦。

CMake的诞生，就是为了解决这个问题。

CMake的诞生背景

跨平台构建的黑暗时代

在CMake出现之前，C/C++项目的构建大致有以下几种方案，但每种都有明显的缺陷：

手写Makefile：在Unix/Linux世界非常普遍，但Makefile的语法晦涩难懂，且对Windows支持极差。更关键的是，不同Unix变体（如Linux、Solaris、AIX）上的编译器和系统库位置并不一致，一份Makefile很难通吃所有平台。
Autotools（Autoconf + Automake + Libtool）：GNU项目的标准构建系统，能够生成适应不同平台的Makefile。但它的学习曲线极其陡峭，脚本语言（M4宏）复杂且难以调试，在Windows上的支持也一直是个”二等公民”。
IDE项目文件：Visual Studio的.vcxproj、Xcode的.xcodeproj等。这种方式将开发者牢牢绑定在特定IDE上，团队成员无法自由选择工具，持续集成（CI）服务器上也很难直接构建。

1999年，美国国家医学图书馆（National Library of Medicine）的ITK（Insight Segmentation and Registration Toolkit）项目团队面临同样的困境。他们需要一个构建系统，既能生成Unix下的Makefile，又能生成Windows下的Visual Studio工程文件，还要支持macOS。由于现有工具都无法满足需求，开发者Will Schroeder、Bill Hoffman和Ken Martin开始着手开发一套全新的元构建系统（Meta-Build System）——这就是CMake的起源。

CMake的核心定位

CMake并不是直接编译代码的构建系统，而是一个构建系统生成器。它的工作方式是：

开发者编写一份与平台无关的CMakeLists.txt文件，描述”项目包含哪些目标（可执行文件/库）、依赖哪些源文件、需要链接哪些库”；
CMake读取这些描述，根据当前平台已安装的编译器和用户指定的生成器（Generator），生成对应平台的原生构建系统文件；
最后，开发者使用平台原生工具（如Make、Ninja、MSBuild、Xcodebuild）执行实际的编译链接工作。

这种“一次编写，到处生成”的理念，让CMake迅速成为C++生态中最主流的构建系统抽象层。

CMake的版本演进：从2.x到4.x

CMake从2000年发布首个版本至今，已经走过了二十多个年头。它的语法和最佳实践发生了巨大的变化。理解这些版本差异，对于避免在网上搜到过时的”垃圾代码”至关重要。

CMake 2.x时代：变量驱动的构建系统

在CMake 2.x时期（特别是2.6-2.8，大约2008-2012年），CMake的编程模型主要是基于全局变量的。开发者大量使用如下命令：

include_directories(/usr/include/mylib)        # 全局添加头文件目录
link_directories(/usr/lib/mylib)               # 全局添加库搜索路径
add_definitions(-DUSE_LEGACY_FEATURE)          # 全局添加宏定义
link_libraries(mylib)                          # 全局链接库

add_executable(myapp main.cpp)

这种写法的问题在于副作用污染：include_directories等命令会影响当前目录及其子目录下的所有目标。如果项目规模较小，这尚可接受；但在大型项目中，全局变量会不受控制地传递，导致目标之间的依赖关系模糊不清——你很难确定某个编译选项或头文件路径到底是因为哪个依赖被引入的。

此外，CMake 2.x缺乏现代的目标属性系统，处理第三方库通常需要手动设置一堆变量（如OPENSSL_INCLUDE_DIR、OPENSSL_LIBRARIES），然后将这些变量逐个填充到目标中。这种”变量驱动”的模式使得CMake脚本冗长且容易出错。

CMake 3.x时代：现代CMake的革命

CMake 3.0于2014年发布，这被普遍认为是现代CMake（Modern CMake）的开端。3.x系列引入了一系列颠覆性的概念，彻底改变了CMake的编程范式：

基于目标的属性系统：引入了target_include_directories、target_compile_definitions、target_link_libraries等命令，所有配置都围绕目标（Target）展开，而不是全局变量。
传递性依赖（Transitivity）：通过PRIVATE、PUBLIC、INTERFACE关键字，目标可以精确控制自己的使用要求（Usage Requirements）如何传递给依赖方。这是现代CMake最核心的创新。
接口库（INTERFACE Library）：允许创建不编译任何代码、仅作为配置集合存在的目标，极大提升了配置的复用能力。
生成器表达式（Generator Expressions）：引入了$<...>语法，允许在配置阶段动态计算属性值，解决了许多平台相关的条件配置问题。

从3.1到3.31（截至2024年底），CMake持续引入了大量便利功能：FetchContent（3.11，原生依赖管理）、CMAKE_EXPORT_COMPILE_COMMANDS（更好的IDE支持）、预设文件CMakePresets.json（3.19+）等。如果你今天在网上搜索CMake教程，一定要确认它是否基于CMake 3.x的最佳实践。

CMake 4.x及未来展望

CMake 4.0尚未发布（目前最新稳定版仍为3.x系列），但CMake开发团队已经在逐步清理历史包袱。未来的方向包括：

进一步提升对C++20 Modules的支持，解决模块编译单元依赖扫描的构建系统难题；
更强的包管理器集成（与vcpkg、Conan等工具的无缝协作）；
废弃更多旧的全局命令，鼓励纯粹的目标驱动写法；
性能优化，减少大型项目的配置时间。

作为初学者，你无需担心版本差异带来的困扰，只需要记住一条铁律：尽量使用你所能安装到的最新版本的CMake（至少3.16以上，推荐3.20+），并遵循现代CMake的目标驱动范式。

现代CMake的核心理念：基于目标而非变量

现代CMake最核心的思维转变可以用一句话概括：忘记全局变量，拥抱目标（Target）。

什么是目标（Target）

在CMake中，目标代表构建系统最终要生成的实体。它可以是：

一个可执行文件（由add_executable()定义）
一个库文件——静态库、动态库或模块库（由add_library()定义）
一个接口库（由add_library(name INTERFACE)定义，不生成文件，仅传递配置）

每个目标都是一等公民，拥有自己的属性集合。你需要编译选项？设置到目标上。需要头文件目录？设置到目标上。需要链接其他库？还是设置到目标上。

封装与传递性

现代CMake的强大之处在于封装（Encapsulation）。假设你有一个network_lib库，它内部使用了OpenSSL。在旧式CMake中，任何使用了network_lib的可执行文件，都必须手动再链接一遍OpenSSL，甚至还要手动添加OpenSSL的头文件路径——因为旧式的全局变量无法封装这种”目标的依赖的依赖”。

在现代CMake中，你只需要这样写：

target_link_libraries(network_lib PUBLIC OpenSSL::SSL)

add_executable(my_app main.cpp)
target_link_libraries(my_app PRIVATE network_lib)

由于network_lib对OpenSSL的依赖被标记为PUBLIC，my_app在链接network_lib时，会自动获得OpenSSL的所有使用要求（头文件路径、链接标志、编译定义），而你作为my_app的开发者甚至不需要知道OpenSSL的存在。这就是传递性依赖的威力。

这种设计使得大型项目的依赖关系从”一团乱麻的全局变量”变成了”清晰的树状目标图”，极大地降低了维护成本。

CMake与其他构建系统的对比

CMake并不是C++世界唯一的构建系统。为了帮助你建立正确的技术选型认知，我们简要对比几种主流工具。

Make（GNU Make / BSD Make）

定位：底层构建工具，直接控制编译命令的执行。
优点：几乎所有Unix系统都预装，无需额外依赖；对小型项目足够简单。
缺点：语法对空格和Tab极度敏感；没有内置跨平台抽象；手动管理依赖非常痛苦；Windows支持差。
与CMake关系：CMake可以生成Makefile，然后由Make执行。CMake站在更高的抽象层。

Ninja

定位：专注于速度的底层构建工具，由Google开发。
优点：增量构建极快；设计简洁，专注于执行构建图；被多种元构建系统支持。
缺点：本身不提供高级语言来描述项目，需要配合CMake或GN使用；Windows下需要额外安装。
与CMake关系：CMake的-G Ninja选项可以生成Ninja构建文件。对于追求编译速度的项目，CMake + Ninja是黄金搭档。

Bazel

定位：Google开发的多语言构建和测试系统，强调可重现性和增量构建。
优点：构建缓存极其强大；对大型单体仓库（Monorepo）支持非常好；严格的依赖声明。
缺点：学习曲线陡峭；对第三方依赖的管理方式与C++传统生态差异较大；Windows和IDE集成曾长期是短板；引入成本很高。
适用场景：超大规模工程（如TensorFlow、Chrome级别的项目），或者已经全面拥抱Google技术栈的团队。

Meson

定位：现代化的元构建系统，设计目标是”比CMake更快、更简单”。
优点：语法非常清晰（类似Python）；原生对依赖管理（wrap子项目）的支持很好；生成Ninja文件的速度通常比CMake快。
缺点：生态成熟度不如CMake；许多第三方库只提供CMake配置包（Config），Meson的查找支持相对较弱；企业级工具和IDE集成不如CMake普及。
适用场景：对构建性能敏感、且不需要与大量遗留CMake生态交互的新项目（如GNOME桌面环境的某些模块已转向Meson）。

CMake的独特优势

综合来看，CMake之所以能成为C++事实标准，是因为它在几个关键维度上取得了平衡：

生态兼容性：绝大多数C++库（无论是Boost、Qt、OpenCV还是protobuf）都原生提供CMake支持或Find模块。
IDE集成：Visual Studio、CLion、VS Code、Qt Creator都对CMake提供了一流支持，可以直接打开CMake项目。
生成器灵活性：既能生成Unix Makefile，也能生成Ninja文件，还能生成Visual Studio和Xcode项目文件，适应不同团队的工作流。
渐进式采用：你可以在项目中只让新模块使用CMake，逐步迁移旧模块，而不需要一次性重写整个构建系统。

小结

在本节中，我们了解了CMake诞生的历史背景——为了解决C/C++项目跨平台构建的痛楚；梳理了CMake从2.x的全局变量时代，到3.x的目标驱动现代的革命性转变；理解了基于目标（Target-based）和传递性（Transitivity）这两个现代CMake最重要的设计哲学；最后通过与其他构建系统的对比，明白了CMake在C++生态中不可撼动的地位。

从下一节开始，我们将动手搭建CMake开发环境，并运行你的第一个CMake项目。

测试标签

评分

欢迎为Ta评分