Why use Scons over (cmakelist.txt + automation)

[Advaitgaur004]

I want to know why should i use scons !?

Reason 1:

Cmake, you can use a cmakelists.txt file along with build scripts (like .sh or .ps1) containing all the necessary commands to build the project. cmakelists.txt handles source files, library linking, tests, and platform-specific configuration. Cmake generates native build files for tools like make, ninja, or visual studio, resulting in efficient builds with fewer system calls and lower overhead compared to scons, which executes build logic directly and can introduce additional processing overhead.
More system calls in python make it slow for larger projects.

Reason 2 :

In terms of manual labour its essentially the same. If you know little bit of automation
But in scons, unnecessary translation needed and its make it slow in every aspect when compared to cmakelist path.

Reason 3:

Both things, does not watch your files in realtime.

Reason 4:

If someones priority is fast builds, more scalability, and broad tool support, cmake with a script is usually the better choice over scons
regardless of the scripting language used in configuration.

*Please don't say it's because Python is easier to manage, that depends on individual perspectives.

Any comments are welcome! I’m not a hater, just genuinely curious

[mwichmann]

It seems like you have your mind made up already, so there's not a lot to say, I guess. Use the tool which feels comfortable to you.

SCons can also act as a build generator, which is CMake's purpose - SCons can generate a ninja build. CMake doesn't handle any building directly, although it has a convenience method to kick off the build. SCons does does indeed do a lot of work in the default "correctness is more important than speed" mode for a big project. For developer use, you can do stuff to speed it up - essentially making the same assumption that makefiles, ninja builds, etc. do: you trade not automatically recomputing dependencies for speed, and leave it up to you as teh developer, rather than the tool, to know when something has changed and stuff should be rescanned.

CMake has evolved over time, it's now relatively "target centric" - which matches how SCons has always been (old CMake was pretty cumbersome to use). You describe the relationship between desired targets and explicit sources, and SCons computes things from there.

Yes, CMake has better toolchain support: nobody would deny it's a bigger ecosystem (and with a commercial company behind it). SCons needs people to contribute more tool modules to keep up.

There's been no particular demand for file change notification - I'm sure it's come up but I don't recall any real discussion. That could potentially be added to "interactive mode", which leaves SCons running and makes incremental rebuilds fast because there's no startup time to pay, the dependency graph is already in memory. The ninja mode uses interactive to have a running copy that can be called back to for steps ninja shouldn't build, and I can see, conceptually, how file change detection could help there.

[Advaitgaur004]

I’m not a hater, just genuinely curious

I am familiar with this topic. Thank you for providing some background on SCons and its features, particularly the "interactive mode." I appreciate that information. I do have a follow-up question: In what real-world scenarios or types of projects have you found SCons to be a better fit than CMake, or vice versa?

**I'm interested in understanding the differing philosophies of each tool.

[mwichmann]

It's hard to speak for others. Projects such as Godot, Gem5 and Nuitka seem to be pretty attached to SCons. MongoDB was SCons based for a long time, they're now transitioning to Bazel, I don't think they ever considered CMake viable - but can't represent to you why.

[Advaitgaur004]

I am interested in nuitka because this source compiler is handy here. (I feel more attached to Scons in this topic, specifically for nuitka.)

[acmorrow]

It's hard to speak for others. Projects such as Godot, Gem5 and Nuitka seem to be pretty attached to SCons. MongoDB was SCons based for a long time, they're now transitioning to Bazel, I don't think they ever considered CMake viable - but can't represent to you why.

There is actually an interesting reason why.

We did an experiment moving from SCons to cmake early on. However, at the time, the library dependency graph in the MongoDB source code was not acyclic (and not easily made to be), and CMake of that era couldn't really handle that (I believe it now can). We also found that it was much easier to write python than CMake script, so we invested heavily in improving our SCons infra for several years, and we were able to do some things with it that are to this day very hard to achieve with CMake. As noted, they have moved to Bazel and I'm no longer involved, so I can't speak to the motivations or outcomes of that transition.

[Advaitgaur004]

However, at the time, the library dependency graph in the MongoDB source code was not acyclic (and not easily made to be)

Not my expertise here, but I do research, and it says "mongo allowed implicit, undeclared dependencies, which led to cyclic graphs not evident until switching to shared-library builds." I see a lot of TODOs in src/mongo/db/BUILD.bazel around cycle detection thanks to copilot that did heavy searching for me. Although my knowledge in this matter is very limited, still I look into coming days, what was the history.

CMake of that era couldn't really handle that

It's true, but now it is very efficient.

We also found that it was much easier to write python than CMake script

I'm sorry, friend, but I have to disagree. Ultimately, it depends.

SCons infra for several years, and we were able to do some things with it that are to this day very hard to achieve with CMake

I would love to hear the details whenever you have time. plz share your knowledge; I'm all ears, I am quite busy nowadays will look into the nitty gritty details later on, and just scratching the surface for the moment

cheers 🥂