Installer automake avec Homebrew, apk, apt, dnf, MacPorts, Nix, pacman, zypper

Liens du projet

• Page d'accueil
• Dépôt
• Docs amont
• Page du gestionnaire de paquets

Commandes et alias

• aclocal
• aclocal-1.18
• automake
• automake-1.18

Historique du projet

Automake was written to reduce the burden of maintaining large, portable Makefile.in templates by hand. Its official manual history credits the early project to Tom Tromey and describes Automake as part of the GNU build system alongside Autoconf and Libtool.

The Automake manual frames the package around Makefile.am files, configure.ac, GNU Coding Standards conventions, and generated Makefile.in output. Over time it absorbed a large catalog of conventions for recursive builds, installed programs, libraries, tests, distribution tarballs, Texinfo, gettext, and portability checks.

Because Automake generates files consumed by configure and make, it became a maintainer-side tool in many projects: release tarballs often include generated Makefile.in files so end users do not need Automake, while developers building from VCS do.

Historique d'adoption

Automake's adoption is tied to the spread of Autotools as the default build machinery for GNU packages and many non-GNU Unix projects. The batch input lists Automake in Homebrew, Debian/Ubuntu, Fedora, Arch, Alpine, MacPorts, Nix, and openSUSE, reflecting how standard it is in development environments.

For package managers, Automake is both a direct package and a build dependency. Formulae and distro recipes often need specific automake/aclocal versions when regenerating build files, especially for projects that ship old Autotools metadata.

Modes d'utilisation

Maintainers write Makefile.am files and a configure.ac script, run aclocal and automake as part of the autoreconf/bootstrap flow, and ship or build from generated Makefile.in files. Users normally encounter automake indirectly through autoreconf, ./configure, and make.

The official curation correctly treats Makefile.am and configure.ac as the package's relevant configuration/build-input files; Automake has no credentials file.

Pourquoi les passionnés de paquets s'y intéressent

Automake is historically important because it standardized a huge amount of portable Unix build behavior into generated makefiles. Package nerds care because Autotools failures often reduce to Automake version expectations, missing m4 macros, stale generated files, or distribution tarball rules.

It is also a compatibility artifact: even projects migrating to Meson, CMake, or language-native build systems may carry old Automake releases in package histories and bootstrap scripts.

Chronologie

• 1990s: Automake emerges in the GNU build-system ecosystem to generate Makefile.in files from Makefile.am.
• 2000s: Automake becomes a normal dependency for maintainers building GNU and Unix projects from source control.
• 2020s: Automake remains packaged broadly as part of standard developer-tool stacks.

Related projects

• GNU Autoconf generates configure scripts that pair with Automake-generated Makefile.in files.
• GNU Libtool handles portable library-building concerns commonly used with Automake.
• autoreconf orchestrates regeneration of Autotools files and often invokes aclocal and automake.

Sources

• https://git.savannah.gnu.org/cgit/automake.git
• https://www.gnu.org/software/automake/
• https://www.gnu.org/software/automake/manual/automake.html
• source_facts.package-manager