Autotools

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?

Advertisements

2 comments on “Autotools

  1. John Pye says:

    Interested to hear your views on SCons, if you’ve tried it. SCons has autoconf-style functionality implemented, and is very promising. Also includes automake-style dependency checking. Everything is defined in a single ‘SConstruct’ file (no need for Makefile.am, configure.ac, config.guess, etc).

    I’d say that most new linux users now don’t come across M4 until they learn autoconf/automake. On the other hand many of these users will already have experienced python, so this makes the learning curve for SCons shorter as well. It seems like a more natural syntax, less confusing brackets and uppercase smash-ups.

  2. jcalcote says:

    I’ve looked at SCons. It’s a nifty package. I really like its nice concise definition of a build process. Because it’s built on Python, the look and feel of (in fact, the reality of) its extensions are object-oriented in nature, which make the definitions of these extensions very concise (some folks might say too concise, but you can’t have everything).

    SCons works very well, and with it’s autoconf extensions, you get some of the main features of autotools. Dependency management is one of the main strengths of SCons, with its multi-language pre-processor and digest-based change detection system, it beats make hands down.

    The problem is again related to what autotools does that no other build system does: standardized build targets that everyone has come to expect in an autotools project, and the ability to automate package management. There is no other solution for this stuff short of rolling your own within an SCons build script, or hand-rolled makefile – and the idea is to NOT have to do this.

    I agree John that most people not only don’t know M4, many have never heard of it before and don’t know it exists in any form on their preconfigured Unix/Linux machines. This is a documentation issue, and needs to be dealt with.

    I exchanged emails with Steven Knight a few weeks ago, where he commented on a response to an SCons mailing list entry that I posted. The original comment was related to how much better scons was than autotools. My response was that scons didn’t do what autotools does – it’s a replacement for make, not autotools. Steven’
    s response was that I was perfectly accurate, and that an open source project providing the required SCons extensions would be a wonderful thing. I agree whole heartedly, I’m not stuck on autotools. I really wish there was some competition so that a better choice would either fall out of it, or autotools and its documentation would be improved to make it more user-friendly.

    Again, the most significant problem with autotools is its learning curve. But then SCons has quite a steep learning curve also – if you want to make it do what autotools does for projects.

Comments are closed.