SCons Rant

Mac OS X Frameworks

SCons’ dependency tracking is outstanding. It generates a dependency graph of all build artefacts internally before building anything. Each target and source you specify occupies a node in this dependency graph, with a unique identifier, so simply mentioning the name of another target as one of your dependencies (sources, libraries, etc.) is all that’s required for SCons to figure out in what order to build stuff. Great stuff!

So why are Frameworks and unarchiving stuff so hard? The thing is, SCons has (or used to have, I haven’t tried since 0.96) this lobotomized assumption that any build step can only produce a single build artefact. When you’re unpacking an archive file, though, that’s quite obviously not the case — you usually have a single source, but multiple artefacts from the build step.

And while SCons does have a vague notion that this could be the case, it’s just not thought through to the end. As far as archives are concerned, you can sometimes be content with, say, assuming the root directory of all the files in the archive being the single artefact of an extraction build step, but that only works if your archives are created with such a root directory inside.

When it comes to Frameworks, though — or any other kind of directory structure — SCons’s assumption fails miserably. It’s not the root directory of a Framework that SCons needs to update if one of it’s sources are modified, it’s one or two files deep(ish) within the directory structure.

So until SCons undergoes a major change in this regard, it’ll be broken for any more complex uses than producing single libraries and/or binaries. If that’s all you need, though, it rocks!


When it was announced that SCons would get autoconf-like functionality during a Google Summer of Code, I was ecstatic. Finally SCons would be a full replacement for autotools, notwithstanding some odd Mac OS X-specific features that couldn’t really be supported. Who cares about those anyway, besides myself?

Irony aside, I really was happy. And very recently, I had a chance to try them out, and was sorely disappointed. SCons’ autoconfiguration features work, but are basic to the point of being useless to me.

People use autoconf for various different purposes, so it’s a bit hard to claim that it’s purpose is exactly one thing, and nothing else. But as far as I am concerned, it’s purpose is to detect the availability of certain features of the environment in which a software package is built. It then produces some sort of artefact that can be used to abort the build immediately if essential features are missing, or to build only selected parts of the sources.

And SCons provides that, to an extent. It can detect the availability of types, headers, libraries, just as you would expect.

But autoconf just adds so much more. For one thing, you can easily extend configure’s parameters with switches to enable/disable the use of certain features, or specify where a dependency might be found if it’s not installed in default locations. Not so with SCons.

Oh, don’t get me wrong, you can hack up something along the lines. I’ve done so for cartograph, and while it’s not pretty, it works fairly well for what it is. But this, to me, is such an essential part of finding libraries, that the fact it’s missing from SCons simply boggles my mind.

  • 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!