Autoconf [7] changed this paradigm almost overnight. David MacKenzie started the Autoconf project in 1991, but a look at the AUTHORS file in the Savannah Autoconf project[8] repository will give you an idea of the number of people that had a hand in making the tool. Although configuration scripts were long and complex, users only needed to specify a few variables when executing them. Most of these variables were simply choices about components, features, and options, such as: Where can the build system find libraries and header files? Where do I want to install my finished products? Which optional components do I want to build into my products?
Instead of modifying and debugging hundreds of lines of supposedly portable shell script, developers can now write a short meta-script file using a concise, macro-based language, and Autoconf will generate a perfect configuration script that is more portable, more accurate, and more maintainable than a hand-coded one. In addition, Autoconf often catches semantic or logic errors that could otherwise take days to debug. Another benefit of Autoconf is that the shell code it generates is portable between most variations of the Bourne shell. Mistakes made in portability between shells are very common, and, unfortunately, are the most difficult kinds of mistakes to find, because no one developer has access to all Bourne-like shells.
Note
While scripting languages like Perl and Python are now more pervasive than the Bourne shell, this was not the case when the idea for Autoconf was first conceived.
Autoconf-generated configuration scripts provide a common set of options that are important to all portable software projects running on POSIX systems. These include options to modify standard locations (a concept I'll cover in more detail in Chapter 2), as well as project-specific options defined in the configure.ac file (which I'll discuss in Chapter 3).
The autoconf package provides several programs, including the following:
autoconf is a simple Bourne shell script. Its main task is to ensure that the current shell contains the functionality necessary to execute the M4 macro processor. (I'll discuss Autoconf 's use of M4 in detail in Chapter 3.) The remainder of the script parses command-line parameters and executes autom4te.
The autoreconf utility executes the configuration tools in the autoconf, automake, and libtool packages as required by each project. autoreconf minimizes the amount of regeneration required to address changes in timestamps, features, and project state. It was written as an attempt to consolidate existing maintainer-written, script-based utilities that ran all the required Autotools in the right order. You can think of autoreconf as a sort of smart Autotools bootstrap utility. If all you have is a configure.ac file, you can run autoreconf to execute all the tools you need, in the correct order, so that configure will be properly generated.
The autoheader utility generates a C/C++–compatible header file template from various constructs in configure.ac. This file is usually called config.h.in. When the end user executes configure, the configuration script generates config.h from config.h.in. As maintainer, you'll use autoheader to generate the template file that you will include in your distribution package. (We'll examine autoheader in greater detail in Chapter 3.)
The autoscan program generates a default configure.ac file for a new project; it can also examine an existing Autotools project for flaws and opportunities for enhancement. (We'll discuss autoscan in more detail in Chapter 3 and Chapter 8.) autoscan is very useful as a starting point for a project that uses a non-Autotools-based build system, but it may also be useful for suggesting features that might enhance an existing Autotools-based project.
The autoupdate utility is used to update configure.ac or the template (.in) files to match the syntax supported by the current version of the Autotools.
The ifnames program is a small and generally underused utility that accepts a list of source file names on the command line and displays a list of C-preprocessor definitions on the stdout device. This utility was designed to help maintainers determine what to put into the configure.ac and Makefile.am files to make them portable. If your project was written with some level of portability in mind, ifnames can help you determine where those attempts at portability are located in your source tree and give you the names of potential portability definitions.
The autom4te utility is an intelligent caching wrapper for M4 that is used by most of the other Autotools. The autom4te cache decreases the time successive tools spend accessing configure.ac constructs by as much as 30 percent.
I won't spend a lot of time on autom4te (pronounced automate) because it's primarily used internally by the Autotools. The only sign that it's working is the autom4te.cache directory that will appear in your top-level project directory after you run autoconf or autoreconf.
Of the tools listed above, autoconf and autoheader are the only ones project maintainers will use directly when generating a configure script, and autoreconf is the only one that the developer needs to directly execute. Figure 1-1 shows the interaction between input files and autoconf and autoheader that generates the corresponding product files.
Note
I will use the data flow diagram format shown in Figure 1-1 throughout this book. Dark boxes represent objects provided either by the user or by an Autotools package. Light boxes represent generated objects. Boxes with square corners are scripts, and boxes with rounded corners are data files. The meaning of most of the labels here should be obvious, but at least one deserves an explanation: The term ac-vars refers to Autoconf-specific replacement text. I'll explain the gradient shading of the aclocal.m4 box shortly.
The primary task of this suite of tools is to generate a configuration script that can be used to configure a project build directory. This script will not rely on the Autotools themselves; in fact, autoconf is designed to generate configuration scripts that will run on all Unix-like platforms and in most variations of the Bourne shell. This means that you can generate a configuration script using autoconf and then successfully execute that script on a machine that does not have the Autotools installed.
The autoconf and autoheader programs are executed either directly by the user or indirectly by autoreconf. They take their input from your project's configure.ac file and various Autoconf-flavored M4 macro definition files, using autom4te to maintain cache information. autoconf generates a configuration script called configure, a very portable Bourne shell script that enables your project to offer many useful configuration capabilities. autoheader generates the config.h.in template based on certain macro definitions in configure.ac.
[7] For more on Autoconf origins, see the GNU webpage on the topic at http://www.gnu.org/software/autoconf.