1. 1.1 CMake概述与演进历史

6小时前发布

导语

如果你曾经尝试亲手编译一个开源C++项目，一定经历过这样的绝望：README里写着./configure && make && sudo make install，但你的Windows电脑上根本没有configure脚本；或者你下载了一个Visual Studio工程，却发现自己用的是CLion；又或者，你只是想给Mac M系列芯片编译一个库，却被满屏幕的架构错误搞得焦头烂额。

这些痛苦的根源，都指向同一个问题：跨平台构建。

CMake正是为解决这一问题而生的“工业标准答案”。在本节中，我们将回到历史现场，理解CMake诞生的必然性；梳理2.x到4.x的版本脉络，看清Modern CMake的转折意义；并通过与Make、Ninja、Bazel、Meson的横向对比，建立对CMake生态位的清晰认知。放心，本节不需要你写任何复杂代码，但会给你一双看懂后续所有实战的“历史望远镜”。

跨平台构建的痛点与CMake的诞生背景

没有CMake的时代：构建系统的“巴别塔”

在2000年以前，C/C++项目的构建基本处于“军阀割据”状态：

Unix/Linux世界：手写Makefile，配合autotools（autoconf/automake）生成配置脚本。这要求项目维护者精通M4宏语言和Shell脚本，而用户端则需要正确的工具链版本，否则./configure会抛出晦涩的错误。
Windows世界：开发者使用Visual Studio的.sln和.vcproj文件，或者NMake。这些文件与VS版本强绑定，且无法直接在Linux上使用。
Mac世界：早期使用ProjectBuilder，后来转向Xcode，又是另一套完全不同的项目描述格式。

这意味着，如果一个库想在三个平台都可用，维护者必须同时维护多套构建描述文件。任何源码目录调整、新增编译选项、依赖变更，都需要在N个文件之间手动同步——这几乎是一项“不可能完成的任务”。

让我们看一个最直观的例子。假设你写了一个跨平台的Hello World，这是Unix下的Makefile：

# Makefile.unix
CXX = g++
CXXFLAGS = -std=c++11 -Wall
hello: main.cpp
	$(CXX) $(CXXFLAGS) -o hello main.cpp

而在Windows下，如果你使用NMake，可能需要这样写：

# Makefile.nmake
CXX = cl.exe
CXXFLAGS = /EHsc /std:c++11
hello.exe: main.cpp
	$(CXX) $(CXXFLAGS) main.cpp /Fe:hello.exe

这还只是最简程序。一旦涉及第三方库路径差异、不同编译器的警告选项、条件编译，复杂度会指数级上升。开发者渴望一种“写一次，到处生成”的构建描述语言。

CMake的破局之道：元构建系统

CMake（Cross-platform Make）由Kitware公司于2000年发布，其天才之处在于：它并不直接构建项目，而是生成特定平台的原生构建文件。这种设计被称为元构建系统（Meta-Build System）。

具体来说，CMake的工作流程分为两层：

配置层（Configure）：开发者编写与平台无关的CMakeLists.txt，CMake会检测编译器、操作系统、处理器架构，解析依赖关系。
生成层（Generate）：CMake根据检测结果，在后台生成平台原生的构建文件。例如在Windows上生成Visual Studio解决方案，在Linux上生成Makefile，在Mac上生成Xcode工程。

用一张图来概括传统方式与CMake的区别：

传统方式：
开发者 → [手动维护Makefile/VS工程/Xcode] → 各平台原生构建

CMake方式：
开发者 → [编写CMakeLists.txt] → CMake → [生成Makefile/VS工程/Xcode/Ninja] → 各平台原生构建

通过引入这个中间层，CMake将“平台差异”的复杂性从项目维护者手中接管过来。你只需要关心“我要编译什么源码、依赖什么库”，而不必关心“GCC的-Wall对应MSVC的哪个选项”。

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

