SCons Rant

Platform Abstraction

Along the same lines, SCons does only a half-hearted job at abstracting out aspects of the platform you’re building your sources on. Now as I wrote earlier, this part of the rant is a little childish, in that it’s really hard to abstract out some things.

For example, let’s go back to the Frameworks thing above. It’s perfectly possible — likely even — for your software to depend on a library that comes packaged as a Framework on Mac OS X. OpenSceneGraph would be one such example.

And as such it’d be useful to, say, prefer the Framework over UNIXish libraries when you’re building your project on OS X (or not, depending on your preferences). You can extend what I’ve done for cartograph above to do just that (and I have, it’s just not published yet), but that solves only half of the problem. Because when you’re defining your build target itself, you still have to deliver the Frameworks to link against via the FRAMEWORKS parameter, rather than the more conventional LIBS.

So in your SConstruct, you can of course check for the PLATFORM environment variable, and append stuff to LIBS rather than FRAMEWORKS… but that’s not terribly pretty.

Now I’m not even saying that SCons should do that automatically. It would be sweet if it could, but what if the library’s naming conventions are slightly different from the Framework’s? Nothing would be solved.

But at the very least, if you use FRAMEWORKS on any platform other than Mac OS X, print a big fat warning that the variable will be ignored. Support platform-independent builds, rather than just making them kind of possible, somehow.

Final Thoughts

So after all this ranting, why am I not doing anything to rectify the situation? It’s fairly obvious that I’ve put some time into thinking about and analyzing the shortcomings SCons has.

Well, there are two reasons. For one, while I’m technically the kind of guy that actually finds improving build systems a fairly sexy sort of problem to solve, the problems I see crop up at the most unfortunate of times… namely when I’m very busy building code that’s not a build system, and I just want the damn thing to work.

Secondly, I’ve delved fairly deeply into SCons code, and I’ve got to say, I’m confused. It’s not that coding style is bad, or documentation is missing that makes hacking on SCons hard… it’s that it’s a humungous amount of code considering it does so little. And most of it appears to revolve around manipulating nodes in the dependency graph, which fails at the idea that a build step may produce multiple artefacts…

The upshot is that it’d be (almost) easier for me to write a replacement for SCons, rather than changing the things that IMO need changing. And that’s not the sort of thing I want to spend my time on right now.

Now I’m not trying to scare you away from SCons with this rant of mine, quite the contrary. As is often the case with me, I’m pointing out the things that bother me, and completely skip over all the excellent bits. So if you’ve got any build problem but the ones I’ve touched on above, in all likelihood SCons would be an excellent choice to help solve them.

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