
SCons: A Software Construction Tool - rbanffy
https://scons.org/
======
wjakob
The maintainers of SCons have long argued perceived performance and
scalability issues do not exist
([https://github.com/scons/scons/wiki/WhySconsIsNotSlow](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.

~~~
maccard
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.

~~~
beagle3
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.

~~~
maccard
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.

------
jcl
One of my favorite SCons features is that it determines the necessary build
operations from file hashes rather than timestamps. Working on a project with
a long link step, it was wonderful to be able to rephrase comments, rename
local variables, or tidy code formatting and skip the link step, since scons
saw the object files had the same hash.

A few times, the skipped link step revealed to me that the code change I had
just made had no effect on the compiler output, usually because the compiler's
optimizer was already doing the same thing.

Likewise, hash-based compilation made git operations much smoother, since
things like rebasing or jumping back and forth between branches can update
timestamps without affecting content.

I know it's possible to hack similar functionality into some other build
systems by adding a layer of intermediate hash file targets everywhere. But
I'm a bit surprised the idea hasn't seen broader adoption... Having build
artifacts indexed by hash seems like it'd be a requirement for any system that
eventually wants to support large, distributed builds.

~~~
dfgdghdf
Buck and Bazel both work using hashes, if you are looking for a more modern
build system with this feature.

------
yegortimoshenko
Relevant section of Debian upstream guide:
[https://wiki.debian.org/UpstreamGuide#SCons](https://wiki.debian.org/UpstreamGuide#SCons)

As a Linux distribution maintainer, I second that. There are not that many
packages that still use SCons, but ones that do often require boilerplate
and/or patches to honor standard environment variables like CC, CFLAGS,
LDFLAGS. Cross-compiling a SCons package is a nightmare.

If you like that SCons uses Python, I'd suggest to try Meson. It does
everything right and exposes a subset of Python API:
[https://mesonbuild.com](https://mesonbuild.com)

~~~
detaro
How easy is it to extend Meson for languages that it doesn't ship support for
by default? That always seemed to be one of the strong points of
SCons/something many modern build systems don't support so well.

~~~
Hello71
Meson developers are highly opinionated regarding what "should" and "should
not" be supported, and aggressively block anything that might be considered,
or even lead to "badness". Sometimes this is justified, but it makes one's job
very difficult if one disagrees with them. For example, they insist on
completely integrating Rust into the build framework, but also (apparently)
don't have the manpower to actually implement that, so, coupled with the fact
that extending the language is impossible from within the language, practical
Rust (i.e. any dependencies, any Cargo use at all) is difficult to impossible.

------
gvalkov
I'm a build engineer and SCons is one of the gems in my tool belt. Where it
truly shines is as a framework for building build systems. At its core, it's
just a library for building and executing a DAG. What most SCons users work
with is the standard-library of rules built on top of the core API, that makes
it immediately usable as a "high-level" build system like Meson or Cmake. In
my experience, it's unparalleled when you have to model an entirely custom
build-flow in a clean way. I've used it to model build-flows for custom tool-
chains that would have been a nightmare to reason about if they were written
in GNU Make and outright impossible with a meta-build system.

The only other tools I've found to rival this flexibility are Gradle (see the
Software Domain Modeling chapter of its documentation) and Shake (though
having to write rules in Haskell makes it a hard pill to swallow).

------
ncmncm
MongoDB uses Scons to build their product, or did when I was there. MongoDB is
coded in respectable modern C++, with an admixture of Java bad habits and a
history of Google Style pessimization.

Among the most used articles on MDB's internal wiki is "Scons: It's Not That
Slow!"

In fact it is really quite, quite slow, but a universally popular add-on (not
officially "supported" when I was there), is a Ninja build scheduler that is
blindingly quick.

So, the slowness only manifests when you need to recalculate the dependencies,
which doesn't appear in the typical edit-build-test cycle. With Ninja,
combined with Ccache and a distributed build tool (whose name escapes me ATM),
coding at Mongo was not bad.

~~~
matthewbauer
This doesn’t exactly shine well on mongo’s development practices. Why go
through all of this trouble when you could use something that works well out
of the box like CMake? Maybe they like wasting money.

~~~
ncmncm
The answer is the same as everywhere: history. Not just the product build, but
continuous integration, test suites (test themselves are largely JS, of
course) and release management, are all tied together with Scons and lots of
custom Python.

It would just be a huge job migrating to something else, for little better
possible result than "it still works". And it does already work.

------
ginko
I really loved SCons and used it for most of my personal projects, but beyond
a certain project size it really starts to show performance issues. At work we
used to use SCons for a major code base and even running it without any source
changes took a good 30s.

We eventually switched to Blueprint.

~~~
javajosh
For better or worse, a name like "Blueprint" is virtually useless without a
link. Even googling is worthless, since it collides with...everything.

~~~
mkl
Duckduckgo for [blueprint build system] returns
[https://github.com/google/blueprint](https://github.com/google/blueprint) as
the first hit, so I think it's that.

Edit: Google, for me, _doesn 't_ return that on the first page, but the first
result is
[https://opensource.google.com/projects/blueprint](https://opensource.google.com/projects/blueprint)
which links to it.

~~~
javajosh
Interesting. DDG for "blueprint build tool" doesn't get anything relevant, but
"blueprint build _system_ " works fine. Sigh.

------
flanfly
I really like the idea of SCons. Writing Python is strictly better than using
the CMake language or m4. But, quoting one of my colleges: "SCons spends 5min
to figure out nothing needs to be done."

~~~
Mordak
I have exactly the opposite experience: I do not want to write a program to
compile my program.

Having used both scons and waf, and also having used make, cmake and cargo, I
would take any of the last three over scons or waf in a heartbeat. I think
cargo is far and away the nicest to use because there is very little to
actually _do_ to build your program. Using waf or scons was always an exercise
of 'I added a header file, so now I need to figure out the scons/waf API in
order to tell it what to do with it'.

------
nudpiedo
I worked long for years with scons and it is the worst and most terrible tool
I've ever seen and I would only recommend it to my worst enemies.

At the beginning might look good, with some "apparently" nice principles, but
beyond a certain point it will start growing in volume and complexity, like a
cancer grows, until its technical debt devoures whole teams of people and
impacts everyone performance and people starts quitting. Adding more people to
the build responsibilities doesn't help because it's impossible to maintain it
after more than 2 people have been involved in a large scons projects.

Together with the few fancy ideas that it has, there are other design
principles which do not scale from the human standpoint. It's nature of python
code for everything and the way builders and scanners are created, makes
impossible to follow the code flow and next to impossible to find certain bugs
unless the people who built the mess was a god of communication and an ascet
in coding discipline. Every single aspect from that build, as soon as more
than one target is compiled, will start growing unendlessly, moving the focus
from the project's business code to build environment's code. It's design
principles and monolitic structures together with its terrible underlaying
implementation of that horrible API make impossible to work in a team with
scons and the larger it gets the more it leads to giant unmaintaible build
environments which end up crashing randomly and no one can explain why or how
to make anything by themselves. And at some point the amount of features
pythin users end up embeddign there end up creating so much technical debt
that it makes feel impossible to justify the migration to a different build
system; whereas in reality other build environments might solve almost all the
non problems easier by skipping features no one wanted.

You might think I am exagerating because someone showed to you a scons hello
world, but then I will reply you that I've witnessed 3 different teams at a
large corporation escalating their scons based build environments to upper
management because it became an interminable source of conflicts and a black
hole of company's resources. The best case was when a full dedicated person in
a team of 10 people does all the build related work, and when I say all
related work, I trilly mean to write even the most basic aspects of every
single build, leaving the rest of the team in the ignorance and uncappable of
extending the build by themselves, or at best copy-pasting a snippet and
praying that it works.

Seriously, this tool is wrong for teams of all sizes bigger than 2 people. It
favors an unmaintainable mess only comparable with the worst spaghetti-worm-
hole codebases.

------
antonyme
IMHO SCons had some nice ideas but it falls down in practice in non-trivial
projects. Wrestling with eels is easier than doing cross-platform builds in
SCons. And while I do love Python, I think using a fully-fledged language is a
mistake.

I think a declarative DSL with scripting hooks behind it is a better model.
Having used many, many build systems over the years, I've never found one I
thought truly got things right (though several came close).

I actually think the ideas behind bjam ought to be revisited. It had a
declarative style, with scripting to support it. The implementation was awful
sadly; the tiniest mistake or typo would send the parser into a tailspin and
the documentation was truly confusing. Any errors were presented to the user
at the scripting level, which was even more confusing. But the idea of having
toolchains defined separately, and having traits and features was brilliant.
There's a lot to learn from there.

------
panpanna
I love new technology, but when it comes to build systems I am a stone cold
conservative.

Maybe it's just me, but I prefer even the ugliest make files to scons and
Gradle and what not. Because I have been burned too many times by
"improvements" in the build system making my code so compiling.

Am I the only one?

------
zaro
I have used it in a large codebase, and it was terrible.

Everybody must write python code to build their C++ files in a project. What
could go wrong?

------
dfgdghdf
In my experience SCons has the right design, but the implementation is
incredibly slow. Buck and Bazel are superior options.

~~~
microcolonel
This is why CMake is spectacular (for all of its many, many, many warts): it
spits out good, fast configurations for a large number of build runners; and
they all tend to work. CMake + Ninja is spectacular if you want to spend less
time compiling, but maybe not ideal if you are not familiar with CMake
idiosyncrasies and want to configure it for something. I usually find that I
can add a pkgconfig-based dependency to a CMake project without much fuss, but
anything much more complicated than that I typically do not enjoy.

------
onebaddog
I'm the current SCons project Co-Manager. Nice to see spirited conversation.

A couple data points on performance. A current snapshot of MongoDB's repo will
do a null incremental build in 53 seconds on my i7-2600 with non-ssd drive.
(Null incremental build = fully built tree. no need to rebuild anything).

In the last few releases we knocked that down from about 63 seconds.

Currently we're working on a number of performance related items and hope to
make some strides here.

Note the article sited is fairly old:
[https://github.com/scons/scons/wiki/WhySconsIsNotSlow](https://github.com/scons/scons/wiki/WhySconsIsNotSlow)
(from before 2.4).

That said there are (currently) faster build systems. SCons tends to be most
valuable when the build is complicated.

So as you can see.. the current maintainers don't argue that there are no
performance issues with SCons. But we're working on them.

------
Sir_Cmpwn
Nooooooooooo, please!

Try Meson instead:

[https://mesonbuild.com/](https://mesonbuild.com/)

------
nintendo1889
Bleeeech. CASE design? No thanks.

ihmo CASE (really automated policy configuration) is what people are now
calling "AI". It's really just a computer augmenting and assisting a human's
decision making.

------
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?

~~~
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.

------
dang
A thread from 2008:
[https://news.ycombinator.com/item?id=294887](https://news.ycombinator.com/item?id=294887)

------
umvi
I'm starting to think build systems should be built like LLVM with separate
front-ends and back-ends.

Imagine if CMake were separated into a front-end and back-end. You could use a
super nice Scons-esque pythonic front-end instead of CMake's crappy
proprietary language and still have all the benefits of CMake!

~~~
wheels
That's basically the way things already are. Current backends are things like
GNU Make, Ninja, Xcode and Visual Studio. CMake _is_ the frontend.

~~~
umvi
Well what I guess I mean is, I wish CMake were an API. That way I could use
the language of my choice to drive CMake instead of using its quirky/esoteric
language.

Ninja is indeed a build system backend but it's too low level. I want a
intermediate to high level backend that abstracts common things I want to do.

~~~
Koshkin
But why do you think the API would look any nicer?

~~~
umvi
Well the API would have bindings for common languages

------
oever
The best thing about SCons is the build cache. I wish more build tools had
that.

~~~
imglorp
It's a pretty old idea, going back to "derived objects" in ClearCase aka wink-
ins.

If you think about it though, it's not hard to cons up a tool that files
objects on disk by normalizing all the inputs to a compile step, and
retrieving that object if it exists. Here's one but there's others.

[https://www.commandlinux.com/man-
page/man1/ccache.1.html](https://www.commandlinux.com/man-
page/man1/ccache.1.html)

~~~
qznc
It might be ready for a revival. Bazel is halfway there.

[http://beza1e1.tuxen.de/version_control_and_build_systems.ht...](http://beza1e1.tuxen.de/version_control_and_build_systems.html)

------
jmakov
Can somebody summarize how ot compares to e.g. conan.io? I get the python
aproach but yet another build tool?

~~~
riquito
> yet another build tool?

Scons is 19 years old...