CMake并非一蹴而就。理解其版本演进，尤其是从“旧式CMake”到“现代CMake”的范式转变，是避免写出“古董级”CMakeLists.txt的关键。

CMake 2.x时代（2000-2014）：变量驱动的“大锅饭”

CMake 2.x（特别是2.6/2.8）奠定了CMake的基础，但受限于时代，它的设计哲学是全局变量驱动。当时典型的CMakeLists.txt长这样：

cmake_minimum_required(VERSION 2.8)
project(MyProject)

# 全局设置！影响后续所有目标
include_directories(/usr/local/include)
link_directories(/usr/local/lib)
add_definitions(-DUSE_THREADS)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")

add_executable(app1 main1.cpp)
add_executable(app2 main2.cpp)
# app1 和 app2 都被迫继承了上面的全局设置，无法单独控制

这种写法的弊端显而易见：

污染全局：include_directories等命令会无条件作用于之后定义的所有目标，导致编译选项“传染”。
不可传递：如果app1依赖一个静态库liba，你必须手动把liba的头文件路径再写给app1，依赖关系无法自动传播。
命令式而非声明式：脚本充满了字符串拼接和变量操作，更像是Shell脚本而非构建描述。

尽管有诸多不足，CMake 2.x凭借强大的生成器（Generator）体系，迅速击败了同期的竞争对手（如SCons、Premake），成为C++事实上的跨构建标准。

CMake 3.x时代（2014至今）：现代CMake的崛起

2014年发布的CMake 3.0是CMake历史上的“遵义会议”。它引入了完整的Target属性系统和传播语义（Transitivity），正式开启了Modern CMake时代。

几个里程碑版本带来的关键变革：

CMake 3.0（2014）：引入<TARGET_PROPERTY:>等生成器表达式雏形，目标属性体系正式完善。
CMake 3.1（2015）：增加target_compile_features()，可以声明式要求C++11/14标准，不再需要手动拼接编译器标志。
CMake 3.5+（2016）：大量内置Find模块现代化；Imported Targets（如Boost::boost）开始普及。
CMake 3.11（2018）：FetchContent模块登场，允许在配置阶段直接下载依赖源码，极大简化了外部项目管理。
CMake 3.15+（2019）：生成器表达式在更多命令中得到支持；CMAKE_MSVC_RUNTIME_LIBRARY等现代抽象层出现。
CMake 3.20+（2021）：对C++20模块的初步实验性支持；预设文件（Presets）系统成熟。
CMake 3.25+（2022-2023）：持续增强对C++23、HIP、SYCL等新标准的支持；性能优化和新的策略（Policy）机制。

用现代CMake重写上面的例子，会清晰很多：

cmake_minimum_required(VERSION 3.15)
project(MyProject LANGUAGES CXX)

add_library(math STATIC math.cpp)
target_include_directories(math PUBLIC 
    $
)
target_compile_features(math PUBLIC cxx_std_17)

add_executable(app1 main1.cpp)
target_link_libraries(app1 PRIVATE math)
# app1 自动继承了math的头文件路径和C++17要求，且不影响其他任何目标

注意这里的关键词：PRIVATE、PUBLIC、INTERFACE——这些是现代CMake控制依赖传播的“三原色”。我们将在后续章节深入剖析。

CMake 4.x时代（展望）：云原生与语言标准融合

CMake 4.x（目前部分特性已在3.25+中实验性引入）的演进方向主要集中在：

构建系统云化：通过改进远程执行缓存和分布式编译支持，让CMake更好地适应CI/CD和云端开发环境。
C++20 Modules的深度支持：随着C++20标准模块（Modules）的普及，CMake正在重构其依赖扫描逻辑，以原生支持import std;这类现代编译模型。
性能与可扩展性：更快的配置阶段（Configure）速度，以及更完善的JSON交互接口（如cmake-file-api），方便IDE深度集成。

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

从“大锅饭”到“包产到户”

