Missing features in scons
I've been working with autotools for about 4 years now - the first 3 years I didn't know what I was doing, and just tried to hack my way through when there was a problem. This last year, I decided to really understand it. It's been painful, but worth the effort. The really sad part is that it didn't have to be that painful. If there were a really good tutorial on not just the mechanics of autotools, but on the underlying motivation for it, and if all of this documentation were gathered into a single place, it would have been almost painless. Here's the basis for understanding autotools, step by step:
1. Learn what the intent behind autotools is
2. Learn how the toolchain works - what generates what?
3. Learn the underlying language (m4).
Now you have a half a chance at understanding what it does. Quit trying to think you can hack your way through autotools input files without understanding what they are for and how they work.
Before you decide to look at other tools, please try to compare apples to apples. Don't sit there and tell me that scons is a great replacement for autotools. For the things that scons does, it's a wonderful replacement. But if you need the additional functionality provided by autotools, then you just can't do it well in scons. What are these things? Mostly they have to do with package building, maintenance, and distribution.
I'm a packager for SuSE, as well as an open source software project administrator (for multiple projects). Scons is great if I want to build, but it does nothing to help me package and distribute my software. I've been on the mailing lists for scons for some time now, and I've commented on this missing feature set. One of the originators of scons (Steven Knight) has responded to my comments, and the crux of his responses are this: You're right, we need to add these features - why don't you start such a project and add them?
If you want to create a project for inhouse use, then by all means, use scons. If, however, you want to create a project to be packaged for distribution in a GNU/Linux distribution, you'd better use autotools, or be prepared to emulate all of the functionality that autotools gives you with a custom makefile. But don't even dream that a packager for a major distro is going to pick up your project and add it to a distro unless you've done just this. You must have support for all of the following targets in your custom makefile:
all dist distcheck install check installcheck
And all of these targets have to build cleanly on most *nix platforms in order to be considered as a candidate for packaging with a distro such as SuSE, RedHat, Ubuntu, or Debian.
Even now, there is a recent (may 2006) news posting on the scons web site - quote:
"Google's Summer of Code will fund a project proposed by Philipp Scholl to add support for packaging and release dependencies to SCons. Stefan Seefeld will be mentoring Philipp's proposal for the next several months. Congratulations to Philipp, and thanks to Stefan for mentoring."
Summary: Let's not be premature in trying to replace autotools with other build management tools - they're not ready yet - and don't forget, this article was written in 2003 - it's now 2006, and we STILL don't have a proper replacement tool chain for autotools. Perhaps soon...