我的项目依赖于许多外部库，如GLFW3，GLEW，GLM，FreeType2，zlib等。最好在作业之间存储/共享已安装的依赖项，这样就不必下载/安装它们所有的时间都占用了大约一半的时间。我可以看到几个想法如何处理它：
a）为每个构建下载依赖项的每个作业并安装它们
b）将依赖项（源代码）放入我的仓库并且加速很少因为我将不再需要从外部服务器下载它们（仍然需要编译和安装它们）
c）手工编译它们，放在一些服务器上，然后为每个版本下载正确的包
a）我最不需要更新构建和测试的依赖项，允许使用最新版本来构建我的项目，但需要花费大部分时间（编译和下载）
b）膨胀存储库带有额外的代码（不是我的），提供很少的加速（下载通常不那么慢），添加手动工作来更新依赖关系，我想更糟糕的是a）c）速度最快，但需要我的大部分工作不断保持最新的内置依赖关系，并将它们上传到快速服务器上（每个构建任务（编译器等）也不同），允许最快的构建（只需下载和复制/安装）。
那么，您如何管理外部依赖关系并使其保持最新的travis构建？
请注意，我使用Travis的免费版本，并且有点需要sudo来更新cmake，gcc等并安装依赖项...可能会以某种方式欺骗CMake使用本地版本的依赖项而不是/ usr / ...但这不知何故膨胀我认为CMake应该非常简单明了。
答案 0 :(得分：0)
让我们在某个时间点调用依赖项“阵容”所需的整个依赖项集。
我从更新阵容版的任务中分离在您的版本中使用（某个版本的）阵容（当一个新版本的需要依赖） - 混合它们不必要地使图片混淆IMHO（我假设您的许多构建将使用相同的依赖性阵容版本。）
让我们首先看一下使用阵容。
根据您的描述，（已构建的）依赖项的安装对于所有3个选项是通用的，并且在每次构建时都会执行，所以我们暂时将它放在一边。
您的方法之间的区别仅在于您如何获得构建的依赖项：
似乎 a 和 c 基本相同，但 c 会因本地访问而更快。最有可能 b 是最慢的。
因此，在此背景下， c 似乎是构建速度前景的赢家。
现在的问题是，如果/如何在 c 方法中更快地在本地服务器上获得构建的依赖项阵容。我看到两个选项（不确定它们是否可能在您的上下文中）：
您还可以考虑使用两个选项的混合：使用选项 1 的某些依赖项，其他使用选项 2 ，如您所见。
现在，如果您正在为构建计算机使用VM（或docker或类似）映像，并且您可以控制此类映像，那么可能可以通过自定义这些VM映像来显着加速构建 - 在它们上安装依赖项阵容，使它们立即可用于运行此类自定义映像的计算机上的任何构建。
最后，当更新您的依赖关系阵容时（其中，BTW，也应该出现在 a 和 b 方法中） ，不仅仅在 c 中，你必须只需下载新的依赖版本，在需要时构建它们，将构建的依赖项存储在本地快速服务器上，如果自定义的VM映像解决方案有效为您，通过安装新的依赖项阵容来更新/重新创建自定义的VM映像。