
SCons is not slow - moonchild
https://github.com/SCons/scons/wiki/WhySconsIsNotSlow
======
qppo
I feel like if you close with "only 20% slower than make" you can't justify
the title "is not slow."

20% is a pretty huge margin for large builds, which I wouldn't consider using
make for in the first place. CMake + Ninja has shaved enormous amounts of time
off my builds from make, so why should I use something that's even slower?

~~~
Y_Y
As a counterpoint, my builds are mostly too fast to care, but modifying the
CMake files that describe them is excruciating. It's a miracle of software
engineering that CMake functions, but wow is the language awful.

~~~
umvi
Yeah we switched from Scons to CMake and I have to admit I loved being able to
use python for Scons. CMake's language is unintuitive and clunky. I wish CMake
had been designed like LLVM with a front and back end so that there could be a
python-based front end (for example).

~~~
bb88
Yeah, I've been unhappy with any automake system for a long time. Haven't
tried ninja though. Scons was fine-ish.

Now that because work forces me to develop on a locked down windows box, make
is the last thing I want.

~~~
ncmncm
Ninja is not a build system, it is an interpreter for the output of a build
system.

A very, very fast interpreter, with truly admirable process-management skills.

------
ncmncm
I don't know if SCons is _still_ slow, but in 2018 it was definitely very,
very slow. I doubt it has improved much, as its maintainers were in similar
denial then.

When we used it at MongoDB, somebody (thanks Mathias!) put together apparatus
to make it generate a ninja config instead of building by itself. That was
fast! Anyway, after you had the ninja config.

But the edit-build-test cycle did not include a slow SCons run anymore, and
that was huge.

The MongoDB internal wiki had a page titled "SCons Isn't _That_ Slow", with
advice for how to live with how slow it really was, later including
("unofficial") ninja and ccache setup. (Which I added.)

But at least it wasn't WAF.

~~~
bsder
> I don't know if SCons is still slow, but in 2018 it was definitely very,
> very slow. I doubt it has improved much, as its maintainers were in similar
> denial then.

And, at this point, its time has passed.

The big projects that were using scons all moved on to other systems for
various reasons.

Better to move on to something that actually might generate a critical mass
and community.

~~~
onebaddog
Actually not true. Many large projects continue to use SCons and new projects
as well. I don't think in 2018 we had our heads in the sand about SCons'
performance. As project maintainer I've (along with other community members)
have been working on performance since at least 2016.

~~~
ncmncm
If you had a hand in getting it to generate ninja scripts: Congratulations.
That made a big improvement in the daily experience of people maintaining
projects built under SCons.

To be clear: SCons is not notably worse at describing what must be done to
build a big project than other systems of its time. Lots of code has been
compiled under it. Its deep failure has been in trying to direct the
activities of compilations in real time, at which it is bad, gmake is good,
and ninja positively excels.

Still, slowness in resolving dependencies is hard to defend. It is a problem
in operations long well-understood, with familiar algorithms. A data structure
well tuned to the algorithm would make even Python able to solve it quickly
enough.

Nowadays the difficult part of a build system is the complexities of managing
foreign dependencies, at which CMake is only just adequate.

