避免不同Linux版本的bazel远程缓存冲突

我们公司正在从Ubuntu Linux的较低版本迁移到较高版本。在这个过程中，一些狗食者使用更高版本，而其他人使用更低版本。我们发现，BAZEL中的一些C++库可以在Ubuntu Linux版本上共享BAZEL远程缓存中的相同的“密钥”。因此，Ubuntu Linux版本A上的一个C++库的构建结果可以通过Ubuntu Linux版本B来获取，即使它们使用不同版本的C++编译器、LIbSTDC++ +和预构建的外部库。这可能会导致严重的问题

是否有一种优雅的方式来保证不同版本的Ubuntu Linux上的C++构建在BAZEL远程缓存上不共享相同的密钥？ 目前，我们所做的是让我们的构建工具自动生成一个辅助bazelrc文件，该文件附加了一个参数“--copt=-D_uUbuntu_VERSION_XX_YY”。这个C++宏在我们的C++代码中从来没有使用过。相反，它只是确保了不同版本的Ubuntu Linux中的C++构建行为在远程缓存上不共享相同的密钥。虽然这样做有效，但我们认为一定有更优雅的东西。

有两种选择：

使构建完全密封，因此它对系统的依赖性最小。除了使远程缓存可信外，Hermiticity还具有可再现性和可用性优势，开发人员只需安装Bazel和源代码树即可构建任何内容，并相信他们将获得与其他人相同的输出。当然，从构建中删除外部依赖关系可能是一个漫长的过程

如您所做，手动修改缓存密钥。有一个自动进行工具链检测的系统。不过，我不希望这里有一个神奇的解决办法。机械地平衡区分影响构建的系统差异和区分每个客户机（使远程缓存无用）是很困难的

---

谢谢你的回答！最后，我选择了您提到的第二个选项，并使我们最初的解决方案更加智能。我为C++工具链编写了一个存储规则。在规则中，ReaviTryyyCtx被用来运行'LSBY-Reloop-Rs’来收集Ubuntu Linux的版本，并将C宏添加到我们的C++编译器参数中。在我们公司，我们尽最大努力从源代码构建一切。然而，到目前为止，我们仍然在使用系统glibc、libstdc++和Qt。我们使用预编译的Qt主要是因为1。编译时间太长；2.没有人想为Qt源代码编写bazel构建文件：）