30、未来展望：CMake 4.0的新特性、FetchContent的发展方向、C++模块化与依赖管理的未来

说实话，写这一章的时候我有点感慨。从第一节课讲CMake的基本语法，到现在聊未来趋势，咱们已经走了很长一段路。我记得2018年刚接触FetchContent时，它还只是个实验性功能，很多人连听都没听过。现在呢？它几乎成了现代CMake项目的标配。

但技术这东西，永远不会停在原地。CMake 4.0已经在路上了，C++20的模块化也慢慢落地，依赖管理的方式正在发生根本性变化。今天我就结合自己的观察和实践，跟你聊聊这些趋势。

CMake 4.0：我们期待什么？

CMake 4.0不是一个小版本升级。按照Kitware的规划，这会是一次有破坏性变更的大版本。我去年参加了CMake的线上开发者会议，听他们聊了一些方向，这里挑几个跟我关系最密切的说说。

预设工具链（Preset Toolchains）

CMake Presets在3.19引入后，大家用得越来越多。但有个痛点一直没解决：工具链文件（toolchain file）的配置太繁琐了。你想想看，每次换编译器或者交叉编译，都得写一堆set()命令。

CMake 4.0计划引入预设工具链机制。说白了，就是把工具链的配置也做成preset的一部分，直接声明编译器路径、标志、系统根目录等。我在一个嵌入式项目里试过早期的原型，感觉确实省事不少。

{
  "version": 6,
  "toolchains": {
    "arm-gcc": {
      "compilers": {
        "C": "/usr/bin/arm-none-eabi-gcc",
        "CXX": "/usr/bin/arm-none-eabi-g++"
      },
      "sysroot": "/opt/arm-none-eabi",
      "flags": {
        "common": ["-mcpu=cortex-m4", "-mthumb"],
        "CXX": ["-fno-exceptions"]
      }
    }
  },
  "configurePresets": {
    "arm-debug": {
      "toolchain": "arm-gcc",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": "Debug"
      }
    }
  }
}

嗯，这里要注意：这个语法还在讨论中，最终发布时可能会有调整。但方向已经很明确了——让工具链配置像preset一样可复用、可组合。

更好的包管理集成

CMake 4.0会进一步强化与包管理器的集成。目前FetchContent和CPack之间其实存在断层：你下载了依赖，但没法方便地把它打包成二进制分发给别人。新版本计划引入依赖导出机制，让FetchContent下载的库可以直接生成安装目标。

我曾经在一个团队里遇到过这样的场景：我们用FetchContent拉了十几个第三方库，每次CI都要重新编译一遍，耗时将近40分钟。如果能把编译好的依赖缓存起来，或者打包成二进制分发给其他开发者，效率会提升很多。CMake 4.0的依赖导出功能，就是为了解决这个问题。

FetchContent的发展方向

FetchContent从3.11引入到现在，已经迭代了好几个版本。我个人觉得，它最核心的改进方向有三个。

增量下载与缓存

现在的FetchContent每次执行configure都会重新检查依赖是否更新。如果依赖没变，它确实不会重新下载，但检查过程本身是有开销的。尤其是当你依赖了十几个Git仓库时，每次都要跟远程服务器通信，慢得让人抓狂。

我记得有一次，项目里有个同事在咖啡厅用热点编译，FetchContent检查依赖花了将近两分钟，他差点把电脑摔了。后来我帮他配了FETCHCONTENT_QUIET和本地缓存，情况才好转。

未来的FetchContent会引入更智能的增量下载机制。比如，通过本地哈希缓存来判断依赖是否真的需要更新，而不是每次都去拉取远程元数据。另外，离线模式也会得到更好的支持——你可以在有网络时预下载所有依赖，然后在无网络环境下直接使用缓存。

依赖图可视化

这个功能我期待很久了。目前FetchContent的依赖关系是隐式的——你只能在CMakeLists.txt里看到FetchContent_Declare和FetchContent_MakeAvailable，但依赖之间的层级关系、版本冲突，都得靠脑子记。

CMake 4.0计划加入依赖图导出功能，可以生成JSON或Graphviz格式的依赖关系图。你想想看，一个大型项目可能有几十个直接依赖和上百个传递依赖，有了可视化工具，排查版本冲突会轻松很多。

版本锁定与语义化版本支持

现在的FetchContent对版本控制的支持比较弱。你只能指定Git标签、分支或提交哈希，没法像npm或Cargo那样声明^1.2.3这样的版本范围。这导致了一个问题：依赖的版本升级往往需要手动修改CMakeLists.txt。

