为什么我们讨厌 CMake，又为什么无法抛弃它？

最新推荐文章于 2025-04-21 07:52:08 发布

旷野..

最新推荐文章于 2025-04-21 07:52:08 发布

阅读量1.1k

点赞数 50

文章标签： c++ c# 开发语言汇编

本文链接：https://blog.youkuaiyun.com/qq_63315166/article/details/145080316

版权

今天我们来聊聊一个既能引发“群体暴动”，又能让人陷入沉思的话题：CMake。如果你是一个从事 C 或 C++ 开发的程序员，那大概率已经和 CMake “斗智斗勇”过了。很多人吐槽它难用、丑陋、反人类，但转头还是得乖乖用它。那么问题来了：为什么 CMake 让我们这么讨厌，却没有更好的东西取代它？

1.人类天生讨厌学习曲线

不熟悉的东西总是让人感到不舒服，更别提 CMake 的学习曲线简直像一堵墙。我们都知道，当你急着完成一个任务™时，学一个工具的感觉就像上坡推车，痛苦到想骂人。

CMake 的不直觉性是学习曲线的罪魁祸首

奇怪的语法：你见过哪个现代工具还在用这种大写的 ADD_EXECUTABLE 和 ENDIF()？甚至变量定义 set() 和引用语法 $(...) 也非常容易搞混。你总觉得自己回到了上世纪在用某种古老的编程语言。
变量系统让人崩溃：想象一下，你需要通过 10 种不同的方式给源文件传递编译选项。什么 CMAKE_CXX_FLAGS、target_compile_options、add_compile_options，外加神秘的 INTERFACE_COMPILE_OPTIONS，再加上环境变量，瞬间觉得人生已然无望。
调试难如登天：遇到问题想 debug？大多数时候你只能靠 message() 手动打印变量值，就像回到了石器时代调试 C 程序。即便如此，问题可能依然躲在暗处不肯冒头。

我们都知道，这些学习曲线是可以克服的，但问题是：我不是来学一门新语言的，我只是想把项目构建起来啊！

2.CMake 是生态复杂性的“替罪羊”

很多时候，我们抱怨 CMake 难用，其实不是它本身的问题，而是它必须处理的 C 和 C++ 生态的复杂性。这是一场“天降大锅”，而 CMake 必须背起来。

C/C++ 项目复杂到离谱

C 和 C++ 并没有标准化的包管理或构建系统，开发者需要手动解决以下问题：

依赖管理：
你用系统包管理器？还是用 Git 子模块？或者直接下载 tar 包？CMake 的 find_package、FetchContent 和 ExternalProject 虽然提供了接口，但没有统一的规则，每种方式都有自己的坑。
项目布局没有标准：
不同项目的目录结构千奇百怪，有的把头文件放这，有的把库文件放那。CMake 的任务就是“猜”你的项目想干什么，再帮你把这一切配置成工作状态。
测试框架不统一：
Python 有 unittest，Rust 有内置测试工具，而 C/C++？你得自己选一个（比如 Google Test、Catch2），然后再费劲整合到 CMake。
安装和打包难度极高：
你是要给系统路径安装（Linux 上的 /usr/lib），还是打包成一个独立的可执行文件？CMake 提供了一些工具，但配置起来有一堆规则需要学习，稍有不慎就会掉坑里。

CMake 的作用是“提供统一的界面”

说白了，CMake 是用来给这些混乱的生态打补丁的。它的核心任务是把所有这些“散装复杂性”整合成一个看起来像样的工作流，让开发者尽量只需要配置一套 CMake 脚本，就能在不同系统、编译器和工具链上跑起来。

但问题是，这个补丁做得再好，也掩盖不了底层的复杂性。所以，我们对 CMake 的抱怨，很多时候是在发泄对整个 C/C++ 生态的不满。

3. 历史包袱压得 CMake 快喘不过气了

CMake 是 2000 年开发的，当时谁也没想到它会成为未来几十年主流的构建工具。结果，它在无数开发者的需求下越加越多的功能，为了兼容性却不得不保留旧的写法，最终变成了今天的“巨型怪物”。

两种机制并存：新旧混搭的迷惑性

生成器表达式 vs 旧变量机制：
CMake 引入了 target_link_libraries 的新机制，看起来挺现代化。但为了兼容性，老的 _CONFIG 变量和 debug、general 关键字依然存在。两种方式并存，学起来一头雾水。
向后兼容性带来的负担：为了保证旧项目可以在新版本 CMake 上运行，CMake 实现了一套“策略系统”（Policy System）。它允许项目选择特定版本的行为，但这也让 CMake 变得更加复杂。