I'm not at all surprised by the defenses of auto* in response to my rather harsh criticism.
Dom Lachowicz writes: I've yet to see a build system that attempted to fill auto*'s niche and fill it as well as auto* currently does. I agree completely, and perhaps my praise was simply too faint. The goal of making software building Just Work on a wide variety of Unix-like systems is extremely noble, and until auto*, it wasn't even obvious that it could be done.
I'd like to amplify even more. A lot of good free software is inspired by the existence of good proprietary software, in the sense that Gimp was inspired by Photoshop. If nothing else, the proprietary software represents an existence proof that it is possible to attain those goals.
I think this story applies somewhat to version control systems. We've had consensus for a very long time that CVS needed improvement and probably replacement, but it wasn't really until BitKeeper came along that the lightweight distributed version control systems (such as arch, darcs, and mercurial) started coming out of the woodwork.
Now, in the proprietary platform space, build systems are very slick, but none of them give a rat's ass about portability to other platforms. To the contrary, the nicer an IDE is to work in, the less likely the developer is to escape the golden handcuffs. Lock-in is the highest goal. If we're going to create a much better build system, we have to look to ourselves for the inspiration, because we're not going to find it anywhere else. auto* was the first great existence proof, and I think it is high time for others.
Andy Tai and others call for incremental improvement to auto*, including a gradual phase-out of M4, but, with David Turner, I'm not sure that's really feasible. I believe a program of incremental improvement to auto* will never really be able to reduce the overall system complexity. And I do believe that a much simpler system is possible, especially without the demands of adhering to M4, least-common-denominator make, and least-common-denominator shell.
I admit I did overstate some of my original points for the sake of rhetoric. There are, indeed, good reasons to use other compilers than the GNU toolchain. Ralph Giles takes me to task for not acknowledging the importance of Solaris, but for the applications I'm personally most interested in building (font editors and the like), these vendor Unices are vastly less important than native Win32 support.
Dom writes: Regarding auto*'s tendency to work around deficiencies in ld/cc/nm/etc..., all I can counter with is "we don't control the horizontal and the vertical". In response, I ask: Who does? Bill Gates? Maybe after he figures it out we can try to clone it?
I'm not calling for violent overthrow of the auto* hegemony. I am calling for:
- A profusion of prototypes of new autoconfiguring build systems,
much like the distributed version control systems we've seen come out
in the last couple years or so.
- A careful look at which aspects of make/ld/package managers/etc
are holding us back, and clear goals enunciated about how they might
- A more quantitative approach to thinking about building, perhaps
empirically measured in challenges, where students are forced to use
the tools to build and package a trivial app for Linux, Mac, and
Windows platforms, and entries are scored based on time taken, defects
in the results, and so on.
I've had a strong enough long-term interest in this field that I am likely to make one such prototype myself. One reason I'm blogging about now is to gauge the waters, to figure out whether there are other people thinking along similar lines, or whether I'm pretty much just pissing into the wind as far as the broader free software community.