未来的FetchContent会引入版本锁定文件（类似package-lock.json或Cargo.lock），记录所有依赖的确切版本和哈希值。同时，语义化版本解析也会被支持，你可以声明VERSION_REQUIREMENT ">=1.2.0 <2.0.0"，系统会自动选择满足条件的最新版本。

C++模块化与依赖管理的未来

这个话题比较宏大，我尽量说得接地气一些。C++20引入了模块（Modules），这不仅仅是语法糖，它从根本上改变了C++的编译模型和依赖管理方式。

模块化对依赖管理的影响

传统的头文件方式有个根深蒂固的问题：接口泄漏。你引用一个头文件，它可能又引用了十几个其他头文件，最终导致编译时间爆炸、符号冲突、宏污染。我在一个老项目里见过，一个简单的#include <boost/asio.hpp>，预处理后能生成几万行代码。

模块化解决了这个问题。模块只导出你明确声明的接口，内部实现完全隐藏。这意味着：

• 编译速度大幅提升：模块的编译结果可以被缓存，不需要重复解析头文件
• 依赖关系更清晰：你只需要知道模块的接口，不需要关心它的内部依赖
• 符号冲突减少：模块有命名空间隔离，不会出现宏污染

但模块化也给依赖管理带来了新挑战。比如，FetchContent下载的库如果使用了模块，CMake需要知道如何找到这些模块的编译产物。目前CMake对模块的支持还在完善中，3.28版本引入了CMAKE_EXPORT_MODULES，但距离成熟还有一段路。

模块化与FetchContent的协同

我个人认为，未来的FetchContent会深度集成模块化支持。具体来说：

• 自动发现模块接口文件：FetchContent下载的库如果包含.ixx或.cppm文件，CMake会自动识别并注册为模块
• 模块依赖图：类似前面提到的依赖图可视化，但粒度更细——可以展示模块级别的依赖关系
• 模块缓存：编译好的模块单元可以被缓存和复用，进一步加速构建

我记得去年在CppCon上听了一个演讲，演讲者展示了一个实验性的构建系统，它把FetchContent和模块化结合起来，编译一个包含几十个模块的项目，速度比传统头文件方式快了将近5倍。虽然那还是原型，但方向已经很明确了。

依赖管理的终极形态

说了这么多，我想试着勾勒一下未来依赖管理的终极形态。当然，这只是我的个人推测，不一定准确，但你可以参考一下。

这张图展示了我心目中未来依赖管理的四层架构。每一层都有明确的职责，层与层之间通过标准接口通信。这样做的好处是：你可以替换任意一层而不影响其他层。比如，你可以用vcpkg替换FetchContent的下载层，或者用Conan替换解析层。

一些现实中的思考

说了这么多美好的未来，我也想泼点冷水。C++模块化虽然好，但普及速度可能比我们想象的要慢。原因有几个：

• 编译器支持不统一：GCC、Clang、MSVC对模块的实现进度不一致，跨平台项目很难统一使用
• 现有库的迁移成本：把现有的头文件库改造成模块，需要大量工作，很多开源项目可能不会优先做这件事
• 构建系统的适配：CMake对模块的支持还在完善中，其他构建系统（如Bazel、Meson）也在追赶

我曾经在一个新项目里尝试全面使用C++20模块，结果发现某个第三方库的模块接口文件在Clang下编译不过，最后不得不退回传统头文件方式。嗯，这件事让我明白了一个道理：新技术虽好，但落地时一定要考虑生态的成熟度。

总结

CMake 4.0、FetchContent的进化、C++模块化，这三者其实指向同一个方向：让依赖管理变得更简单、更可靠、更高效。我个人觉得，未来两到三年，我们会看到：

• CMake成为C++依赖管理的事实标准（就像npm之于JavaScript）
• FetchContent与vcpkg、Conan等包管理器深度融合
• 模块化逐步取代头文件，成为C++代码分发的主流方式

但不管技术怎么变，核心的原则不会变：清晰的依赖声明、可复现的构建、高效的增量更新。这些原则，我们在前面29节课里已经反复强调过了。掌握了这些，无论未来工具怎么变，你都能快速适应。

好了，这一章的内容就到这里。希望这些展望能给你一些启发，也欢迎你在实践中验证这些趋势。毕竟，最好的学习方式就是动手去做。

公众号：蓝海资料掘金营，微信 deep3321