由简至繁，以小见大。首先，让我们从标准的Gartner 技术成熟度曲线开始，了解 CMake 的发展，感受 CMake 对行业的深远影响。
图片来源：Gartner (我在原图基础上增加了年份)
CMake 的开发从 1999 年开始，最初的版本由 Kitware 在 2000 年发布。在接下来的五年里，CMake 被公认为是构建大型开源和专有项目的有效解决方案。2006 年，KDE 成功迁移到 CMake，并留下了老化的自动工具构建系统。这对 CMake 来说是一个重大的胜利，在这个时期，CMake 处于过高期望的高峰期（Inflated expectations）。大约过了十年后，CMake 3.0 才发布。在这期间，CMake 经历了泡沫出现的低谷期（Trough of Disillusionment）。现代CMake（CMake 3.0 之后的版本）抛弃了许多经典 CMake 的反模式，并进入稳步爬升的光明期 （Slope of Enlightement）。从 Visual Studio 2017 到 Qt6.0 开始支持 CMake，我相信，CMake 目前已经达到了实质生产的高峰期（Plateau of Productivity）。
CMake 风暴已经酝酿了二十年！现在，CMake 已到达实质生产的高峰期，技术成熟曲线暂时告一段落。接下来让我们看看一些成功的案例，了解为何现代 CMake 不容轻视。
Visual Studio 和 CMake
在长期的项目运行中，维护 Visual Studio 项目和解决方案的健全性是一件痛苦的事（委婉的说法）。维护一个只在 Visual Studio 2010 中编译的分支，为客户提供到该产品后续版本的迁移路径，这种情况并不少见。产品版本不同，编译的 Visual Studio 版本也不同，且具有多个分支，这类产品的维护堪称一场噩梦。因此，使用 CMake 生成正确的 Visual Studio 项目/解决方案像是有如天助。从 VS2017 开始，Visual Studio 与现代 CMake 捆绑（Incredibuild 也与 Visual Studio 捆绑）。因此，遵循 CMake – Visual Studio 工作流变得更为简单，大型项目亦是如此。CMake 也支持 C# 语言的项目生成和构建，因此我希望 CMake Visual Studio 在 Windows 世界中会变得更加流行。下面总结了 Visual Studio CMake 对项目的意义：
- 避免在不同分支中维护多个项目和解决方案， CMakefiles.txt 文件中可以自动生成。
- 新版本的 Visual Studio 不需要迁移解决方案和项目，Visual Studio 最新版本操作简单。
- 由于没有需要合并的项目或更改的解决方案，因此合并不同分支的并行工作变得更加简单。
- 不再需要维护批标准化或 Perl 脚本，因为 CMake 可以自动构建。
- 在 CMake 中构建的 CI/CD 管道比基于自制脚本的定制解决方案更易于维护。
Visual Studio, CMake 和 WSL2
Visual Studio 2019 为 Linux 2 的 Windows 子系统带来的集成量是惊人的。不必离开熟悉的 Windows 环境，开发人员可以即刻启动 CMake – Visual Studio 项目，使用 Clang 或 GCC 进行交叉编译，然后调试 WSL 机器上运行的应用程序。当项目变得稳定时，可以消除交叉编译的麻烦，因为基于 CMake Visual Studio 的项目需要在本机环境中正确配置和构建。
CLion 和 CMake
CLion 是 Jetbrains旗下专门开发针对 C 以及 C++ 的跨平台IDE。CMake 是最深入集成到 CLion 中的项目模型。CLion 中的 CMake 智能支持是使用体验最佳的编辑器，这让 CMake 构建成为一种乐趣。
Qt6.0 和 CMake
2020 年 12 月，“下一代 Qt”， Qt6.0，正式发布。Incredibuild 与 Qt 完美集成，加快 编译速度 （详情请阅读链接内容）。Qt6.0 的亮点之一是“支持 CMake”。这是 Qt 员工的原话：“使用行业标准的构建系统，以其广泛的功能集、大型生态系统来构建 Qt 应用程序。” 在管道中，Qt – CMake 集成的过程很长。
不知大家还记得 QMake 吗？尽管它仍然受支持，但建议使用 CMake 来构建基于 Qt6.0 的项目。那么庞大的 Qt 源代码本身呢？它也是用 CMake 构建的吗？我做了一些研究，偶然发现了 Jörg Bornemann 的博客。Qt6.0 源代码目前使用 CMake 进行构建。这也是说明 Qt-CMake 集成成功的最佳证据！
Vcpkg 和 CMake
（本片博客的内容绝对真实，这部分也是我和一位建筑师之间发生的真人真事。免责声明：没有建筑师在生产过程中受到伤害）
在一个繁忙的星期一上午，我被拉去和我们公司一个高级项目的建筑师开会。我负责建立这个项目的建设管道，一切进展顺利。为了满足一个新的需求，这个项目被迫将 OpenSSL 加入到代码库中，他们希望每晚构建都能启动并运行——但就在昨天：
Vcpkg 紧急救援! Vcpkg 安装 OpenSSL 时，甚至显示出下列内容：
OpenSSL 包与内置 CMake 目标兼容：
找到包(OpenSSL REQUIRED)
目标链接库(main PRIVATE OpenSSL::SSL OpenSSL::Crypto)
这就是标准化的力量！Vcpkg 给出了如何将 OpenSSL 集成到构建中的有用提示，工作在一小时内就高效完成了！
VSCode 和 CMake
微软的Visual Studio 代码是一个开源的跨平台集成开发环境，其扩展机制对CMake 有很大的帮助。使用 VS 代码在 CMake 中进行构建，很轻松地就能建立一个 C++ 跨平台的项目。甚至可以使用 CMake:debug 这个优秀的轻量级编辑器调试代码。
CMake.js
Node.js 本机插件通常使用 node-gyp 构建，但是 CMake.js 公司允许使用CMake 构建插件。这对本地开发人员更为友好，因为他们不必再为另一个构建系统而痛苦不已。
结论
现代 CMake 是一个伟大的构建生成系统。多年来，许多著名的开源项目都采用了现代 CMake，因为其历经时间考验，功能强大，且支持所有的主要平台（对比 Make 的局部支持）。你与 CMake 的成功案例是什么？
