autoconf

Generate a configuration script from configure.ac (if present) or configure.in and save this script to configure

$ autoconf

$ autoconf [template-file]

$ autoconf [[-f|--force]] [[-o|--output]] [outfile] [template-file]

autoconf [OPTION]... [TEMPLATE-FILE]

--help
    Display a help message and exit.

--version
    Output version information and exit.

-f, --force
    Regenerate the configure script even if configure.ac is older. This forces a regeneration regardless of timestamps.

--verbose
    Print verbose messages showing input and output files and actions taken.

-W CATEGORY, --warnings=CATEGORY
    Report warnings falling into CATEGORY. Common categories include all, none, obsolete, syntax, unsupported.

TEMPLATE-FILE
    Specifies the input file to process. Defaults to configure.ac or configure.in.

autoconf is a powerful tool part of the GNU Build System (often called Autotools) that automates the process of creating portable configure scripts. Its primary purpose is to allow software developers to write code that can be compiled and installed on a wide variety of Unix-like operating systems without manual adjustments to the build system.

When you, as a user, download a software package and see instructions like ./configure && make && make install, the configure script was likely generated by autoconf. This script intelligently probes the user's system for specific features, such as available libraries, header files, compiler capabilities, system calls, and endianness. Based on these checks, it then customizes the build process by generating appropriate Makefiles and header files.

For developers, autoconf reads a template file, typically named configure.ac (or historically configure.in), which contains a series of m4 macros. These macros represent various system checks and configuration logic. autoconf processes this file, expanding the macros and producing the final configure shell script. This significantly simplifies cross-platform development, allowing developers to focus on writing code rather than managing complex platform-specific build configurations.

The Autotools suite, including autoconf, has a steep learning curve for developers due to its reliance on m4 macros and a specific workflow.
The generated configure scripts can be quite large and complex, which can sometimes make them slow to run for end-users and difficult to debug for developers.
autoconf (and Autotools) are primarily designed for Unix-like environments. While efforts have been made for Windows compatibility (e.g., MinGW/MSYS2), they are less native compared to other build systems.
Debugging issues within the configure script can be challenging due to the layers of macro expansion.

For developers, the typical workflow involves writing configure.ac and Makefile.am files. Then, they run autoreconf -i (or individual commands like aclocal, autoconf, autoheader, automake) to generate the necessary build infrastructure.

For users, the process is much simpler: they typically download the source tarball (which includes the pre-generated configure script and Makefile.ins), then run ./configure, followed by make, and finally make install.

This is the input file for autoconf. It consists of m4 macros that describe the desired system features, checks for programs, libraries, header files, and compiler characteristics. Key macros include AC_INIT (initializes the package), AM_INIT_AUTOMAKE (for Automake integration), AC_PROG_CC (checks for a C compiler), AC_CHECK_LIB (checks for a library), and AC_OUTPUT (specifies output files like Makefile).

autoconf was originally written by David MacKenzie in 1991 and became part of the GNU project. It emerged as a crucial tool for solving the pervasive problem of software portability across diverse Unix variants. Before autoconf, developers often had to include multiple platform-specific Makefiles or complex preprocessor directives, leading to significant maintenance overhead.

Its development was driven by the Free Software Foundation's need for a standardized and robust build system for GNU software. Over the years, it has been continually developed and refined, becoming the cornerstone of the GNU Build System, widely adopted by a vast number of open-source projects for its effectiveness in abstracting away underlying system differences. The transition from configure.in to configure.ac as the preferred input file name reflected a slight evolution in naming conventions, but the core functionality remained the same.

automake(1), aclocal(1), autoheader(1), autoreconf(1), m4(1)