Modern CMake最核心的思想可以用一句话概括：“围绕目标（Target）组织构建，而非围绕全局变量。”

在旧式CMake中，构建信息是“散养”的全局状态；而在现代CMake中，每一个可执行文件、每一个库，都是一个自给自足的目标对象，拥有自己的属性、依赖和接口。

我们通过一组对比代码来感受这种差异。假设项目有一个库mylib和一个可执行文件myexe：

旧式写法（CMake 2.x风格，不推荐）

# 全局变量就像公共厕所，谁都能改，谁都不知道当前状态是什么
include_directories(include)  
add_definitions(-DMY_MACRO)
set(CMAKE_CXX_STANDARD 11)

add_library(mylib STATIC mylib.cpp)
add_executable(myexe main.cpp)
target_link_libraries(myexe mylib)
# 问题：如果此时还有一个add_executable(other ...)，它也会被强制使用C++11和include目录

现代写法（CMake 3.15+，推荐）

add_library(mylib STATIC mylib.cpp)
target_include_directories(mylib PUBLIC 
    $
    $
)
target_compile_definitions(mylib PRIVATE MY_MACRO=1)
target_compile_features(mylib PUBLIC cxx_std_17)

add_executable(myexe main.cpp)
target_link_libraries(myexe PRIVATE mylib)
# 优点：
# 1. mylib 的 include 路径只对依赖它的目标（myexe）可见
# 2. MY_MACRO 只在编译 mylib 时定义，不会泄漏给 myexe
# 3. C++17 要求会随着链接自动传递给 myexe

可传递性（Transitivity）：依赖管理的“自动扶梯”

现代CMake最伟大的发明之一，是使用要求（Usage Requirements）的自动传播机制。

当你在旧式CMake中使用target_link_libraries(myexe mylib)时，链接器确实会把mylib.a链接进去，但不会告诉编译器mylib的头文件在哪里。你必须手动再写一遍include_directories。

而在现代CMake中，如果mylib通过target_include_directories(mylib PUBLIC ...)声明了自己的接口头文件路径，那么任何通过target_link_libraries(... PRIVATE mylib)链接它的目标，都会自动获得这些头文件路径。这就像乘坐自动扶梯——你只需“链接”这一步，所有必要的编译要求都会自动跟上。

这种机制极大地降低了大型项目的维护成本。当你引入一个第三方库（如Boost::filesystem）时，只需要一行target_link_libraries，编译定义、头文件路径、链接顺序、甚至运行时库设置都可能被自动处理。

CMake与其他构建系统的对比

构建系统家族谱

为了准确定位CMake，我们需要看看它的“兄弟姐妹”们。以下是当前C/C++生态中最主流的构建工具对比：

1. GNU Make

定位：底层构建工具，直接调用编译器。
优点：几乎所有Unix系统预装；规则简单直观；适合小型项目。
缺点：语法对空格敏感（必须用Tab缩进）；无跨平台能力（Windows需Cygwin/MinGW）；无内置依赖查找机制；大规模项目Makefile极难维护。
与CMake关系：CMake在Linux/Unix上最常生成的就是Makefile。CMake是“指挥官”，Make是“执行者”。

2. Ninja

定位：追求极致速度的低级构建系统。
优点：由Chrome团队开发，设计目标是比Make更快；支持并行构建极致优化；文件格式被设计为易于机器生成而非人类编写。
缺点：语法极简但功能极简，不适合直接手写复杂逻辑；没有内置的依赖包管理或配置检测能力。
与CMake关系：Ninja是CMake的黄金搭档。运行cmake -G Ninja，CMake会生成build.ninja文件，再由Ninja执行编译。这是目前大型C++项目（如LLVM、Android）的标准配置。

3. Bazel

