语言/平台/与构建无关的依赖性管理器

Question

我需要一个不依赖于特定语言或构建系统的依赖项管理器。我研究了几种出色的工具（Gradle，Bazel，Hunter，Biicode，Conan等），但没有一个能够满足我的要求（请参见下文）。我还使用了Git子模块和Mercurial子仓库。

Daniel Pfeifer在Meeting C ++ 2014上的演示中很好地描述了我的需求。总结此依赖工具的目标（在链接的视频中@ 18：55进行了讨论）：

• 不只是包裹管理者
• 支持预建或源依赖
• 可以在本地下载或查找-无需下载
• 使用多种方法（例如下载或VCS克隆等）进行提取
• 与系统安装程序集成-可以检查是否安装了lib
• 无需以任何方式修改源代码
• 无需调整构建系统
• 跨平台

我还要添加其他要求或说明：

• 适用于第三方和/或版本化的依赖项，但也可以指定非版本化和/或共同开发的依赖项（可能由git / mercurial哈希或标记指定）。
• 提供一种机制来覆盖指定的获取行为，以使用我选择的某些替代依赖项版本。
• 无需手动设置依赖项存储。我不反对使用中央依赖性位置来避免冗余或循环依赖性。但是，我们需要克隆仓库和执行一些顶层构建脚本的简单性，这些脚本调用依赖管理器并构建所有内容。
• 尽管要求我不必修改构建系统，但显然某些顶级构建必须使用依赖项管理器，然后将这些依赖项提供给各个构建。该要求意味着个人构建不应了解依赖项管理器。例如，如果将CMake用于C ++程序包，则无需修改其CMakeLists.txt以使其特殊。定位依赖项的功能调用。而是，顶级构建管理器应调用依赖性管理器以检索依赖性，然后提供CMake可以传统方式使用的参数（即find_package或add_subdirectory）。换句话说，我应该始终可以选择手动执行顶级构建和依赖项管理器的工作，并且各个构建都不应该知道它们之间的区别。

很高兴有：

• 事后询问依赖关系管理器以查找放置依赖关系的方式。这将允许我创建VCS挂钩，以自动更新共同开发的源回购依赖项的依赖项元数据中的哈希。（就像子模块或子仓库一样）。

Answer 1

在彻底搜索可用技术，与各种语言（即 npm）的包管理器进行比较，甚至在我自己的依赖管理器工具上运行之后，我选择了 Conan。在深入研究 Conan 之后，我发现它开箱即用地满足了我的大部分要求，并且易于扩展。

在研究柯南之前，我将 BitBake 视为我正在寻找的模型。但是，它仅适用于 linux，并且非常适合嵌入式 linux 发行版。Conan 具有与 bb 基本相同的配方功能，并且是真正的跨平台

以下是我的要求以及我在柯南身上发现的东西：

• 不仅仅是包管理器
• 支持预构建或源依赖项

Conan 支持经典版本或开发依赖项，还允许您打包源代码。如果注册表（或“存储库”，用柯南的话）中不存在具有特定配置/设置的二进制文件，则将从源代码构建二进制文件。

• 可以在本地下载或查找 - 没有不必要的下载
• 与系统安装程序集成 - 可以检查是否安装了 lib

Conan 维护一个本地注册表作为缓存。因此，碰巧共享依赖项的独立项目不需要重做昂贵的下载和构建。

Conan 不会阻止您查找系统包而不是声明的依赖项。如果您编写构建脚本以传递前缀路径，则可以即时更改各个依赖项的路径。

• 使用多种方法获取（即下载或 VCS 克隆等）

实现source配方的功能可以完全控制如何获取依赖项。Conan 支持下载/克隆源代码的配方，或者可以“快照”源代码，将其与配方本身打包在一起。

• 无需以任何方式修改源代码
• 无需调整构建系统

Conan 支持各种生成器，使您选择的构建系统可以使用依赖项。来自特定构建系统的不可知论是柯南的真正胜利，最终使 Bazel、Buckaroo 等的依赖管理变得繁琐。

• 跨平台 Python。查看。

• 适用于第三方和/或版本依赖，但也能够指定非版本和/或共同开发的依赖（可能由 git/mercurial 哈希或标签指定）。

考虑到 semver 构建，但可以使用任何字符串标识符作为版本。此外，还有user和channel充当包版本的命名空间。

• 提供一种机制来覆盖指定的获取行为以使用我选择的某些替代依赖项版本。

您可以通过不在install命令中包含特定依赖项来防止获取特定依赖项。或者您可以修改或覆盖生成的前缀信息以指向磁盘上的不同位置。

• 无需手动设置依赖项存储。我不反对将中央依赖位置作为避免冗余或循环依赖的一种方式。但是，我们需要简单地克隆一个 repo 并执行一些调用依赖项管理器并构建所有内容的顶级构建脚本。尽管要求我不必修改我的构建系统，但显然某些顶级构建必须使用依赖项管理器，然后将这些依赖项提供给单个构建。该要求意味着单个构建不应该知道依赖项管理器。例如，如果将 CMake 用于 C++ 包，我应该不需要修改它的 CMakeLists.txt 来进行特殊的函数调用来定位依赖项。相当，顶级构建管理器应调用依赖项管理器来检索依赖项，然后提供 CMake 可以以传统方式（即 find_package 或 add_subdirectory）使用的参数。换句话说，我应该始终可以选择手动完成顶级构建和依赖项管理器的工作，而单个构建不应该知道区别。

Conan 在本地注册表中缓存依赖项。这是无缝的。您将在 Conan 的文档中看到的规范模式是在您的构建脚本中添加一些 Conan 特定的调用，但这是可以避免的。再一次，如果您将构建脚本编写为消费者前缀路径和/或输入参数，您可以将信息传入，而根本不使用 Conan。我认为 Conan CMake 生成器可以做一些工作来使它更优雅。作为后备，柯南让我编写自己的生成器。

• 一种事后询问依赖管理器以查找依赖关系的方法。这将允许我创建 VCS 挂钩以自动更新共同开发的源代码库依赖项的依赖项元数据中的哈希值。（就像子模块或子库一样）。

生成器指向这些位置。借助 Python 的全部功能，您可以根据自己的喜好对其进行自定义。

目前合作开发依赖项目对我来说是最大的问号。意思是，我不知道柯南是否有一些开箱即用的东西来简化跟踪提交，但我相信钩子在那里添加这个自定义。

我在柯南中发现的其他东西：

• Conan 提供了下载或构建我在开发过程中需要的工具链的能力。它使用 Python virtualenv 来轻松启用/禁用这些自定义环境，而不会污染我的系统安装。