Introducing GNU Automake

The primary goal of Automake is to generate Makefile.ins compliant with the GNU Makefile Standards. Along the way, it tries to remove boilerplate and drudgery. It also helps the Makefile writer by implementing features (for instance automatic dependency tracking and parallel make support) that most maintainers don't have the patience to implement by hand. It also implements some best practices as well as workarounds for vendor make bugs - both of which require arcane knowledge not generally available.

A secondary goal for Automake is that it work well with other free software, and, specifically, GNU tools. For example, Automake has support for Dejagnu-based test suites.

Chances are that you don't care about the GNU Coding Standards. That's okay. You'll still appreciate the convenience that Automake provides, and you'll find that the GNU standards compliance feature, for the most part, assists rather than impedes.

Automake helps the maintainer with five large tasks, and countless minor ones. The basic functional areas are:

  1. Build

  2. Check

  3. Clean

  4. Install and uninstall

  5. Distribution

We cover the first three items in this chapter, and the others in later chapters. Before we get into the details, let's talk a bit about some general principles of Automake.

General Automake principles

Automake at its simplest turns a file called Makefile.am into a GNU-compliant Makefile.in for use with configure. Each Makefile.am is written according to make syntax; Automake recognizes special macro and target names and generates code based on these.

There are a few Automake rules which differ slightly from make rules:

All macros and targets, including those which Automake does not recognize, are passed through to the generated Makefile.in - this is a powerful extension mechanism. Sometimes Automake will define macros or targets internally. If these are also defined in Makefile.am then the definition in Makefile.am takes precedence. This feature provides an easy way to tailor specific parts of the output in small ways.

Note, however, that it is a mistake to override parts of the generated code that aren't documented (and thus `exported' by Automake). Overrides like this stand a good chance of not working with future Automake releases.

Automake also scans configure.in. Sometimes it uses the information it discovers to generate extra code, and sometimes to provide extra error checking. Automake also turns every AC_SUBST into a Makefile variable. This is convenient in more ways than one: not only does it mean that you can refer to these macros in Makefile.am without extra work, but, since Automake scans configure.in before it reads any Makefile.am, it also means that special variables and overrides Automake recognizes can be defined once in configure.in.