我需要一个与特定语言或构建系统无关的依赖管理器。我已经研究过几种优秀的工具（Gradle，Bazel，Hunter，Biicode，柯南等），但没有一种能满足我的要求（见下文）。我也使用过Git Submodules和Mercurial Subrepos。
Daniel Pfeifer在Meeting C ++ 2014的presentation中详细描述了我的需求。总结了这种依赖工具的目标（讨论了链接视频的@ 18:55）：
我要补充的其他要求或说明：
尼斯到有：
答案 0 :(得分：3)
在彻底搜索可用技术后，与各种语言的包管理器（即npm）进行比较，甚至运行我自己的依赖管理器工具，我已经选择了柯南。深入柯南之后，我发现它开箱即可满足我的大多数要求并且易于扩展。
在调查柯南之前，我看到BitBake是我所寻找的模型。但是，它只是Linux，并且非常适合嵌入式Linux发行版。柯南具有与bb基本相同的配方功能，并且是真正的跨平台
以下是我的要求以及我在柯南所发现的内容：
- 不仅仅是包经理
- 支持预构建或源依赖
Conan支持经典版本或dev依赖项，还允许您打包源代码。如果注册表中存在具有特定配置/设置的二进制文件（或者＆＃34;存储库＆＃34;，在Conan的说法中），则将从源构建二进制文件。
- 可以在本地下载或查找 - 没有不必要的下载
- 与系统安装程序集成 - 可以检查是否已安装lib
Conan将本地注册表维护为缓存。因此，碰巧共享依赖项的独立项目不需要重做昂贵的下载和构建。
Conan不会阻止您查找系统包而不是声明的依赖项。如果编写构建脚本以传递前缀路径，则可以动态更改各个依赖项的路径。
- 使用各种方法（即下载或VCS克隆等）获取
实现配方的source功能可以完全控制如何获取依赖项。柯南支持下载/克隆源代码的配方，或者可以＆＃34;快照＆＃34;来源，用配方本身包装。
- 无需以任何方式调整源代码
- 无需调整构建系统
Conan支持各种生成器，以使您所选择的构建系统可以使用依赖项。来自特定构建系统的不可知论是柯南真正的胜利，最终使得Bazel，Buckaroo等人的依赖管理变得繁琐。
跨平台 蟒蛇。检查。
适用于第三方和/或版本化依赖项，但也能够指定非版本化和/或共同开发的依赖项（可能由git / mercurial哈希或标记指定）。
< / LI>
考虑到semver，但可以使用任何字符串标识符作为版本。此外，还有user和channel作为包版本的命名空间。
- 提供一种机制来覆盖指定的抓取行为，以使用我选择的某个备用依赖版本。
您可以通过不将其包含在install命令中来阻止获取特定依赖项。或者，您可以修改或覆盖生成的前缀信息，以指向磁盘上的其他位置。
- 无需手动设置依赖项存储。我并不反对中央依赖位置作为避免冗余或循环依赖的方法。但是，我们需要克隆repo并执行一些顶级构建脚本的简单性，该脚本调用依赖管理器并构建所有内容。 尽管要求我不必修改我的构建系统，但显然一些顶级构建必须使用依赖管理器，然后将这些依赖项提供给各个构建。该要求意味着各个构建不应该知道依赖管理器。例如，如果将CMake用于C ++包，我不需要修改其CMakeLists.txt来进行特殊的函数调用来定位依赖项。相反，顶级构建管理器应该调用依赖项管理器来检索依赖项，然后提供CMake可以以传统方式使用的参数（即find_package或add_subdirectory）。换句话说，我应该总是可以选择手动执行顶级构建和依赖管理器的工作，并且单个构建不应该知道区别。
Conan在本地注册表中缓存依赖项。这是无缝的。您在Conan的文档中看到的规范模式是在构建脚本中添加一些Conan特定的调用，但这可以避免。再一次，如果您将构建脚本编写到使用者前缀路径和/或输入参数，您可以传入信息而不使用Conan。我认为柯南CMake发生器可以使用一些工作来使它更优雅。作为后备，柯南让我自己编写发电机。
- 一种在事后查询依赖关系管理器以查找依赖关系放置位置的方法。这将允许我创建VCS挂钩以自动更新共同开发的源repo依赖项的依赖关系元数据中的散列。 （像子模块或子目录一样）。
发电机指向这些位置。凭借Python的全部功能，您可以根据自己的心灵内容进行自定义。
目前共同开发的依赖项目对我来说是最大的问号。这意味着，我不知道柯南是否有开箱即用的东西可以让跟踪提交变得简单，但我确信这些钩子会在那里添加这种自定义。
我在柯南发现的其他事情：