在大型项目中选择scon和Waf

Question

我们正在考虑将一个非常大的项目从使用GNU Make转换为一些更现代的构建工具。我现在的建议是使用SCons或Waf。

目前：

• 构建时间大约为15分钟。
• 大约100名开发商。
• 约10%的代码是C/C++ +FORTRAN REST是艾达（使用GnAtGub）。

改进的潜在希望/收益是

• 共享编译器缓存以减少生成时间并需要磁盘空间
• 更容易维护

SCons能很好地适应这个任务吗？我也看到过对它的评论没有Waf那样的可伸缩性。不过，那是几年前的事了。斯科恩斯在过去几年的表现中有进步吗？如果没有，与Waf相比，它的性能差的原因是什么。

Answer 1

我个人更喜欢Waf，因为它更灵活，不存在变量目录问题。

华夫

优点：

• 单独的变量目录；你不会把你的源文件夹和对象文件混在一起（SCons也有这个，但它在默认情况下不是打开的，需要一些尝试才能工作）
• 非常灵活
• 自动相关性排序
• 适用于很多Python版本（CPython 2、CPython 3、Jython和PyPy）
• 您将它与应用程序一起分发，因此用户只需要Python

缺点：

• A要延长的疼痛
• 严重的文档不足（尽管示例有帮助）
• 没有很好地区分GCC和Clang（不确定SCons是否也有这个问题）

烤饼

优点：

• 比Waf简单得多
• 比Waf更容易扩展（参见here）
• 有更好的记录

缺点：

• Scalability issues（注意SCons isn't actually quite that bad，buy it仍然会随着大小的增加而稍微慢一点）
• 丑陋（这是100%的个人观点）

底线

这取决于你在找什么。一般来说，Waf似乎非常擅长管理大型项目（不仅仅是因为速度），但是，如果您需要扩展它，请查看其他地方。另一方面，SCons更易于使用。

如果您决定使用Waf，只需将您的问题发布到mailing list。

Answer 2

我一直在为我们公司开发一个围绕waf构建的工具链。它的目标是Fedora、Ubuntu、Arch、Windows、MacOSX，并将推出到我们的嵌入式设备上，在各种主机上进行交叉编译。

我们发现waf通过工具、特性和其他方法允许包含的可扩展性，使得为我们的项目定制和扩展变得异常容易。

就我个人而言，我认为它很出色，并且发现它很好地将接口抽象为集成的不同工具。

不幸的是，我对Scons没有深入的经验，但对GNU Make/Autotools有很多经验。在评估构建工具之后，我们决定使用waf，这是因为我们需要在任何地方都能正常工作的东西，这使得我们的构建工具得到了python的支持，而且速度很快。我的决定是基于these results然后从那里出发。

Answer 3

在过去，SCons的性能没有以前那么好，但是从那时起已经有了很多改进。

我喜欢这两种选择，大约6个月前不得不做出同样的决定。我选择了SCons，因为它似乎有更大的用户和支持基础。

Here是一个有用的链接，可以将scon与其他构建工具进行比较。