这是关于 C++项目中依赖和包管理的系列的第三部分也是最后一部分，主要关注构建系统本身内置的解决方案。

• 概述：此部分将深入探讨meson wraps、cmake’s FetchContent、bazel’s central registry以及conda。

  • Meson WrapDB：Meson 可通过子项目集成依赖，支持 meson 和 CMake 构建系统，还提供了WrapDB，安装简单，能构建 rust 代码。其局限性在于无额外缓存，且 WrapDB 仅适用于 meson。

    • 测试：作者偏爱 meson，将inja集成到 meson 测试项目中很容易，但 meson 有自身局限性，如项目特定的subprojects目录外无缓存，WrapDB 仅适用于 meson 等。

  • conda：可描述为“包管理器”，创建环境并在其中安装项目依赖，类似于系统包管理器，使用channel存储预构建的包，还可创建自定义通道和安装本地包。

    • 测试：创建conda环境并安装相关工具，为inja创建 recipe 并构建，可创建本地通道并进行包分发，环境可导出存储。conda 感觉是成熟可靠的解决方案，但创建包的一些手动步骤可能不如spack自动化。
  • CMake FetchContent：是 CMake 的一部分，可在项目的 CMake 文件中直接声明和拉取外部依赖，使用简单方便，适合小规模项目，但不处理瞬态依赖，仅在项目的subprojects目录中缓存。
  • Bazel Central Registry：Bazel 有自己的版本管理器和编程语言，专注于构建隔离、并行性等，安装bazel可使用bazelisk，还需安装bazel build tools。工作区和 bazel 模块在处理传递依赖方面有所不同，bazel 能更好地处理依赖图，可手动集成非 bazel 项目，如通过rules_foreign_cc，也可使用 Bazel Central Registry 集成官方或本地包。
• 结论：C++中包管理和构建系统碎片化的现状可用 XKCD 漫画来概括，引入官方 C++包管理器可能也无法改变现状。大多数 C++项目需要为多个构建系统和包管理器提供支持，这给维护者带来了额外工作和潜在的问题。我们需要跟上时代步伐，以最小的依赖管理工作来维护代码库。