[yazr]

The main comment here seems to be sluggish performance.

Is it some sort O(n^2) rule handler deep inside the builder? Or is it just "python-slow" ? :/

Can someone give an example of a big open source project which is too slow to build?

[chadaustin]

I was on the original SCons team. It’s a lot of “python slow” but if someone build a daemonized version of the build graph that could be updated incrementally from filesystem change events it could be great. (A la Buck and Bazel)

[w0utert]

I think there’s a lot of exaggeration in the comments about SCONS being slow. We use it for a 300K LOC codebase, and while it is not as fast as cmake, it’s still perfectly serviceable. To be honest, for me the flexibility to do non-trivial customization of the build directly using Python code is well worth the somewhat slower performance. I always wonder what kind of build process people use if the overhead of the build system outweighs the compile time itself.

[ncmncm]

No, Scons really is dog-slow. How slow can be discovered by using the Ninja back-end plugin, with Ccache. Then it can be quite pleasant.

Of course if you only ever build from scratch, on one core, compile time will dominate, and you will wonder what the fuss is about.

[carlmr]

>I always wonder what kind of build process people use if the overhead of the build system outweighs the compile time itself.

Using Ninja as a benchmark, most of these higher level build systems take a lot of time to determine they have little to do, while ninja instantly determines this. The build performance rarely matters, the incremental build performance is where you waste a lot of time. Especially if you do TDD cycles.