语言/平台/构建无关依赖关系管理器

Question

我需要一个不受特定语言或构建系统束缚的依赖关系管理器。我研究过几种优秀的工具（Gradle，Bazel，Hunter，Biicode，Conan等），但都没有满足我的要求（见下文）。我也使用过Git Submodules和Mercurial Subrepos。

我的需求以及在presentation由丹尼尔·普法伊费尔在会C++ 2014中描述总结这种依赖性工具的目标（讨论@ 18：55所链接的视频的）：

• 不只是一个包经理
• 支持预建或源依赖性
• 可以下载或在本地找到 - 没有不必要的下载
• 获取使用各种方法（即下载，或VCS克隆，等）
• 集成与系统安装程序 - 可以检查LIB安装
• 无需以任何方式
• 无需适应构建系统
• 跨平台

适应源代码

进一步的要求或说明我要补充：

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

尼斯到有：

• 询问依赖管理后的，其实找一个地方依赖放置的方法。这将允许我创建VCS挂钩来自动更新共同开发的源代码repo依赖关系的依赖元数据中的散列。 （就像子模块或subrepos一样）。

Answer 1

在彻底搜索可用技术后，与各种语言的软件包管理器（即npm）进行比较，甚至在我自己的依赖管理器工具上运行，我已定居在柯南上。在深入科南之后，我发现它满足了我的大部分要求，并且易于扩展。

在研究柯南之前，我看到了BitBake作为我寻找的模型。但是，它只是Linux，并且主要面向嵌入式Linux发行版。柯南已经基本相同的配方特点和BB是真正的跨平台

这里是我的要求，我发现柯南：

• 不只是一个包管理器
• 支持预建或源依赖性

柯南支持经典的释放或开发的依赖，也可以让你的网络源。如果具有特定配置/设置的二进制文件不存在于注册中心（或Conan的说法“存储库”）中，则会从源代码构建二进制文件。如果LIB安装

柯南维护本地注册表缓存可以检查 -

• 可以下载或在本地找到 - 没有不必要的下载
• 集成与系统安装。因此，发生共享依赖关系的独立项目不需要重新进行昂贵的下载和构建。

  柯南不会阻止你找到系统包而不是声明的依赖关系。如果您编写构建脚本以通过前缀路径，则可以即时更改各个依赖项的路径。

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

  实施配方的source函数给出了一个依赖如何被取出的完全控制。柯南支持做下载/克隆源代码的食谱，或者可以“快照”源代码，将其与食谱本身打包在一起。

  • 无需适应的源代码以任何方式
  • 无需适应构建系统

  柯南支持各种发电机组通过您所选择的构建系统，使依赖耗材。来自特定构建系统的不可知论是柯南真正的胜利，并最终导致Bazel，Buckaroo等人的依赖管理繁琐。

  • 跨平台的Python 。检查。

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

  内置在考虑semver，但可以使用任何字符串标识符版本。另外还有user和channel作为软件包版本的命名空间。

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

  您可以防止不包括它在install取命令特定的依赖。或者您可以修改或覆盖生成的前缀信息以指向磁盘上的其他位置。

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

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

  • 询问依赖管理后的，其实找一个地方依赖放置的方法。这将允许我创建VCS挂钩来自动更新共同开发的源代码repo依赖关系的依赖元数据中的散列。 （就像子模块或subrepos一样）。

  发电机指向这些位置。借助Python的全部功能，您可以根据自己的内容对其进行自定义。

  目前共同开发的依赖项目对我来说是最大的问题。意思是说，我不知道柯南是否有开箱即用的功能来让跟踪提交变得简单，但我相信这些挂钩可以添加这个定制。

  其他的事情我在柯南发现：

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