Linux.conf.au 2003 | Abstracts

Using autoconf, automake and friends.

Malcolm Tredinnick

Bio

Paper

Audio

A fairly common expectation amongst Open Source users is that they can just grab the latest tarball of package X, unpack it and then put on a blindfold and type ./configure && make && make install - and it usually Just Works(tm). However, the magic that goes on behind the scenes to make this process work remains a mystery, even to a lot of programmers. This tutorial will try to draw back the curtain a little bit and reveal the elves going about their business as they create autogen.sh, configure.in and Makefile.am files for your later enjoyment.

Using autoconf and automake provides benefits for both programmers and end-users: they help with programming for portability and detecting pre-requisites for the build phase (autoconf) and allow the developer to focus on the programming without needing to spend too much time putting together a build infrastructure (automake). At least, that is how it is meant to work in theory. In practice, a fair bit of time is spent fine tuning the various files because things never quite seem to work as you first expected. Furthermore, it seems that people will still just prefer to cut-and-paste from another similar project and poke about wildly until the thing more or less works, rather than solving their particular problem. This part of a project is seen as an arcane area that is hard to comprehend.

So we are going to fix that!

These programs are not difficult to use if you approach it with the right mindset and a clear system for how you are going to use them. They are the misunderstood workhorses of freely available software. Building automatic configuration and build support into your project is fairly simple. Helping with somebody else's problems is not too difficult and usually educational. Hanging out your shingle on mailing lists or IRC and saying "I will debug your build problems" is a satisfying thing to do.

This tutorial will cover three fairly large areas (without trying to bore people to death):

• Writing Makefile.am files to describe a project's build and distribution requirements.
• writing configure.in files to handle configure-time options and detect portability constraints.
• Isolating machine-specific code fragments (and using configure-time results to pick the right code).

No prior knowledge of autotools or m4 is assumed. No knowledge of specific programming languages is required -- many of the examples will talk about C programs, but we will discuss packaging, documentation, internationalisation issues and other programming languages.