CMake 4.0正式发布：停止兼容3.5前版本，C++构建工具20年最大变革

2025 年 3 月，CMake 跳过 3.32，直接把版本号拉到了 4.0。距离 2001 年 CMake 1.0 发布，这是首次变更主版本号——不是例行升级，而是一次明确的断代。

最狠的一刀：旧版本兼容性直接砍掉

CMake 4.0 最核心的变化，是彻底移除了对 3.5 之前版本的行为兼容。

过去二十年里，CMake 一直靠 cmake_minimum_required() 维持向后兼容。你写 cmake_minimum_required(VERSION 2.8)，CMake 3.x 会默默模拟 2.8 的行为。4.0 开始，这条规则作废——只要项目要求 CMake 版本低于 3.5，配置阶段就直接中断。

cmake_minimum_required(VERSION 2.8)  # CMake 4.0 下直接报错
cmake_minimum_required(VERSION 3.5)  # 最低存活线

Kitware 的意思很直白：维护二十年前行为模式的成本已经高到不合理。老项目要么升级到 3.5+ 的策略，要么锁死旧版 CMake。

注意，这不是说 CMake 4.0 不能编译老项目。cmake_minimum_required(VERSION 3.5...4.0) 这种范围语法仍然有效，CMake 会在 3.5 到 4.0 之间选择匹配的策略。但如果你硬写 VERSION 2.8 或 VERSION 3.4，4.0 不会再迁就。

命令行与构建链的实质性升级

除了兼容性断裂，4.0 在工程实践层面也加了不少新东西。

cmake 命令新增 --project-file 选项，允许临时指定替代 CMakeLists.txt 的文件名。这对增量迁移和大型仓库的过渡场景有用，但 CMake 每次都会警告你这不是最终方案。

--sarif-output 和 CMAKE_EXPORT_SARIF 变量引入了 SARIF 格式的静态分析日志输出。CI 流水线可以直接消费这种标准格式，不用再写正则解析 CMake 的诊断文本。

target_link_libraries() 正式支持 LINKER: 前缀，链接器标志的传递终于有了统一且可移植的写法：

target_link_libraries(myapp PRIVATE LINKER:--no-as-needed)

对应的，CMAKE_EXE_LINKER_FLAGS 等链接器变量也学会了识别这个前缀。policy CMP0181 管的就是这件事。

Windows 上还有一个容易被忽略但影响深远的改动：项目代码中的文件路径不再自动转换为磁盘上的实际大小写。CMake 要求你在一开始就写对路径的大小写。这对跨平台项目是好事，但对依赖大小写不敏感旧习惯的 Windows 开发者，意味着一批潜在的路径问题会暴露出来。

平台相关行为的清理

macOS 侧的改动也很干净。/usr/bin 下的编译器不再被映射到 Xcode 内部对应版本，CMAKE_OSX_SYSROOT 默认留空，交给编译器自己决定 SDK。这意味着第三方构建系统接收到的编译器路径更诚实，也避免了 xcode-select 切换后构建树失效的问题。

AIX 上，SHARED 库目标现在默认产出共享库归档，由 policy CMP0182 控制。Visual Studio 2015 和 2017 的 generator 不再支持把平台名直接拼在 generator 字符串里，平台选择必须走正规途径。

对 C++ 开发者意味着什么

CMake 4.0 不会让你的代码编译得更快，也不会新增什么语法糖。它的本质是 Kitware 对技术债务的一次集中清理。

对大多数项目来说，实际影响分三层：

• 如果你已经在用 cmake_minimum_required(VERSION 3.16+)，基本无感，平滑升级即可。
• 如果你的项目还卡在 VERSION 2.8 或 VERSION 3.4，4.0 是一记警钟，迟早要动。
• 如果你是库作者，CI 矩阵里最好尽快加上 CMake 4.0 的测试轮次，否则用户先踩坑、你先收 issue。

版本号从 3 跳到 4，不是营销噱头。二十年的向后兼容包袱，CMake 这次选择放下。对 C++ 生态来说，这不是最温柔的升级，但可能是最必要的一次。