在 c++ 中应该如何处理中间库依赖关系？

Question

我正在构建一个 c++ 存储库，它依赖于支持此存储库的外部公司存储库。我必须构建这些以针对特定于我的系统的某些版本的 boost 和其他库。在（长）构建过程结束时，我有几个静态库和完成的可执行文件。我使用 Docker 进行这些构建。

我正在尝试确定管理这些依赖项的最简洁方法。

• git 子模块和每次从源代码构建二进制文件（最长构建）
• 单独构建库并将它们存储为每个存储库的工件/版本（大部分工作，跨多个存储库）
• 编写一份关于如何重建二进制文件并将其提交到主仓库的自述文件（由于某种原因感觉很脏）

c++ 中处理这些中间二进制文件的常见做法是什么？

Answer 1

可能无法给出一个普遍有效的答案。您必须考虑您的代码的用户（我是指编译它的人）是谁以及他们的工作流程是什么。

我个人越来越倾向于您列表中的选项三——是的，README 文件。原因是在许多情况下，用户根本不需要（也不应该）为依赖而烦恼。通常会有更高级别的构建过程，以确保所有依赖项都按照应用程序的预期正确准备（下载、可选修补、编译和安装）。使用 Docker，我感觉这正在成为常态。我总是提供一个 Dockerfile（有时甚至是一个完整的 Docker 映像），其中所有依赖项都已就位，用户无需考虑这些就可以编译。

如果不是 Docker，可能还有其他更高级别的构建过程来处理依赖关系。由于我在嵌入式行业，我们主要使用 Yocto，但也有其他的。用户甚至不需要自己使用 Yocto，因为我为他们提供了一个包含所有依赖项的 SDK。

对于那些拒绝使用所有这些选项并坚持在他们的主机上进行本地编译的极少数人，我在 README 文件中写了一个依赖项列表，每行有几行，描述如何获取、编译和安装它们。

至于你提到的其他两个选项：

• 选项一（git 子模块） - 我必须说我从来没有真正适应过它。 IMO 它们在 git 中的实现有点糟糕（例如，要准确找出每个子模块当前签出的版本真的很麻烦）。此外，使用更高级别的构建过程，这可能意味着双重获取每个依赖项，这是低效的。如果必须的话，很难对依赖项应用补丁。您必须编写一些额外的脚本并将其包含在您的构建过程中。最后，您的依赖项可能本身就有依赖项，然后变得非常丑陋。
• 选项二（将二进制工件存储在 repo 中）是一个绝对紧急的解决方案，我总是会尽量避免。

因为有人提到了 git 子树——我们在团队中尝试了大约半年。这绝对是一场灾难。没有人真正理解它，大约每周一次有人搞砸了整个存储库。我再也不会使用它了。