我该如何管理C或C++开源项目中的依赖关系？

Question

我有几个开源应用程序，它们依赖于一些第三方组件，尤其是Crypto++和Boost。有几种选择：

• 将第三方代码放入版本控制中，并将其与我的代码分发一起包含。一方面，这对于人们直接从我的源代码控制存储库编译使用最为简单。另一方面，他们可能会浪费带宽下载他们已经拥有的源代码，或者最终不得不与我的库做斗争以删除第三方部分。此外，源代码控制工具通常很难处理像Boost这样庞大的库。
• 根本不包括第三方代码。这迫使人们特意去使用我的库。另一方面，这意味着我的源代码控制存储库和分发将会很小。
• 还有某些我尚未预料到的东西。

我该怎么办？

注意：我不在环境下工作，不能依赖于类似于aptitude、apt-get或yum这样的依赖映射器。

- Billy ONeal

---

关于"源代码控制工具经常有问题"，您是否尝试使用bcp获取更可管理的boost子集？ - Steve Jessop

@Steve：没有，我会记住关于boost的事情，但其他库仍然存在相同的问题。 - Billy ONeal

关于链接，虽然我对Boost或CryptoPP不太确定，但您可能还考虑提供一个本地的“镜像”，其中包含您使用的依赖项版本，以便人们不会突然得到过时的链接。 - Matthieu M.

Answer 1

选项3: 不要将其包含在代码分发中，而是包含一个（链接到）下载，该下载应与您支持的最新版本相匹配。
同时，明确列出您的依赖项和您支持的最新版本。

这样可以让用户按照自己的喜好进行操作。想要与依赖项一起使用？从同一来源加载两者。只需部分依赖项因为已经拥有其他依赖项？加载其中的一部分。只想要你的代码？单独加载它。

选项4: 提供2个版本，一个包括依赖项，另一个不包括但与上述选项3结合使用。

- Xeo

---

我发现许多项目使用这种变体，其中链接实际上是可执行脚本，它获取依赖项并将其解压缩到正确的相对目录中。 - Ben Voigt

Git子模块在您的意思中是否被视为“链接”？我一直在使用Git模块进行依赖项管理，似乎效果很好。 - conradkleinespel

Answer 2

我建议使用Autoconf，它的设计旨在帮助您抽象掉这些烦恼。

我怀疑您能够预期维护所有平台上所有依赖项的构建脚本。将第三方代码放入svn中的另一个问题是现在您还需要跟踪它们的依赖关系等等。

- Andrew White

---

1. 我所说的是源代码分发，而不是二进制分发。共享与动态链接在此不适用。
2. Autoconf 在非 POSIX 系统上有些难以运行。

- Billy ONeal

@Billy：抱歉更新了一下，我想两个通常是配套使用的。 - Andrew White

@Billy：关于POSIX的评论，你可能想把它加到问题中去，因为排除apt-get和yum并不意味着非POSIX。 - Andrew White

只是发表了一条评论--这并不一定意味着这是一个糟糕的答案。依赖于Apt或Yum是不好的，因为你会将自己绑定到特定的发行版--因此我认为这样的答案毫无价值。依赖于POSIX是我不能做到的事情，但是很多读者可以，所以我欢迎这样的答案，即使对我来说它们并不是那么有用。 - Billy ONeal

Answer 3

我认为在SVN中拥有依赖关系是一个好主意。这样开发人员可以简单地检出和编译。此外，您还可以避免依赖项的不同不兼容版本问题。

如果您将依赖项放在单独的文件夹中，那么开发人员可以选择不检出您的依赖项，如果他们已经拥有它们的话...

- ronag

---

你如何处理跟进每个依赖项及其依赖项的更新？根据我的经验，对于任何不仅仅是琐碎库的东西，这几乎是不可能的。 - Andrew White

只要避免每天更新依赖项，它就能正常工作。如果您每两个月才一次性更新所有依赖关系，那也没问题。 - ronag

Answer 4

如果你有一个好的软件包管理器，那么我肯定不会在你的代码仓库中包含依赖项。如果你列出依赖项，对于编译代码的人来说，从软件仓库获取它们是相当容易的。

如果你愿意，你可以将所有依赖项作为附加下载包括在内。但是将它们与你的工作代码混合在一起通常不是个好主意。

- Leif Andersen