The Fugue

I’ve been known to knock autotools (autoconf and automake and friends), but let it not be forgotten that I have also been known to say that alternative pickings are pretty slim.

Part of the problem with autotools is that it’s easy to make an unmaintainable and unusable mess, and one that is essentially opaque to the uninitiated.

But, on the other hand, it’s equally easy to use autotools in a sane way which is just as easy or easier than writing makefiles and whatnot by hand. Once you get over the initial learning curve. That has been a big caveat. I’ve climbed that curve a few times and it goes in one ear and out the other.

Well, a friend pointed out an excellent tutorial on autotools which demystifies autotools. It also makes a good reference for next week when you’ve forgotten everything.

If you’re writing code to distribute, you should consider using autotools (and doing so sanely), and this is a good starting point. But that’s not the only reason to check it out. You may just be curious, or you may wish to learn how this works so you can contribute patches and bring sanity to your favorite project’s build system.

But whatever you do, never ever just copy someone else’s autotools configuration into yours and apply “shotgun debugging” to shoehorn it into your project. That is the wrong approach and the primary cause of so many broken autotools setups.

I hate autotools (autoconf, automake, and friends). I hate them with a passion! Unfortunately, the only thing worse than a project using autotools is a project not using autotools.

As a user, I love the simplicity that autotools promises, and sometimes delivers:

./configure
make
sudo make install

When it works, it’s a beautiful thing. When it doesn’t, it’s deep voodoo to fix. This is doubly true when you’re not using Linux.

As a developer… well let’s face it. Very few developers know the first thing about using autotools. Of those that do, almost none know more than the very basics necessary to copy, paste, and hack someone else’s autotools setup to mostly-successfully build their project. Developers who write elegant DRY code and would never even consider the cut, paste, and hack approach to software development, will lose all resolve when faced with learning autotools.

The result is sloppy, bloated, unintelligible configure.{ac,in} and Makefile.am files. ./configure scripts that take longer performing pointless and repetitive tests, than it takes to build the project. Even on big projects, most configure scripts are many orders of magnitude slower than they need to be, because they check everything under the sun—decades of copy, paste, and hack cruft. I recently went through a decent tutorial on autotools and made me a simple autotools setup from scratch for a simple toy project. ./configure took all of 3 seconds to run.

Clearly we need something like autotools. We need something to do the following mundane tasks automatically:

• Figure out if the dependencies are installed and what compiler flags we need to access them.
• Figure out the compilation, installation, etc. commands and flags.
• Construct a nice Makefile with the expected targets (install, clean, etc.)
• Allow the user to easily override and give hints.

So what is so hard about this? I can see why autotools turned out the way it did; it was written in shell and m4, in the dark ages, without the benefit of 20/20 hindsight, and has accumulated decades of cruft. The truly amazing thing is that autotools has done so well and is so popular—that’s a testament to something fundamentally right about autotools. So fundamentally right that in spite of all its warts it continues to be the premier build system.

There are contenders to replace it. Scons and CMake seem to be the leaders in this arena. I’ve used Scons on a large project (Ardour) and I wasn’t impressed. You have to be fluent in Python to use it effectively, you have to approach your build system as a full-blown programming problem in a general purpose language (Python). It’s quite slow, and you need Python installed to use it. It is very flexible, though.

CMake seems promising, but I was dismayed to see that its syntax is not much better than autotools, and the documentation is skimpy (unless you buy that book that’s out of print until the next edition). Still, it’s better documented than autotools, and the user experience is quite nice.

Will CMake rise to supremacy? With time, it may. I think there’s room to undercut CMake though. I think one could design a tool that is flexible yet easy to use, fills the autotools niche solidly, and isn’t all that complicated to boot. What do you think?