在大型项目中选择Scons和Waf

Nor*_*löw 16 python caching build-tools scons waf

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

目前:

  • 建造时间约为15分钟.
  • 大约100名开发人员
  • 大约10%的代码是C/C++/Fortran休息是Ada(使用gnatmake).

改进的潜在希望/收益是

  • 共享编译器缓存可缩短构建时间并需要磁盘空间
  • 维护更方便

SCons能否很好地完成这项任务?我已经看到它的评论没有缩放,也不像Waf.然而,这些已经有几年了.过去几年中,scons的表现有所增加吗?如果没有,与Waf相比,其表现不佳的原因是什么?

Mat*_*son 10

我一直在为我们公司开发一个工具链waf.它面向Fedora,Ubuntu,Arch,Windows,Mac OSX,并将推广到我们的嵌入式设备,在各种主机上进行交叉编译.

我们已经找到了waf允许通过工具,功能和其他方法实现包含可扩展性的方式,这使得为我们的项目定制和扩展非常容易.

就个人而言,我认为它非常出色,并且很好地将接口抽象为集成的不同工具.

不幸的是,我对Scons没有深入的经验,但有很多GNU Make/Autotools.我们waf在评估构建工具之后决定采用的是我们需要能够在各处运行良好的东西,这使得我们的构建工具得到了python的支持并且速度很快.我根据这些结果做出决定并从那里开始.


Bra*_*ady 8

在过去,SCons并不是高效的,但从那以后增加了很多改进.

我喜欢这两种选择,并且必须在6个月前做出同样的决定.我选择了SCons,因为它似乎拥有更大的用户和支持基础.

是一个有用的链接,可以将SCons与其他构建工具进行比较.

  • +1.我大多同意这一点.waf的问题在于API不稳定,并且切换到它的每个非KDE项目都会关闭,因此实际上没有用户库.(它也和scons一样冗长,并且文档较少.)我会说,如果你的项目没有进入scons砖墙,那么你添加的每个文件的大型项目突然花了17倍的时间,你会更好坚持用scons; 否则,waf值得一看. (2认同)

kir*_*sos 7

我个人更喜欢Waf,因为它更灵活,没有变种目录问题.

WAF

优点:

  • 单独的变体目录; 你不要用源文件混乱你的源文件夹(SCons也有这个,但默认情况下它没有打开,需要几次尝试才能工作)
  • 非常灵活
  • 自动依赖排序
  • 适用于许多Python版本(CPython 2,CPython 3,Jython和PyPy)
  • 您随应用程序一起分发它,因此用户只需要Python

缺点:

  • 一个痛苦延长
  • 可怕的未记录(尽管示例有帮助)
  • 不能很好地区分GCC和Clang(不确定SCons是否也存在这个问题)

使用SCons

优点:

  • 比Waf简单得多
  • 比Waf更容易扩展(见这里)
  • 记录得更好一些

缺点:

底线

这取决于你在寻找什么.总的来说,Waf似乎非常擅长管理大型项目(而不仅仅是因为速度),但是,如果你需要扩展它,那就去别处看看吧.另一方面,SCons更容易使用.

如果你决定和Waf一起去,只需将你的问题发布到邮件列表中.