autoconf: Automake

1 
1 2.1 Automake
1 ============
1 
1 The ubiquity of `make' means that a makefile is almost the only viable
1 way to distribute automatic build rules for software, but one quickly
1 runs into its numerous limitations.  Its lack of support for automatic
1 dependency tracking, recursive builds in subdirectories, reliable
1 timestamps (e.g., for network file systems), and so on, mean that
1 developers must painfully (and often incorrectly) reinvent the wheel
1 for each project.  Portability is non-trivial, thanks to the quirks of
1 `make' on many systems.  On top of all this is the manual labor
1 required to implement the many standard targets that users have come to
1 expect (`make install', `make distclean', `make uninstall', etc.).
1 Since you are, of course, using Autoconf, you also have to insert
1 repetitive code in your `Makefile.in' to recognize `@CC@', `@CFLAGS@',
1 and other substitutions provided by `configure'.  Into this mess steps
1 "Automake".  
1 
1    Automake allows you to specify your build needs in a `Makefile.am'
1 file with a vastly simpler and more powerful syntax than that of a plain
1 makefile, and then generates a portable `Makefile.in' for use with
1 Autoconf.  For example, the `Makefile.am' to build and install a simple
1 "Hello world" program might look like:
1 
1      bin_PROGRAMS = hello
1      hello_SOURCES = hello.c
1 
1 The resulting `Makefile.in' (~400 lines) automatically supports all the
1 standard targets, the substitutions provided by Autoconf, automatic
1 dependency tracking, `VPATH' building, and so on.  `make' builds the
1 `hello' program, and `make install' installs it in `/usr/local/bin' (or
1 whatever prefix was given to `configure', if not `/usr/local').
1 
1    The benefits of Automake increase for larger packages (especially
1 ones with subdirectories), but even for small programs the added
1 convenience and portability can be substantial.  And that's not all...
1