I just read a post on meTUX, a German site sponsoring articles on IT issues. I was referred to the site by an email message on the autoconf mailing list. I have nothing personal against the author of this message, nor do I disagree with him on all points, but his main point I do take issue with. He states that autotools, and autoconf specifically, is a collection of hacks. Let me tell you what I think about this by asking a question of my own: If autotools are so bad, why is there no competing product?
Autotools as a packages does two things for the open source developer. First, it provides a convenient mechanism for encapsulating all of the garbage you don’t want to have to do manually, such as creating distribution packages (commonly called tarballs), ensuring your packages contain appropriate open source copyright, installation, and changelog information, and that your packages build using the same procedure on all platforms (except one we won’t mention here). The default installation paths for your packages’ components are chosen based on the GNU coding standards document, as well as the two dozen standard targets supported by Automake.
The second thing that autotools does for you is provide a very portable mechanism for running your configure/make scenario on any POSIX compliant system you can think of. Often we consider only Unix systems such as FreeBSD, Solaris, or Linux. But autotools has been ported to many embedded POSIX compliant platforms, as well. This embedded world is foreign to many of us who just want to get an open source package up and running on our Linux boxes, but the people who work every day in this world are greatful for any tools that just work on their little-known platforms. The people who wrote Autotools understood this issue and tried to design it in such a way that it relies on as little existing infrastructure as possible, basically the M4 macro processor, and a bourn compatible shell. With these design constraints in mind, autotools has a pretty good chance (85%) of just working on a POSIX-compliant platform for which it was never tested or targeted – that (quite contrary to the above author’s comments) is actually an amazing engineering feat, when you consider it.
A common gripe with autotools is that it doesn’t work well with Windows. Not really much to complain about in reality however, as most folks like their IDE’s and such on this platform. I find it simple enough to maintain an MS VC project along side my autotools scripts, and most Windows folks are delighted to be able to double-click on the .sln file and press F7 to build.
My personal gripe with autotools is the stunning lack of good documentation for the high-level concepts of this set of tools. There’s plenty of doc that describes the internals of the product, but the only resource I’ve ever been able to find that does a good job of describing the rational behind autotools is a book commonly referred to as “The Goat Book” because it has one of O’Reilly’s famous animal covers. But, Hey! What am I complaining about? The autotools are open source projects. If I don’t like the existing doc, why don’t I just write some good doc myself?