File: autoconf.info,  Node: Automake,  Next: Gnulib,  Up: The GNU Build System

2.1 Automake
============

The ubiquity of ‘make’ means that a makefile is almost the only viable
way to distribute automatic build rules for software, but one quickly
runs into its numerous limitations.  Its lack of support for automatic
dependency tracking, recursive builds in subdirectories, reliable
timestamps (e.g., for network file systems), and so on, mean that
developers must painfully (and often incorrectly) reinvent the wheel for
each project.  Portability is non-trivial, thanks to the quirks of
‘make’ on many systems.  On top of all this is the manual labor required
to implement the many standard targets that users have come to expect
(‘make install’, ‘make distclean’, ‘make uninstall’, etc.).  Since you
are, of course, using Autoconf, you also have to insert repetitive code
in your ‘Makefile.in’ to recognize ‘@CC@’, ‘@CFLAGS@’, and other
substitutions provided by ‘configure’.  Into this mess steps “Automake”.

   Automake allows you to specify your build needs in a ‘Makefile.am’
file with a vastly simpler and more powerful syntax than that of a plain
makefile, and then generates a portable ‘Makefile.in’ for use with
Autoconf.  For example, the ‘Makefile.am’ to build and install a simple
"Hello world" program might look like:

     bin_PROGRAMS = hello
     hello_SOURCES = hello.c

The resulting ‘Makefile.in’ (~400 lines) automatically supports all the
standard targets, the substitutions provided by Autoconf, automatic
dependency tracking, ‘VPATH’ building, and so on.  ‘make’ builds the
‘hello’ program, and ‘make install’ installs it in ‘/usr/local/bin’ (or
whatever prefix was given to ‘configure’, if not ‘/usr/local’).

   The benefits of Automake increase for larger packages (especially
ones with subdirectories), but even for small programs the added
convenience and portability can be substantial.  And that's not all...