Hacker News new | ask | show | jobs
by wjakob 2572 days ago
The maintainers of SCons have long argued perceived performance and scalability issues do not exist (https://github.com/scons/scons/wiki/WhySconsIsNotSlow).

I've long been really excited about SCons but eventually decided to move away because it became unbearably sluggish for a large-ish codebase with >180K lines of C++ code split into many files. Another issue are cross-platform builds. SCons breaks every time there is a new version of Visual Studio, and it takes many months until an updated version restores compatibility.

6 comments

That blog post is an impressive logical leap on the authors part.

I realise that the post is not from recently but the benchmarks are on seriously outdated software and hardwaee, those specs are over a decade old at this stage. His conclusions are also misleading, all of his graphs show that make is 2-10x faster than scons, and that make scales better than scons.he seems hell bent on proving there's no quadratic complexity, despite there being an order of magnitude of a difference!

On the other hand, I don't think it's reasonable to assume every build system will immediately support every compiler/IDE. At the end of the day, scons is an open source project and if that's the only issue stopping you using it, I'm sure they'd be happy to accept patches providing support rather than wait months.

Scons is almost 20 years old at this point. There are projects like waf that tried to fix it but ended up incompatible (and faster and more usable).

Scons has great ideas, but something either about the implementation or about reality fails to deliver.

As is cmake. Make is about to hit a mid life crisis, other projects like Ninja are faster and more lightweight, projects like WAF/Premake use a scripting language instead of a DSL, others liek FASTbuild claim to support distrobuted builds. At a certain point, sofradre has to be accepted for what it is, not what it claims to be.
I agree it's a peculiar system to use for benchmarking in 2018, but for comparison purposes it shouldn't matter much as long as the same software/hardware are used for both Make and SCons.

There's definitely some mental gymnastics and careful massaging going on to hide the performance problem. Would be a great example for a "How to lie with charts and graphs" article.

I think it is still invalid to consider for a benchmark. We don't consider a car track based on how quickly 10 year old cars can navigate it.

In the last decade we have gone from everyone needs an antivirus to Windows 10 is good enough for most people. We've had Spectre and meltdown, SSDs have become viable and been replaced by nvmE SSDs we've had a decade of OS development, filesystem development and hardware improvements.weve also had huge improvements in build ststems, Ninja was only relewaeed in 2012!

And yet, even after all of that, the TLDR from the article is "scons is an order of magnitude slower than make, but my hardware was the bottleneck before i figured it out scaled quadratically, therefore scons is not slow".

> On the other hand, I don't think it's reasonable to assume every build system will immediately support every compiler/IDE.

If your API is stable, why wouldn't it be reasonable to expect that it should work out of the box?

I don't think visual studio had ever claimed to have a stable API. 2019/2017/2015 have been good, but there was some definitely teething issues migrating to their current situation. That doesn't necessitate months of waiting - there is nothing stopping me or you adding support for an unstable API
Try WAF. It was created about twelve years ago as a fork of SCons because the author was dissatisfied with its performance problems. WAF is in my opinion a very capable build and configuration system but the main drawback is its small community. The person developing WAF isn't keen on "marketing" it.
The only place I have encountered WAF was at Bloomberg, where it was used to build the C++ foundation library (BDE) that Bloomberg uses in older projects in place of Boost and Std, both of which it predates.

WAF worked, and didn't seem especially slow, unlike Scons, but I frequently needed to code Python to make it do what seemed like pretty ordinary things.

The alternative I've enjoyed is Bazel.
Meson is basically SCons done right.
Personally I see Meson as an attempt to do CMake right. A big differences between Meson and SCons is that SCons handles the execution of the build graph, while Meson delegates execution to Ninja. The nice thing about the former is that while the graph is being walked, new nodes can be added. The nice thing about the latter is that it's incredibly efficient.
Why not both? :-) While the architecture is more similar to CMake, Meson's language reminds me of SCons---but it is a custom DSL and not Python, which makes things less surprising. For example in SCons a single-element list can be replaced with with the element itself, but that is a feature of SCons's builtins: if you write custom Python code, you can have confusing results when you place a string in a place where you must use a list of strings.

Also SCons is Turing complete and this makes it a bit of a stretch to call the language declarative; Meson keeps simple loops but is not Turing complete and the maintainers are okay with plans/pull requests that make Meson even more declarative. In Meson generally "there is only one way to do it", in SCons much less so which is ironic given it uses Python as the language.

All these systems annoy me with their dependencies... the only one that i kinda do not mind much is premake because it consists of a single self-contained executable. However even with that you need to have premake available. I'd prefer it if these programs took a page out of Autotools and created configuration scripts that only relied on whatever the target OS has available (plus the compiler) without having the need to install a separate build system since after a while you end up with a bunch of different build systems since everyone prefers theirs.
Meson's only dependency is Python, with no external packages needed---only the standard library.

The only annoying part of Meson is that it only supports a few compilers (GCC, clang, ICC, MSVC), and requires porting to new compilers unlike Autoconf.

Meson is very different to SCons. Meson is more like a better CMake.
It's not slow?

It takes it 30s, on a decent size codebase, just to tell you that there is "Nothing to do." There is order of magnitude difference between it and make. It's a complete travesty!

I’ve never heard of half these build systems - are they mostly used for Cxx heavy repos ?
Probably the biggest SCons project is Blender (unless they've switched to something else since last I worked on it).
Yes.