gradle - 语言/平台/独立于构建的依赖管理器

Question

我需要一个不依赖于特定语言或构建系统的依赖管理器。我研究了几个优秀的工具(Gradle、Bazel、Hunter、Biicode、Conan 等)，但没有一个能满足我的要求(见下文)。我还使用了 Git 子模块和 Mercurial Subrepos。

我的需求在 presentation 中有详细描述Daniel Pfeifer 在 Meeting C++ 2014 上。总结这个依赖工具的目标(在链接视频的 @18:55 讨论):

不仅仅是包管理器

支持预建或源依赖

可在本地下载或查找-无需下载

使用多种方法获取(即下载或 VCS 克隆等)

与系统安装程序集成 - 可以检查是否安装了 lib

无需以任何方式修改源代码

无需适配构建系统

跨平台

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

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

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

无需手动设置依赖存储。我不反对将中央依赖位置作为避免冗余或循环依赖的一种方式。但是，我们需要简单地克隆一个 repo 并执行一些顶级构建脚本，该脚本调用依赖管理器并构建所有内容。

尽管要求我不必修改我的构建系统，但显然某些顶级构建必须使用依赖管理器，然后将这些依赖提供给各个构建。该要求意味着各个构建不应该知道依赖管理器。例如，如果将 CMake 用于 C++ 包，我不需要修改它的 CMakeLists.txt 来进行特殊的函数调用来定位依赖项。相反，顶级构建管理器应该调用依赖管理器来检索依赖关系，然后提供 CMake 可以以传统方式使用的参数(即 find_package 或 add_subdirectory)。换句话说，我应该始终可以选择手动执行顶级构建和依赖管理器的工作，而单个构建不应该知道其中的区别。

很高兴有:

一种事后询问依赖管理器以查找依赖放置位置的方法。这将允许我创建 VCS Hook 以自动更新共同开发的源代码库依赖项的依赖元数据中的哈希。 (就像子模块或子存储库一样)。

Answer 1

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

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

以下是我的要求以及我对柯南的发现:

• Not just a package manager
• Supports pre-built or source dependencies

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

• Can download or find locally - no unnecessary downloads
• Integrated with the system installer - can check if lib is installed

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

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

• Fetches using a variety of methods (i.e. download, or VCS clones, etc.)

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

• No need to adapt source code in any way
• No need to adapt the build system

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

• Cross-platform Python. Check.

• Suitable for third-party and/or versioned dependencies, but also capable of specifying non-versioned and/or co-developed dependencies (probably specified by a git/mercurial hash or tag).

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

• Provides a mechanism to override the specified fetching behavior to use some alternate dependency version of my choosing.

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

• No need to manually set up a dependency store. I'm not opposed to a central dependency location as a way to avoid redundant or circular dependencies. However, we need the simplicity of cloning a repo and executing some top-level build script that invokes the dependency manager and builds everything. Despite the requirement that I should not have to modify my build system, obviously some top-level build must wield the dependency manager and then feed those dependencies to the individual builds. The requirement means that the individual builds should not be aware of the dependency manager. For example, if using CMake for a C++ package, I should not need to modify its CMakeLists.txt to make special functional calls to locate dependencies. Rather, the top-level build manager should invoke the dependency manager to retrieve the dependencies and then provide arguments CMake can consume in traditional ways (i.e find_package or add_subdirectory). In other words, I should always have the option of manually doing the work of the top-level build and dependency manager and the individual build should not know the difference.

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

• A way to interrogate the dependency manager after-the-fact to find where a dependency was placed. This would allow me to create VCS hooks to automatically update the hash in dependency metadata of co-developed source repo dependencies. (Like submodules or subrepos do).

生成器指向这些位置。借助 Python 的全部功能，您可以随心所欲地对其进行自定义。

目前共同开发依赖项目是我最大的问号。意思是，我不知道柯南是否有一些开箱即用的东西可以使跟踪提交变得容易，但我相信钩子(Hook)在那里可以添加这种自定义。

我在柯南中发现的其他内容:

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