我们公司正在从较低版本的Ubuntu Linux迁移到较高版本。在这个过程中，一些狗食者使用更高版本，而其他人则使用更低版本。我们发现bazel中的一些C++库可能在UbuntuLinux版本中共享bazel远程缓存上的相同"密钥"。因此，Ubuntu Linux版本a上的一个C++库的构建结果可能会被Ubuntu Linux版本B获取，即使它们使用不同版本的C++编译器、libstdc++和预构建的外部库。这可能会导致严重的问题。
有没有一种优雅的方法可以保证不同版本的Ubuntu Linux上的C++构建不会在bazel远程缓存上共享同一个密钥？
目前，我们所做的是让我们的构建工具自动生成一个辅助bazelrc文件，该文件附加了一个参数"--copt=-D_UBUNTU_VERSION_XX_YY"。这个C宏从未在我们的C++代码中使用过。相反，它只是确保不同版本的UbuntuLinux中的C++构建操作不会在远程缓存中共享相同的密钥。虽然这是有效的，但我们认为一定有更优雅的东西。
有两个选项：
- 使构建完全密封，因此它对系统的依赖性最小。除了使远程缓存值得信赖之外，hermaticity还具有可重复性和可用性优势——开发人员只需要安装Bazel和一个源树就可以构建任何东西，并相信他们会获得与其他人相同的输出。当然，从构建中删除外部依赖关系可能是一个漫长的过程
- 手动修改缓存密钥。自动进行系统工具链检测存在上游问题。不过，我不希望这里有神奇的解决方案。要在区分影响构建的系统差异和区分每个客户端(使远程缓存变得无用(之间取得机械平衡是很困难的