------
beervirus
Rebuttal here: [https://blog.melski.net/2013/12/11/update-scons-is-still-
rea...](https://blog.melski.net/2013/12/11/update-scons-is-still-really-slow/)

~~~
cbsmith
I'm just kind of amazed that there is this kind of lack of understanding of
performance & measurement amongst people working on optimizing low-level
technical tools like build systems.

~~~
ncmncm
To be fair, not _all_ such people; by the evidence, only SCons people.

~~~
cbsmith
It was absolutely not intended as a statement about _all_ such people. The
surprise is about _any_ such people.

------
dTal
Ironically, hitting the front page of HN with a title of "SCons Is Not Slow"
is, for me, _excellent_ circumstantial evidence that SCons is, in fact, slow.

------
mmorearty
Scons is definitely slow in some scenarios. It has O(m * n) performance if a
rule has m inputs and n outputs. I tdiscovered this when working with a code
base that had a single rule with all .ts files as inputs, and all .js files as
outputs. As the number of files we had got bigger, SCons got painfully slow.
Of course we can rewrite our rules, but that shouldn’t be necessary,
especially since it was quite hard to figure out why our builds got so slow.

------
dimator
Slow or not, it becomes cryptic to write Sconsfiles with any complexity, and
it's _impossible_ to debug.

~~~
sgtnoodle
It's python, so you can write your own abstractions as you see fit. Like any
general purpose programming language, you can make something maintainable or
you can make a mess.

~~~
TazeTSchnitzel
Sometimes having a tool prevent you from shooting yourself in the foot is
kinder.

But it's more than that, a good build system does not need to be Turing
complete, and having Turing completeness imposes certain requirements on it
that may make it inherently slower.

~~~
sgtnoodle
Going along with the firearm analogy, it's only fully useful and powerful tool
once you've removed it from its case and removed the trigger lock. Any given
firearm may have additional safety features such as interlocks, but they're
only effective if they stay out of the way when you intend to shoot. You avoid
accidentally shooting yourself and others through training, practice and
discipline: treat any firearm as if it were loaded, keep your finger off the
trigger until you intend to shoot, etc.

When setting up a build system for multiple people to use, it's important to
agree on a general approach and some rules to follow in order to keep the
system from turning into a mess. It's code like anything else, and benefits
from training, practice and discipline. Using a language that most folk
already know is almost always better than using an obscure one out of a sense
that the obscurity makes it safer.

When building up a build system, I suggest focusing on designing abstractions
to make 90% of use cases trivial for other developers to use. Spitting out
libraries and linking them into binaries, existing autocoding scripts, etc.
The other 10% of cases that other folk run into, loudly volunteer to make
yourself available to help them work through it. Most of the time, there's a
way to do what they need that isn't horrendous, or you can take the
opportunity to improve your abstractions.

If your problem is that other developers you work with just go in with a
hatchet and make a mess without informing anyone, perhaps it's time to adobt
some processes to address that, such as better version control hygiene and
code reviews.

------
onebaddog
As the maintainer of SCons I can assure you that we are aware of SCons's
performance issue.

The page in question is actually quite old at this point.

Since the content was written Ninja, Cmake, Bazel, and other build systems
have launched and become mature.

We are slowly working through the easiest of the list of known performance
issues.

In addition MongoDB has contributed their Ninja file output logic. We expect
to integrate that in the next major release.

Projects like MongoDB, Godot, VMware, PlatformIO, and many others use SCons.
One of it's strengths is the ability to correctly build complex builds.

Please engage with the community our users mailing list, IRC Channel, or
discord server if you're a user.

One frustration for the project is that users run into issues using SCons and
never reach out and ask for help. Many times a small change in usage will
resolve whatever has a user stuck.

------
amelius
I hope that FOSS can converge to a single build system as much as possible,
because it's not very convenient to learn them all.

~~~
CameronNemo
I don't think a single build system is necessary or desirable. meson (as well
as waf and scons) depends on python, which is not so nice for bootstrapping.
Thus desktop applications and low level userspace plumbing could benefit from
different build systems.

That said, I hope waf and scons die off soon (only a handful of packages even
use them). CMake and Meson are much better choices.

~~~
amelius
> I don't think a single build system is necessary or desirable.

Why not? In the old days, it was "./configure; make". Today, it's much less
certain what build system(s) you'll have to deal with when building a FOSS
tool. That's not a problem when everything works, but as experience shows,
more often than not you'll run into issues and then I would say it's nice if
you are familiar with the system.

And just like with other tools it's nice if everybody uses the same thing.
Github wouldn't exist if everybody rolled their own version control system,
for example.

~~~
progval
> Github wouldn't exist if everybody rolled their own version control system,
> for example.

It also wouldn't exist if no one did. It's all about compromises. Having too
many tools for the same job isn't good, but monoculture isn't either.

------
budabudimir
Indeed, I had the misfortune of using SCons on one project back in 2017-2019.
It was ridiculous how slow it was. Even for the case when "Nothing to be done"
was the result it took 20-40 seconds to output the message.

Thankfully we switched to ninja.

------
gfxgirl
SCons is the worst experience I've had with a build system. No one, even its
advocates, ever really understood what was going on. Things became so much
simpler and orders of magnitude faster when we switched away

~~~
stingraycharles
You must not have used cmake. It’s fast but man is it cryptic and has a steep
learning curve.

------
mypalmike
Maybe add (2014) to the title? It looks like the text may have been revised a
few times since, but the original appears to be at least that old.

------
29athrowaway
I have not tried SCons, and I have not heard about it in a while. Is it good?
who does it compare to CMkae or Bazel?

For context, I don't like autotools.

~~~
sgtnoodle
It's good in that it's mature, cross platform, and it's python so you can
build whatever you want on top of it. We use it at work for a relatively large
codebase that targets multiple languages and architectures.

I like python a lot better than cmake's syntax. It's nice to be able to define
functions and importable modules to abstract away the ugly details of the
build so that other developers can safely use them without being build system
experts.

Bazel is cool, but it's relatively immature. Last time I looked into it, you
couldn't just install it easily. It's easy enough to make scons look like
bazel. I suspect bazel handles very large codebases more efficiently.

------
person_of_color
Do people use tup?

~~~
chenglou
Tup requires FUSE, so is a deal breaking dependency for many corporate setups
due to security.

If you’re into Tup, you might also like
[https://github.com/droundy/fac](https://github.com/droundy/fac)

Fun fact: ninja was inspired by Tup, but is a bit more geared toward pragmatic
usages.

~~~
papaf
I think tup used to use LD_PRELOAD and seems to still support it:

[https://github.com/gittup/tup/issues/394#issuecomment-636378...](https://github.com/gittup/tup/issues/394#issuecomment-636378846)

------
person_of_color
We need a deep learning based build system.

