autoreconf

autoreconf [OPTION]... [DIRECTORY]...

-f, --force
    Recreate all files, even if they are newer than their inputs. This option implies --install.

-i, --install
    Copy auxiliary files (e.g., config.guess, install-sh) into the source tree if they are missing or older. This also implies --force.

-s, --sync
    Synchronize auxiliary files, updating them if they are older or differ from the system-wide versions.

-v, --verbose
    Print verbose messages about the operations being performed.

-W CATEGORY, --warnings=CATEGORY
    Enable warnings classified by CATEGORY. Common categories include 'all', 'none', 'gnu', 'obsolete'.

-I DIR, --include=DIR
    Add DIR to the aclocal search path for .m4 macros.

-m, --make
    If automake is part of the build system, explicitly run it. This is usually handled implicitly by --install.

--system
    Use the system-wide versions of auxiliary files without copying them into the source tree.

--no-warn-each-tool
    Suppress warnings about each Autotools tool being run.

autoreconf is a shell script that automatically regenerates the GNU Build System (Autotools) configuration files for a software package. It typically runs autoconf, autoheader, automake, aclocal, libtoolize, and autopoint in the correct order, ensuring that all necessary generated files are up-to-date.

Developers use autoreconf to prepare a source tarball for distribution or when working with a source tree obtained directly from a version control system (like Git or SVN) where the configure script and Makefile.in templates are not pre-generated. By running autoreconf in the top-level directory of a project, it ensures that configure.ac and Makefile.am files are properly processed to produce the configure script, Makefile.in files, config.h.in, and other build system artifacts.

This command streamlines the process of bootstrapping an Autotools-based project, making it easier for users to compile the software by simply running ./configure && make && make install. It eliminates the need to manually invoke each Autotools component separately, reducing potential errors and simplifying the build setup.

• autoreconf requires that the various Autotools components (like autoconf, automake, libtool, aclocal, autoheader) are installed and accessible in your system's PATH.
• It should generally be run from the top-level directory of the project's source tree.
• While autoreconf generates the configure script, it does not execute it. You still need to run ./configure manually to configure the build.
• Sometimes, issues can arise due to version mismatches between different Autotools components, or if the configure.ac or Makefile.am files have specific requirements.

autoreconf is primarily used in two scenarios: First, by project developers when they modify the configure.ac (Autoconf input) or Makefile.am (Automake input) files, or when adding new Autotools components to a project. Second, by users or developers who obtain a project's source code directly from a version control system (e.g., via git clone). In such cases, the configure script and Makefile.in files are typically not committed, requiring autoreconf to generate them before the project can be configured and built.

The typical workflow for building an Autotools-based project involves three main steps:

1. Bootstrapping: Running autoreconf -i (or similar) to generate the configure script and Makefile.in files from their source templates.
2. Configuration: Executing the generated ./configure script to adapt the build to the specific system environment, creating Makefiles from Makefile.in and config.h from config.h.in.
3. Building & Installation: Running make to compile the source code and make install to install the compiled binaries and other files onto the system.

autoreconf plays the crucial first role in this chain.

autoreconf is an integral part of the GNU Autotools suite, which originated in the early 1990s to standardize and simplify the build process for complex Unix-like software, making it portable across different systems. autoreconf was developed to automate the often intricate and error-prone sequence of invoking individual Autotools commands (aclocal, autoconf, autoheader, automake, libtoolize). Before autoreconf, developers had to manually run these commands in the correct order.

Its introduction significantly streamlined the bootstrapping of Autotools-based projects, especially when obtaining source code directly from version control repositories, as it provides a single, convenient command to prepare the build system.

autoconf(1), automake(1), aclocal(1), libtoolize(1), autoheader(1), make(1), configure(8)