||This article's lead section may not adequately summarize key points of its contents. (March 2013)|
|Initial release||May 28, 1996|
|Stable release||1.14.1 / December 24, 2013|
|License||GNU General Public License|
It automatically generates one or more Makefile.in from files called Makefile.am. Each Makefile.am contains, among other things, useful variable definitions for the compiled software, such as compiler and linker flags, dependencies and their versions, etc. The generated Makefile.ins are portable and compliant with the Makefile conventions in the GNU Coding Standards, and may be used by configure scripts to generate a working Makefile.
Automake aims to allow the programmer to write a makefile in a higher-level language, rather than having to write the whole makefile manually. In simple cases, it suffices to give:
- A line that declares the name of the program to build;
- A list of source files;
- A list of command-line options to be passed to the compiler (for example, in which directories header files will be found);
- A list of command-line options to be passed to the linker (which libraries the program needs and in what directories they are to be found).
From this information, Automake generates a makefile that allows the user to:
- Compile the program;
- Clean (i.e., remove the files resulting from the compilation);
- Install the program in standard directories;
- Uninstall the program from where it was installed;
- Create a source distribution archive (commonly called a tarball);
- Test that this archive is self-sufficient, and in particular that the program can be compiled in a directory other than the one where the sources are deployed.
The makefiles produced follow the GNU Coding Standards.
Automake also takes care of automatically generating the dependency information, so that when a source file is modified, the next invocation of the make command will know which source files need to be recompiled. If the compiler allows it, Automake tries to make the dependency system dynamic: whenever a source file is compiled, that file's dependencies are updated by asking the compiler to regenerate the file's dependency list. In other words, dependency tracking is a side effect of the compilation process.
This attempts to avoid the problem with some static dependency systems, where the dependencies are detected only once when the programmer starts working on the project. In such a case, if a source file gains a new dependency (e.g., if the programmer adds a new #include directive in a C source file), then a discrepancy is introduced between the real dependencies and those that are used by the compilation system. The programmer should then regenerate the dependencies, but runs the risk of forgetting to do so.
In the general case, automake generates dependencies via the bundled depcomp script, which will invoke the compiler appropriately or fall back to makedepend. If the compiler is a sufficiently recent version of gcc, however, automake will inline the dependency generation code to call gcc directly.
Automake can also help with the compilation of libraries by automatically generating makefiles that will invoke GNU Libtool. The programmer is thus exempted from having to know how to call Libtool directly, and the project benefits from the use of a portable library creation tool.
aclocal, however, is a general-purpose program that can be useful to autoconf users. The GNU Compiler Collection, for example, uses aclocal even though its makefile is hand written.
Like Autoconf, Automake is not entirely backwards compatible. For example, a project created with automake 1.13 will not necessarily work with automake 1.14. This can require complex projects to include multiple versions.
Notable applications that use Automake
- Lattarini, Stefano (2013-12-24). "GNU Automake 1.14.1 released" (Mailing list). info-gnu.
- Automake - GNU Project Documentation
- Automatic Dependency Tracking, Automake Manual
- Dependency Tracking in Automake, Automake Manual
- Automake "broken"?
- GTK+ libraries
- XCircuit website
- XCircuit documentation
- Uwe Ohse (2000). "Why autoconf, automake and libtool fail".
- Gary V. Vaughan, Ben Elliston, Tom Tromey: Gnu Autoconf, Automake, and Libtool, Sams, ISBN 1-57870-190-2
- Official website
- Online version of The Goat Book aka Autobook
- Combined manual for Automake and Autoconf
- Autotoolset home page
- Article "Using Automake and Autoconf with C++" by Murray Cumming
- Autotools Mythbuster
- A Brief History of Automake (through 2007).
- Autotools Tutorial by Alexandre Duret-Lutz introduces Autoconf, Automake, Libtool, and Gettext.
- Learning the GNU Development tools