Post

SCons

SCons

Some thoughts from the backlog about SCons, a python scripting tool I had the pleasure of using.

TLDR; don’t use it. Just stick with CMake or any other build tool. And if you only read one thing: Some Lessons Learned.

Scones

As wiki explains: don’t confuse it with “scones” Source

But if not a Scone, what is SCons?

A python build tool that famously ignores environment variables (think CFLAGS) and is comparable to CMake.

Pros

  • Python
  • Reliable dependency analysis (supposedly)

Cons

  • Support for library versioning is absent
  • Ignores environment variables and path variables (unusual behavior)
  • There are very limited resources, examples, and documentation
  • No Automation possible (worst feature)
    • Because every SCons script is unique, and commonality is not enforced and making automation effectively unattainable

What Others Think

As I was compiling some of my thoughts about SCons I did some research… and I felt so validated.

“Please don’t use SCons. It is hard to use it correctly. For instance SCons is designed to ignore environment variables such as CFLAGS (unless your add code for this). It also does not support DESTDIR out of the box. As an upstream you have to explicitly add code for that (or Debian has to patch). Support for SONAMEs (library versioning) is also absent. The general observation is that many projects, that use SCons, do not have a working install target. Since projects work around these limitations individually there is no way to just use a SCons project in Debian, but more work is required to invoke it correctly.” Source

“SCons lacks many basic features required from a complete build system and thus it is mostly about reimplementing the wheel a dozen times. And doing that means a lot of pain to users and developers which have to adjust to custom solutions and be hit by repeating bugs in custom implementations.” Source (this site also includes a more detailed list of cons)

My experience and opinion

I wasn’t exposed to SCons until working in the industry. My prior experience with build tools was with CMake. I found my dislike for SCons grew the more I used it. My opinion is not divorced from other factors related to my work with SCons, but regardless I have found it an inconvenient and challenging build tool.

Our project was way too complex for SCons. Our SCon scripts were ridiculously long and exceptionally complex. I never truly understood what was really in these SCon scripts, and if I needed a new one, I’d just copy an old one. And I wasn’t alone. I didn’t know anyone on our team who actually wrote a SCons script. Imagine this happening for decades and you are looking at some very bloated and uncomfortably long scripts each slightly different from their predecessor.

Ideally I will never use SCons again. From my research I found it is not a popular build tool (I wonder why?) and I doubt many people will ever even hear the word SCons. So why is this experience at all relevant?

Some Lessons Learned

  • How did this happen? How did the build system never get upgraded as the software grew in complexity?
    • What is easy: “It works, don’t touch it.” What is hard: Looking at the big picture and updating and readdressing pain points as things grow. One mentality leads to growth, the other to stagnation.
  • How could this be improved?
    • Update the build system.
    • For my team there was no hope. The inconvenience of using SCons was actually a very minor problem that will likely never be addressed. But given the right people and emergency scenario it could happen!
    • Everyone will struggle with introducing change whether that be new processes, protocols, software or whatever. They are hard to adopt and they are hard to change. This reminded me of the following heuristic: how you introduce technological and social change is often more important than what you do.
  • What to consider before using unfamiliar software:
    • Community Support —> doesn’t feel important until you run into an issue
    • Toolchain —> Ensure the build system you choose integrates well with your preferred toolchain
    • Learning Curve —> It will take time to learn a new build system

If SCons is not it, what is the solution? A couple of brief thoughts

CMake is the most obvious/best solution.

There are a lot of different things you could look at depending on software size, complexity of tool, speed of build etc. Bazel could be a good pick for large complex projects. Another popular tool is Meson. It is newer and open source. It also integrates well with Ninja and can be faster and easier to learn than CMake.

Sconce

A Sconce, Also not SCons Source

Disclaimer: This is a pretty opinionated piece mostly based on personal experience and research. Please reach out if you’ve had a positive experience with SCons. I would love to hear about what worked well for you!

This post is licensed under CC BY 4.0 by the author.