SCons Rant

Why oh why is it that there is no sane cross-platform build system out there?

If it weren’t for a few (recent and not so recent) experiences, I’d gladly answer this all-too-common question with “but there is, and it’s called SCons“.

Now don’t get me wrong, SCons is still a world better than others I’ve been using — make, imake/xmkmf, autotools, every custom build system used at every company I’ve worked at, including some I myself helped improve. But it still has a couple of glaring misfeatures…

  • Around when SCons 0.96 was the latest and greatest, I tried building Mac OS X Frameworks with it. And that sounds fairly simple at first, given that all a Framework is from a UNIXy perspective, is a predefined directory structure and one or two structured files. Stuff one can easily generate, right?

    Right… but with a major caveat: SCons dependency tracking gets in the way. This is really painful given that it’s dependency tracking where SCons usually shines compared to other build systems.

  • The autoconf/configure-like abilities added to SCons a while ago during a summer of code are woefully inadequate for any but the simplest tasks.
  • The platform abstraction SCons offers isn’t so much. Now admittedly, it’s a bit childish to expect complete abstraction from platform-specific build differences, but things could be improved vastly with (theoretically) very little effort.
  • Functionality for some very, very common tasks is missing.

Let’s dig into some detail here.

Missing Functionality

If you’ve ever had to deal with building anything larger than a small command line program, and especially when you’ve built something with external dependencies, your Makefiles (or whatever) will likely have either contained or invoked some form of shell script.

Now SCons is actually a bit better in that it allows you to use Python to perform the same tasks, how to solve any of these slightly more complex problems isn’t necessarily a question of how powerful the scripting language is that you’re using. More often than not, it’s a question of how well the scripting language integrates with the build system… especially when your script generates build artefacts that other targets depend on.

Whatever your build system, your custom scripts should really generate results that can be picked up by the build system as equivalent to built-in artefact types — a script that writes a file would easily fulfil that requirement, as most build systems simply track the existence and/or last modification date of files to figure out whether a dependency of a target has changed.

But things become slightly more difficult when your script’s output can’t be any single file. For example, what if your script creates a directory structure? Or unpacks an archive file with third-party sources?

Actually, integrating something that creates directories and can be used as a dependency into SCons is fairly easy, which makes it even more surprising that (at the time I needed that functionality, which was around version 0.96) it’s missing.

Unarchiving files is quite a bit harder, though, and the reason for that is the same as why it’s hard to create Mac OS X Frameworks with SCons…

  • Paul Mohr

    Thanks for that idea. I have already apt-getted it an I use ‘make’ usually and I have just learned the advantages of Python so this seems a real good tool. Make seems to be a bit antiquated and has some odd methods that require a familiarity that makes it difficult to deal with at times. I will still use make, but this seems to be a good tool to understand. From the surface of it it seems the right idea to have a tool that uses a standard language like Python.

    Paul Mohrs last blog post… The math is wrong

    • unwesen

      I think it’s the right idea, and I think SCons does a great job. It just should do a little bit more :)

  • Pingback: Moved to SCons builds | fhtagn!