Caching SCons缓存如何与不同的操作系统和CPU体系结构协同工作？

对于不同的操作系统和CPU体系结构是否安全？

当然可以跨不同的操作系统，但在同一操作系统上跨不同的CPU体系结构，不安全，默认情况下不安全。上一次我使用SCons缓存（v2.0.1版的SCons）时，它在不同的CPU体系结构中是不安全的。这就是我们在我目前的工作中停止使用它的原因。通过将体系结构正确地插入到构建环境中，可以使它变得安全，但是很难使它正常工作

---

除非您网络上的每台构建机器都有完全相同的硬件规格，否则我不建议使用SCons缓存，而是尝试使用变体目录。这至少可以使您在更改构建模式时不必重新构建所有内容。

这令人惊讶。我不认为我看到过许多多平台和多体系结构的邮件列表用户对此有任何抱怨。听起来像是将编译器引用为“gcc”，它没有路径，并且无论平台如何，您的命令行都完全相同，并且您将文件写入到与源代码完全相同的相对位置？我不认为我很清楚“CPU体系结构”指的是什么。我们遇到的最大问题是在同一个网络上混合使用intel和amd机器拉/推到scons缓存。结果生成的浮点模糊性则取决于谁首先生成并推送到scons缓存。我可以看到由32位和64位混合体系结构的构建机器网络造成的类似问题。32位机器上构建的构建签名可能与64位机器上的构建签名相同，但生成的对象肯定不兼容。因此，这是因为编译器执行-march=native，因此优化器抛出了在其他制造商的x86/x64实现上运行的次优代码？所以，如果您检测到这样的情况，并将-m32-m64和其他命令行放在命令行上，就应该可以了。基本上是将默认值放入命令行。甚至-DMY\u 32位\u英特尔\u标志也不起任何作用。应该足够了。另外，如果您将32位和64位输出写入到源代码的同一相对目录中（命令行中没有差异），这也会有所帮助。通常我使用variant_dir来指定每个arch/build的风格，我相信这也解决了cache dir问题。如果您遇到这样的问题，您将从scons用户邮件列表中获得帮助。@bdbaddog，我同意，我们使用带有子目录的变体目录，用于OS、32/64位、构建模式等，但是，当网络上不同构建机器中的处理器不相同时，我们仍然无法有效地解决不同处理器编译太不同二进制文件的问题。唯一有效的解决方案是为构建节点提供一个变体目录级别，但这扼杀了您对缓存的追求。这就是为什么我建议不要使用scons缓存，除非网络上的所有构建节点都具有相同的硬件规格。是的。缓存标识符应基于足够的信息，以使缓存引用在每个平台/体系结构中都是唯一的。如果你不这么认为，那就是一个bug。你看到这个有什么问题吗？（你的意思可能是“安全”而不是“保存”）