定位：Google开源的 monorepo 构建与测试工具。
优点：严格的沙箱构建、增量编译极其精确、内置远程缓存和分布式构建支持；原生支持多语言（C++/Java/Go等）。
缺点：学习曲线陡峭（需要理解WORKSPACE、BUILD、Starlark语言）；第三方库集成相对繁琐；Windows支持曾长期是短板；与主流IDE集成不如CMake成熟。
与CMake关系：两者是竞争关系，但生态位不同。Bazel更适合超大规模企业级 monorepo；CMake则是开源社区和跨平台库的首选，生态更为开放。

4. Meson

定位：CMake的“现代挑战者”。
优点：语法更简洁（受Python启发）；原生支持Ninja后端，配置速度通常比CMake快；内置依赖管理（dependency()）比CMake早期更直观。
缺点：生态成熟度和社区规模远不及CMake；许多开源库只提供CMake Config文件而没有Meson支持；IDE支持相对薄弱。
与CMake关系：设计理念接近Modern CMake（同样强调Target/声明式），但CMake凭借二十余年的积累，在第三方库兼容性上仍占绝对优势。

横向对比总结表

为了更直观，我们用一张表总结各构建系统的特性：

特性                CMake       Make        Ninja       Bazel       Meson
--------------------------------------------------------------------------------
跨平台生成能力       ★★★★★     ★★☆☆☆     ★★★☆☆     ★★★★☆     ★★★★☆
手写维护难度         ★★★☆☆     ★★★★☆     ★★★★★     ★★★★☆     ★★★☆☆
编译速度             ★★★★☆     ★★★☆☆     ★★★★★     ★★★★★     ★★★★☆
IDE/工具链生态       ★★★★★     ★★★☆☆     ★★★★☆     ★★★☆☆     ★★★☆☆
第三方库支持度       ★★★★★     ★★☆☆☆     ★★☆☆☆     ★★★☆☆     ★★★☆☆
学习曲线（新手友好）  ★★★☆☆     ★★★☆☆     ★★★★★     ★★☆☆☆     ★★★★☆

（注：★越多代表在该维度越优秀；Ninja的手写维护难度五星代表“极难手写”，因为它本就不是为人类直接编写设计的。）

为什么学CMake仍是2024年的最优解？

尽管Bazel和Meson来势汹汹，但CMake仍有两个短期内无法被撼动的优势：

生态惯性：Boost、Qt、OpenSSL、LLVM、OpenCV……几乎所有主流C++库都以CMake作为首要或唯一支持的构建系统。学会CMake，意味着你能无障碍地使用整个C++开源生态。
生成器灵活性：CMake可以生成Makefile、Ninja、Visual Studio工程、Xcode工程、Eclipse工程……这种“一次编写，到处生成”的能力，目前还没有其他工具能完全替代。

因此，对于个人开发者、开源贡献者或需要与大量遗留系统交互的工程师，CMake依然是必修技能。而Ninja通常作为CMake的“加速引擎”搭配使用（cmake -G Ninja），而非独立替代CMake。

小结

在本节中，我们穿越了CMake二十余年的发展历程，理清了以下几个关键认知：

诞生的必然性：跨平台构建的碎片化，催生了CMake这种元构建系统。
版本分水岭：CMake 3.0是旧式变量驱动与现代目标驱动的分界线，后续版本持续强化Target、生成器表达式和依赖管理能力。
核心哲学：Modern CMake = 基于目标（Target-based）+ 传播语义（PUBLIC/PRIVATE/INTERFACE）+ 避免全局变量污染。
生态定位：CMake是跨平台C++生态的“通用语言”，与Ninja搭配可获得最佳编译速度；Bazel/Meson是特定场景下的有力竞争者，但尚未形成全面替代。

理解这些背景，将帮助你在后续章节中不仅“知道怎么写”，更“知道为什么这么写”。从下一节开始，我们将动手安装CMake，并写出你的第一个CMakeLists.txt。准备好你的键盘，我们实战见！

测试标签

评分

欢迎为Ta评分