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
be fixed.

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.