1

我有一个项目依赖于许多外部库，如 GLFW3、GLEW、GLM、FreeType2、zlib 等。最好在作业之间存储/共享已安装的依赖项，这样就不必一直下载/安装它们。大约一半的时间。我可以看到几个想法如何处理它：

a）为每个构建下载依赖项的每个作业并安装它们

b）将依赖项（源）放在我的仓库中并且几乎没有加速，因为我不再需要从外部服务器下载它们（仍然必须编译和安装它们）

c）手动编译它们，放在一些服务器上，然后为每个构建下载正确的包

a）它为我留下最少的工作来更新构建和测试的依赖项，允许使用最新版本来构建我的项目，但它需要大部分时间（编译和下载）

b）带有额外代码（不是我的）的膨胀存储库，几乎没有加速（下载通常不是那么慢），增加了手动工作来更新依赖项，我想比a）

c) 最快但需要我做大部分工作来不断更新构建的依赖项并将它们上传到快速服务器上（每个构建任务（编译器等）也不同），允许最快的构建（只需下载和复制/安装）。

那么，你是如何管理你的外部依赖并为你的 travis 构建保持最新的呢？

请注意，我使用 Travis 的免费版本，并且有点需要 sudo 来更新 cmake、gcc 等并安装依赖项......可能会以某种方式欺骗 CMake 使用本地版本的依赖项而不是 /usr/......但这会以某种方式使 CMake 膨胀，我相信应该很简单明了。

4

1 回答 1

0

让我们将您的构建在某个时间点所需的整个依赖项集称为依赖项“阵容”。

我会将构建中的（某个版本）阵容的使用与更新阵容版本的任务（当需要新版本的依赖项时）分开 - 混合它们不必要地使图片复杂化恕我直言（我假设您的许多构建将使用相同的依赖阵容版本）。

我们先来看看阵容的使用。

根据您的描述，（已构建的）依赖项的安装对于所有 3 个选项都是通用的，并且在每次构建时都执行，所以现在让我们把它放在一边。

您的方法之间的区别仅在于您如何获得构建的依赖项：

  • a - 从外部服务器下载它们 - 在每次构建时
  • b - 从 repo 源构建它们 - 在每次构建时
  • c - 从本地快速服务器下载它们 - 在每次构建时

似乎a和c基本相同，只是c由于本地访问而更快。b很可能是最慢的。

因此，在这种情况下，从构建速度的预期来看， c似乎是赢家。

现在的问题是，如果/如何使用c方法更快地在本地服务器上获取构建的依赖项阵容。我看到 2 个选项（不确定它们在您的上下文中是否都可能）：

  1. 从外部服务器（实际上只是将它们缓存在本地服务器上）下载已经构建的依赖项（就像您的 方法一样）
  2. 从源代码本地构建依赖项，除非您不必将这些源代码放在与项目相同的存储库中，也不必为每个项目构建构建它们（如在您的b方法中） - 您只需要在更新阵容时执行此操作（并且仅适用于相应依赖项的新版本）。

您还可以考虑混合使用 2 个选项：一些依赖项使用选项1，其他依赖项使用选项2，您认为合适。

现在，如果您在构建机器上使用 VM（或 docker 或类似）映像，并且您可以控制这些映像，则可以通过自定义这些 VM 映像来显着加快构建速度——在它们上安装依赖关系，使它们立即可用于运行此类自定义映像的机器上的任何构建。

最后，当需要更新您的依赖项阵容时（顺便说一句，您的 a和b方法中也应该出现这些，不仅在c中），您只需下载新的依赖项版本，并在需要时构建它们，将构建的依赖项存储在本地快速服务器上，如果定制的 VM 映像解决方案适合您，则通过安装新的依赖项阵容更新/重新创建定制的 VM 映像。

于 2015-08-22T01:04:39.403 回答