This is Info file autoconf.info, produced by Makeinfo-1.54 from the input file ./autoconf.texi. START-INFO-DIR-ENTRY * Autoconf: (autoconf). Create source code configuration scripts. END-INFO-DIR-ENTRY This file documents the GNU Autoconf package for creating scripts to configure source code packages using templates and an `m4' macro package. Copyright (C) 1992, 1993, 1994 Free Software Foundation, Inc. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Foundation.  File: autoconf.info, Node: Site Defaults, Prev: Transforming Names, Up: Site Configuration Setting Site Defaults ===================== Autoconf-generated `configure' scripts allow your site to provide default values for some configuration values. You do this by creating site- and system-wide initialization files. If the environment variable `CONFIG_SITE' is set, `configure' uses its value as the name of a shell script to read. Otherwise, it reads the shell script `PREFIX/lib/config.site' if it exists, then `EXEC_PREFIX/lib/config.site' if it exists. Thus, settings in system-dependent files override those in system-independent ones in case of conflict. Site files can be arbitrary shell scripts, but only certain kinds of code are really appropriate to be in them. Because `configure' reads any cache file after it has read any site files, a site file can define a default cache file to be shared between all Autoconf-generated `configure' scripts run on that system. If you set a default cache file in a site file, it is a good idea to also set the output variable `CC' in that site file, because the cache file is only valid for a particular compiler, but many systems have several available. Site files are also good places to set default values for other output variables, such as `CFLAGS', if you need to give them non-default values: anything you would normally do, repetitively, on the command line. If you use non-default values for PREFIX or EXEC_PREFIX (wherever you locate the site file), you can set them in the site file if you specify it with the `CONFIG_SITE' environment variable. You can set some cache values in the site file itself. Doing this is useful if you are cross-compiling, so it is impossible to check features that require running a test program. You could "prime the cache" by setting those values correctly for that system in `EXEC_PREFIX/lib/config.site'. To find out the names of the cache variables you need to set, look for shell variables with `_cv_' in their names in the affected configure scripts, or in the Autoconf `m4' source code for those macros. The cache file is careful to not override any variables set in the site files. Similarly, you should not override command-line options in the site files. Your code should check that variables such as `prefix' and `cache_file' have their default values (as set near the top of `configure') before changing them. Here is a sample file `/usr/share/local/gnu/lib/config.site'. The command `configure --prefix=/usr/share/local/gnu' would read this file (if `CONFIG_SITE' is not set). # config.site for configure # # Give Autoconf 2.x generated configure scripts a shared default # cache file for feature test results, architecture-specific. if test $cache_file = ./config.cache; then cache_file=/usr/local/gnu/lib/config.cache # A cache file is only valid for one C compiler. CC=gcc fi # Default --prefix and --exec-prefix. test $prefix = NONE && prefix=/usr/share/local/gnu test $exec_prefix = NONE && exec_prefix=/usr/local/gnu  File: autoconf.info, Node: Invoking configure, Next: Invoking config.status, Prev: Site Configuration, Up: Top Running `configure' Scripts *************************** Below are instructions on how to configure a package that uses a `configure' script, suitable for inclusion as an `INSTALL' file in the package. * Menu: * Basic Installation:: Instructions for typical cases. * Compilers and Options:: Selecting compilers and optimization. * Build Directory:: Configuring in a different directory. * Installation Names:: Installing in different directories. * System Type:: Specifying the system type. * Optional Features:: Selecting optional features.  File: autoconf.info, Node: Basic Installation, Next: Compilers and Options, Up: Invoking configure Basic Installation ================== These are generic installation instructions. The `configure' shell script attempts to guess correct values for various system-dependent variables used during compilation. It uses those values to create a `Makefile' in each directory of the package. It may also create one or more `.h' files containing system-dependent definitions. Finally, it creates a shell script `config.status' that you can run in the future to recreate the current configuration, a file `config.cache' that saves the results of its tests to speed up reconfiguring, and a file `config.log' containing compiler output (useful mainly for debugging `configure'). If you need to do unusual things to compile the package, please try to figure out how `configure' could check whether to do them, and mail diffs or instructions to the address given in the `README' so they can be considered for the next release. If at some point `config.cache' contains results you don't want to keep, you may remove or edit it. The file `configure.in' is used to create `configure' by a program called `autoconf'. You only need `configure.in' if you want to change it or regenerate `configure' using a newer version of `autoconf'. The simplest way to compile this package is: 1. `cd' to the directory containing the package's source code and type `./configure' to configure the package for your system. If you're using `csh' on an old version of System V, you might need to type `sh ./configure' instead to prevent `csh' from trying to execute `configure' itself. Running `configure' takes awhile. While running, it prints some messages telling which features it is checking for. 2. Type `make' to compile the package. 3. Optionally, type `make check' to run any self-tests that come with the package. 4. Type `make install' to install the programs and any data files and documentation. 5. You can remove the program binaries and object files from the source directory by typing `make clean'. To also remove the files that `configure' created (so you can compile the package for a different kind of computer), type `make distclean'.  File: autoconf.info, Node: Compilers and Options, Next: Build Directory, Prev: Basic Installation, Up: Invoking configure Compilers and Options ===================== Some systems require unusual options for compilation or linking that the `configure' script does not know about. You can give `configure' initial values for variables by setting them in the environment. Using a Bourne-compatible shell, you can do that on the command line like this: CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure Or on systems that have the `env' program, you can do it like this: env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure  File: autoconf.info, Node: Build Directory, Next: Installation Names, Prev: Compilers and Options, Up: Invoking configure Using a Different Build Directory ================================= You can compile the package in a different directory from the one containing the source code. Doing so allows you to compile it on more than one kind of computer at the same time. To do this, you must use a version of `make' that supports the `VPATH' variable, such as GNU `make'. `cd' to the directory where you want the object files and executables to go and run the `configure' script. `configure' automatically checks for the source code in the directory that `configure' is in and in `..'.  File: autoconf.info, Node: Installation Names, Next: System Type, Prev: Build Directory, Up: Invoking configure Installation Names ================== By default, `make install' will install the package's files in `/usr/local/bin', `/usr/local/man', etc. You can specify an installation prefix other than `/usr/local' by giving `configure' the option `--prefix=PATH'. Alternately, you can do so by consistently giving a value for the `prefix' variable when you run `make', e.g., make prefix=/usr/gnu make prefix=/usr/gnu install You can specify separate installation prefixes for architecture-specific files and architecture-independent files. If you give `configure' the option `--exec-prefix=PATH' or set the `make' variable `exec_prefix' to PATH, the package will use PATH as the prefix for installing programs and libraries. Documentation and other data files will still use the regular prefix. If you use an unusual directory layout in which some of the installation directory names are not based on a single prefix, you can set the individual variables `bindir', `libdir', etc. on the `make' command line: make bindir=/bin libdir=/usr/lib Check the `Makefile.in' files to see which variables each package uses. If the package supports it, you can cause programs to be installed with an extra prefix or suffix on their names by giving `configure' the option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.  File: autoconf.info, Node: System Type, Next: Optional Features, Prev: Installation Names, Up: Invoking configure Specifying the System Type ========================== There may be some features `configure' can not figure out automatically, but needs to determine by the type of host the package will run on. Usually `configure' can figure that out, but if it prints a message saying it can not guess the host type, give it the `--host=TYPE' option. TYPE can either be a short name for the system type, such as `sun4', or a canonical name with three fields: CPU-COMPANY-SYSTEM See the file `config.sub' for the possible values of each field. If `config.sub' isn't included in this package, then this package doesn't need to know the host type. If you are building compiler tools for cross-compiling, you can also use the `--target=TYPE' option to select the type of system they will produce code for and the `--build=TYPE' option to select the type of system on which you are compiling the package.  File: autoconf.info, Node: Optional Features, Prev: System Type, Up: Invoking configure Optional Features ================= Some packages pay attention to `--with-PACKAGE' options to `configure', where PACKAGE is something like `gnu-as' or `x' (for the X Window System). They may also pay attention to `--enable-FEATURE' options, where FEATURE indicates an optional part of the package. The `README' should mention any `--with-' and `--enable-' options that the package recognizes. `configure' also recognizes the following options: `--cache-file=FILE' Save the results of the tests in FILE instead of `config.cache'. Set FILE to `/dev/null' to disable caching, for debugging `configure'. `--help' Print a summary of the options to `configure', and exit. `--quiet' `--silent' `-q' Do not print messages saying which checks are being made. `--srcdir=DIR' Look for the package's source code in directory DIR. Usually `configure' can determine that directory automatically. `--version' Print the version of Autoconf used to generate the `configure' script, and exit. `--x-includes=DIR' X include files are in directory DIR. `--x-libraries=DIR' X library files are in directory DIR. `configure' also accepts some other, not widely useful, options.  File: autoconf.info, Node: Invoking config.status, Next: Questions, Prev: Invoking configure, Up: Top Recreating a Configuration ************************** The `configure' script creates a file named `config.status' which describes which configuration options were specified when the package was last configured. This file is a shell script which, if run, will recreate the same configuration. You can give `config.status' the `--recheck' option to update itself. This option is useful if you change `configure', so that the results of some tests might be different from the previous run. The `--recheck' option re-runs `configure' with the same arguments you used before, plus the `--no-create' option, which prevent `configure' from running `config.status' and creating `Makefile' and other files, and the `--no-recursion' option, which prevents `configure' from running other `configure' scripts in subdirectories. (This is so other `Makefile' rules can run `config.status' when it changes; *note Automatic Remaking::., for an example). `config.status' also accepts the options `--help', which prints a summary of the options to `config.status', and `--version', which prints the version of Autoconf used to create the `configure' script that generated `config.status'. `config.status' checks several optional environment variables that can alter its behavior: - Variable: CONFIG_SHELL The shell with which to run `configure' for the `--recheck' option. It must be Bourne-compatible. The default is `/bin/sh'. - Variable: CONFIG_STATUS The file name to use for the shell script that records the configuration. The default is `./config.status'. This variable is useful when one package uses parts of another and the `configure' scripts shouldn't be merged because they are maintained separately. The following variables provide one way for separately distributed packages to share the values computed by `configure'. Doing so can be useful if some of the packages need a superset of the features that one of them, perhaps a common library, does. These variables allow a `config.status' file to create files other than the ones that its `configure.in' specifies, so it can be used for a different package. - Variable: CONFIG_FILES The files in which to perform `@VARIABLE@' substitutions. The default is the arguments given to `AC_OUTPUT' in `configure.in'. - Variable: CONFIG_HEADERS The files in which to substitute C `#define' statements. The default is the arguments given to `AC_CONFIG_HEADER'; if that macro was not called, `config.status' ignores this variable. These variables also allow you to write `Makefile' rules that regenerate only some of the files. For example, in the dependencies given above (*note Automatic Remaking::.), `config.status' is run twice when `configure.in' has changed. If that bothers you, you can make each run only regenerate the files for that rule: config.h: stamp-h stamp-h: config.h.in config.status CONFIG_FILES= CONFIG_HEADERS=config.h ./config.status echo > stamp-h Makefile: Makefile.in config.status CONFIG_FILES=Makefile CONFIG_HEADERS= ./config.status (If `configure.in' does not call `AC_CONFIG_HEADER', there is no need to set `CONFIG_HEADERS' in the `make' rules.)  File: autoconf.info, Node: Questions, Next: Upgrading, Prev: Invoking config.status, Up: Top Questions About Autoconf ************************ Several questions about Autoconf come up occasionally. Here some of them are addressed. * Menu: * Copyright:: Legal restrictions on Autoconf output. * Why GNU m4:: Why not use the standard `m4'? * Bootstrapping:: Autoconf and GNU `m4' require each other? * Why Not Imake:: Why GNU uses `configure' instead of Imake.  File: autoconf.info, Node: Copyright, Next: Why GNU m4, Up: Questions Copyright on `configure' Scripts ================================ What are the restrictions on distributing `configure' scripts that Autoconf generates? How does that affect my programs that use them? The configuration scripts that Autoconf produces are covered by the GNU General Public License. This is because they consist almost entirely of parts of Autoconf itself, rearranged somewhat, and Autoconf is distributed under the terms of the GPL. As applied to Autoconf, the GPL just means that you need to distribute `configure.in', and `acsite.m4', `aclocal.m4', `acconfig.h', and `CONFIG.h.top' and `CONFIG.h.bot' if you use them, along with `configure'. Programs that use Autoconf scripts to configure themselves do not automatically come under the GPL. Distributing an Autoconf configuration script as part of a program is considered to be *mere aggregation* of that work with the Autoconf script. Such programs are not derivative works based on Autoconf; only their configuration scripts are. We still encourage software authors to distribute their work under terms like those of the GPL, but doing so is not required to use Autoconf.  File: autoconf.info, Node: Why GNU m4, Next: Bootstrapping, Prev: Copyright, Up: Questions Why Require GNU `m4'? ===================== Why does Autoconf require GNU `m4'? Many `m4' implementations have hard-coded limitations on the size and number of macros, which Autoconf exceeds. They also lack several builtin macros that it would be difficult to get along without in a sophisticated application like Autoconf, including: builtin indir patsubst __file__ __line__ Since only software maintainers need to use Autoconf, and since GNU `m4' is simple to configure and install, it seems reasonable to require GNU `m4' to be installed also. Many maintainers of GNU and other free software already have most of the GNU utilities installed, since they prefer them.  File: autoconf.info, Node: Bootstrapping, Next: Why Not Imake, Prev: Why GNU m4, Up: Questions How Can I Bootstrap? ==================== If Autoconf requires GNU `m4' and GNU `m4' has an Autoconf `configure' script, how do I bootstrap? It seems like a chicken and egg problem! This is a misunderstanding. Although GNU `m4' does come with a `configure' script produced by Autoconf, Autoconf is not required in order to run the script and install GNU `m4'. Autoconf is only required if you want to change the `m4' `configure' script, which few people have to do (mainly its maintainer).  File: autoconf.info, Node: Why Not Imake, Prev: Bootstrapping, Up: Questions Why Not Imake? ============== Why not use Imake instead of `configure' scripts? Several people have written addressing this question, so I include adaptations of their explanations here. The following answer is based on one written by Richard Pixley: Autoconf generated scripts frequently work on machines which it has never been set up to handle before. That is, it does a good job of inferring a configuration for a new system. Imake cannot do this. Imake uses a common database of host specific data. For X11, this makes sense because the distribution is made as a collection of tools, by one central authority who has control over the database. GNU tools are not released this way. Each GNU tool has a maintainer; these maintainers are scattered across the world. Using a common database would be a maintenance nightmare. Autoconf may appear to be this kind of database, but in fact it is not. Instead of listing host dependencies, it lists program requirements. Imake is special-purpose. It is directed at building the X11 distribution. By comparison to the GNU tools, this is a simple problem. If you view the GNU suite as a collection of native tools, then the problems are similar. But the GNU tools are more powerful than that. The development tools can be configured as cross tools in almost any host+target permutation. All of these configurations can be installed concurrently. They can even be configured to share host independent files across hosts. Imake doesn't address these issues. Imake templates are a form of standardization. The GNU coding standards address the same issues without necessarily imposing the same restrictions. Here is some further explanation, written by Per Bothner: One of the advantages of Imake is that it easy to generate large Makefiles using `cpp''s `#include' and macro mechanisms. However, `cpp' is not programmable: it has limited conditional facilities, and no looping. And `cpp' cannot inspect its environment. All of these problems are solved by using `sh' instead of `cpp'. The shell is fully programmable, has macro substitution, can execute (or source) other shell scripts, and can inspect its environment. Paul Eggert elaborates more: With Autoconf, installers need not assume that Imake itself is already installed and working well. This may not seem like much of an advantage to people who are accustomed to Imake. But on many hosts Imake is not installed or the default installation is not working well, and requiring Imake to install a package hinders the acceptance of that package on those hosts. For example, the Imake template and configuration files might not be installed properly on a host, or the Imake build procedure might wrongly assume that all source files are in one big directory tree, or the Imake configuration might assume one compiler whereas the package or the installer needs to use another, or there might be a version mismatch between the Imake expected by the package and the Imake suported by the host. These problems are much rarer with Autoconf, where each package comes with its own independent configuration processor. Also, Imake often suffers from unexpected interactions between `make' and the installer's C preprocessor. The fundamental problem here is that the C preprocessor was designed to preprocess C programs, not `Makefile's. This is much less of a problem with Autoconf, which uses the general-purpose preprocessor `m4', and where the package's author (rather than the installer) does the preprocessing in a standard way. Finally, Mark Eichin notes: Imake isn't all that extensible, either. In order to add new features to Imake, you need to provide you own project template, and duplicate most of the features of the existing one. This means that for a sophisticated project, using the vendor-provided Imake templates fails to provide any leverage--since they don't cover anything that your own project needs (unless it is an X11 program). On the other side, though: The one advantage that Imake has over `configure': `Imakefile's tend to be much shorter (likewise, less redundant) than `Makefile.in's. There is a fix to this, however--at least for the Kerberos V5 tree, we've modified things to call in common `post.in' and `pre.in' `Makefile' fragments for the entire tree. This means that a lot of common things don't have to be duplicated, even though they normally are in `configure' setups.  File: autoconf.info, Node: Upgrading, Next: History, Prev: Questions, Up: Top Upgrading From Version 1 ************************ Autoconf version 2 is mostly backward compatible with version 1. However, it introduces better ways to do some things, and doesn't support some of the ugly things in version 1. So, depending on how sophisticated your `configure.in' files are, you might have to do some manual work in order to upgrade to version 2. This chapter points out some problems to watch for when upgrading. Also, perhaps your `configure' scripts could benefit from some of the new features in version 2; the changes are summarized in the file `NEWS' in the Autoconf distribution. First, make sure you have GNU `m4' version 1.1 or higher installed, preferably 1.3 or higher. Versions before 1.1 have bugs that prevent them from working with Autoconf version 2. Versions 1.3 and later are much faster than earlier versions, because as of version 1.3, GNU `m4' has a more efficient implementation of diversions and can freeze its internal state in a file that it can read back quickly. * Menu: * Changed File Names:: Files you might rename. * Changed Makefiles:: New things to put in `Makefile.in'. * Changed Macros:: Macro calls you might replace. * Invoking autoupdate:: Replacing old macro names in `configure.in'. * Changed Results:: Changes in how to check test results. * Changed Macro Writing:: Better ways to write your own macros.  File: autoconf.info, Node: Changed File Names, Next: Changed Makefiles, Up: Upgrading Changed File Names ================== If you have an `aclocal.m4' installed with Autoconf (as opposed to in a particular package's source directory), you must rename it to `acsite.m4'. *Note Invoking autoconf::. If you distribute `install.sh' with your package, rename it to `install-sh' so `make' builtin rules won't inadvertantly create a file called `install' from it. `AC_PROG_INSTALL' looks for the script under both names, but it is best to use the new name. If you were using `config.h.top' or `config.h.bot', you still can, but you will have less clutter if you merge them into `acconfig.h'. *Note Invoking autoheader::.  File: autoconf.info, Node: Changed Makefiles, Next: Changed Macros, Prev: Changed File Names, Up: Upgrading Changed Makefiles ================= Add `@CFLAGS@', `@CPPFLAGS@', and `@LDFLAGS@' in your `Makefile.in' files, so they can take advantage of the values of those variables in the environment when `configure' is run. Doing this isn't necessary, but it's a convenience for users. Also add `@configure_input@' in a comment to each input file for `AC_OUTPUT', so that the output files will contain a comment saying they were produced by `configure'. Automatically selecting the right comment syntax for all the kinds of files that people call `AC_OUTPUT' on became too much work. Add `config.log' and `config.cache' to the list of files you remove in `distclean' targets. If you have the following in `Makefile.in': prefix = /usr/local exec_prefix = ${prefix} you must change it to: prefix = @prefix@ exec_prefix = @exec_prefix@ The old feature of replacing those variables without `@' characters around them has been removed.  File: autoconf.info, Node: Changed Macros, Next: Invoking autoupdate, Prev: Changed Makefiles, Up: Upgrading Changed Macros ============== Many of the macros were renamed in Autoconf version 2. You can still use the old names, but the new ones are clearer, and it's easier to find the documentation for them. *Note Old Macro Names::, for a table showing the new names for the old macros. Use the `autoupdate' program to convert your `configure.in' to using the new macro names. *Note Invoking autoupdate::. Some macros have been superseded by similar ones that do the job better, but are not call-compatible. If you get warnings about calling obsolete macros while running `autoconf', you may safely ignore them, but your `configure' script will generally work better if you follow the advice it prints about what to replace the obsolete macros with. In particular, the mechanism for reporting the results of tests has changed. If you were using `echo' or `AC_VERBOSE', your `configure' script's output will look better if you switch to `AC_MSG_CHECKING' and `AC_MSG_RESULT'. *Note Printing Messages::. Those macros work best in conjunction with cache variables. *Note Caching Results::.  File: autoconf.info, Node: Invoking autoupdate, Next: Changed Results, Prev: Changed Macros, Up: Upgrading Using `autoupdate' to Modernize `configure' =========================================== The `autoupdate' program updates a `configure.in' file that calls Autoconf macros by their old names to use the current macro names. In version 2 of Autoconf, most of the macros were renamed to use a more uniform and descriptive naming scheme. *Note Macro Names::, for a description of the new scheme. Although the old names still work (*note Old Macro Names::., for a list of the old macro names and the corresponding new names), you can make your `configure.in' files more readable and make it easier to use the current Autoconf documentation if you update them to use the new macro names. If given no arguments, `autoupdate' updates `configure.in', backing up the original version with the suffix `~' (or the value of the environment variable `SIMPLE_BACKUP_SUFFIX', if that is set). If you give `autoupdate' an argument, it reads that file instead of `configure.in' and writes the updated file to the standard output. `autoupdate' accepts the following options: `--help' `-h' Print a summary of the command line options and exit. `--macrodir=DIR' `-m DIR' Look for the Autoconf macro files in directory DIR instead of the default installation directory. You can also set the `AC_MACRODIR' environment variable to a directory; this option overrides the environment variable. `--version' Print the version number of `autoupdate' and exit.  File: autoconf.info, Node: Changed Results, Next: Changed Macro Writing, Prev: Invoking autoupdate, Up: Upgrading Changed Results =============== If you were checking the results of previous tests by examining the shell variable `DEFS', you need to switch to checking the values of the cache variables for those tests. `DEFS' no longer exists while `configure' is running; it is only created when generating output files. This difference from version 1 is because properly quoting the contents of that variable turned out to be too cumbersome and inefficient to do every time `AC_DEFINE' is called. *Note Cache Variable Names::. For example, here is a `configure.in' fragment written for Autoconf version 1: AC_HAVE_FUNCS(syslog) case "$DEFS" in *-DHAVE_SYSLOG*) ;; *) # syslog is not in the default libraries. See if it's in some other. saved_LIBS="$LIBS" for lib in bsd socket inet; do AC_CHECKING(for syslog in -l$lib) LIBS="$saved_LIBS -l$lib" AC_HAVE_FUNCS(syslog) case "$DEFS" in *-DHAVE_SYSLOG*) break ;; *) ;; esac LIBS="$saved_LIBS" done ;; esac Here is a way to write it for version 2: AC_CHECK_FUNCS(syslog) if test $ac_cv_func_syslog = no; then # syslog is not in the default libraries. See if it's in some other. for lib in bsd socket inet; do AC_CHECK_LIB($lib, syslog, [AC_DEFINE(HAVE_SYSLOG) LIBS="$LIBS $lib"; break]) done fi If you were working around bugs in `AC_DEFINE_UNQUOTED' by adding backslashes before quotes, you need to remove them. It now works predictably, and does not treat quotes (except backquotes) specially. *Note Setting Output Variables::. All of the boolean shell variables set by Autoconf macros now use `yes' for the true value. Most of them use `no' for false, though for backward compatibility some use the empty string instead. If you were relying on a shell variable being set to something like 1 or `t' for true, you need to change your tests.  File: autoconf.info, Node: Changed Macro Writing, Prev: Changed Results, Up: Upgrading Changed Macro Writing ===================== When defining your own macros, you should now use `AC_DEFUN' instead of `define'. `AC_DEFUN' automatically calls `AC_PROVIDE' and ensures that macros called via `AC_REQUIRE' do not interrupt other macros, to prevent nested `checking...' messages on the screen. There's no actual harm in continuing to use the older way, but it's less convenient and attractive. *Note Macro Definitions::. You probably looked at the macros that came with Autoconf as a guide for how to do things. It would be a good idea to take a look at the new versions of them, as the style is somewhat improved and they take advantage of some new features. If you were doing tricky things with undocumented Autoconf internals (macros, variables, diversions), check whether you need to change anything to account for changes that have been made. Perhaps you can even use an officially supported technique in version 2 instead of kludging. Or perhaps not. To speed up your locally written feature tests, add caching to them. See whether any of your tests are of general enough usefulness to encapsulate into macros that you can share.  File: autoconf.info, Node: History, Next: Old Macro Names, Prev: Upgrading, Up: Top History of Autoconf ******************* You may be wondering, Why was Autoconf originally written? How did it get into its present form? (Why does it look like gorilla spit?) If you're not wondering, then this chapter contains no information useful to you, and you might as well skip it. If you *are* wondering, then let there be light... * Menu: * Genesis:: Prehistory and naming of `configure'. * Exodus:: The plagues of `m4' and Perl. * Leviticus:: The priestly code of portability arrives. * Numbers:: Growth and contributors. * Deuteronomy:: Approaching the promises of easy configuration.  File: autoconf.info, Node: Genesis, Next: Exodus, Up: History Genesis ======= In June 1991 I was maintaining many of the GNU utilities for the Free Software Foundation. As they were ported to more platforms and more programs were added, the number of `-D' options that users had to select in the `Makefile' (around 20) became burdensome. Especially for me--I had to test each new release on a bunch of different systems. So I wrote a little shell script to guess some of the correct settings for the fileutils package, and released it as part of fileutils 2.0. That `configure' script worked well enough that the next month I adapted it (by hand) to create similar `configure' scripts for several other GNU utilities packages. Brian Berliner also adapted one of my scripts for his CVS revision control system. Later that summer, I learned that Richard Stallman and Richard Pixley were developing similar scripts to use in the GNU compiler tools; so I adapted my `configure' scripts to support their evolving interface: using the file name `Makefile.in' as the templates; adding `+srcdir', the first option (of many); and creating `config.status' files.  File: autoconf.info, Node: Exodus, Next: Leviticus, Prev: Genesis, Up: History Exodus ====== As I got feedback from users, I incorporated many improvements, using Emacs to search and replace, cut and paste, similar changes in each of the scripts. As I adapted more GNU utilities packages to use `configure' scripts, updating them all by hand became impractical. Rich Murphey, the maintainer of the GNU graphics utilities, sent me mail saying that the `configure' scripts were great, and asking if I had a tool for generating them that I could send him. No, I thought, but I should! So I started to work out how to generate them. And the journey from the slavery of hand-written `configure' scripts to the abundance and ease of Autoconf began. Cygnus `configure', which was being developed at around that time, is table driven; it is meant to deal mainly with a discrete number of system types with a small number of mainly unguessable features (such as details of the object file format). The automatic configuration system that Brian Fox had developed for Bash takes a similar approach. For general use, it seems to me a hopeless cause to try to maintain an up-to-date database of which features each variant of each operating system has. It's easier and more reliable to check for most features on the fly--especially on hybrid systems that people have hacked on locally or that have patches from vendors installed. I considered using an architecture similar to that of Cygnus `configure', where there is a single `configure' script that reads pieces of `configure.in' when run. But I didn't want to have to distribute all of the feature tests with every package, so I settled on having a different `configure' made from each `configure.in' by a preprocessor. That approach also offered more control and flexibility. I looked briefly into using Larry Wall's Metaconfig program, but I decided not to for several reasons. The `Configure' scripts it produces are interactive, which I find quite inconvenient; I didn't like the ways it checked for some features (such as library functions); it was not being maintained at that time, and its scripts didn't work on many modern systems (such as System V R4 and NeXT); it wasn't very flexible in what it could do in response to a feature's presence or absence; I found it confusing to learn; and it was too big and complex for my needs (I didn't realize then how much Autoconf would eventually have to grow). I considered using Perl to generate my style of `configure' scripts, but decided that `m4' was better suited to the job of simple textual substitutions: it gets in the way less, because output is implicit. Plus, everyone already has it. (Initially I didn't rely on the GNU extensions to `m4'.) Also, some of my friends at the University of Maryland had recently been putting `m4' front ends on several programs, including `tvtwm', and I was interested in trying out a new language.  File: autoconf.info, Node: Leviticus, Next: Numbers, Prev: Exodus, Up: History Leviticus ========= Since my `configure' scripts determine the system's capabilities automatically, with no interactive user intervention, I decided to call the program that generates them Autoconfig. But with a version number tacked on, that name would be too long for old UNIX file systems, so I shortened it to Autoconf. In the fall of 1991 I called together a group of fellow questers after the Holy Grail of portability (er, that is, alpha testers) to give me feedback as I encapsulated pieces of my handwritten scripts in `m4' macros and continued to add features and improve the techniques used in the checks. Prominent among the testers were Franc,ois Pinard, who came up with the idea of making an `autoconf' shell script to run `m4' and check for unresolved macro calls; Richard Pixley, who suggested running the compiler instead of searching the file system to find include files and symbols, for more accurate results; Karl Berry, who got Autoconf to configure TeX and added the macro index to the documentation; and Ian Taylor, who added support for creating a C header file as an alternative to putting `-D' options in a `Makefile', so he could use Autoconf for his UUCP package. The alpha testers cheerfully adjusted their files again and again as the names and calling conventions of the Autoconf macros changed from release to release. They all contributed many specific checks, great ideas, and bug fixes.  File: autoconf.info, Node: Numbers, Next: Deuteronomy, Prev: Leviticus, Up: History Numbers ======= In July 1992, after months of alpha testing, I released Autoconf 1.0, and converted many GNU packages to use it. I was surprised by how positive the reaction to it was. More people started using it than I could keep track of, including people working on software that wasn't part of the GNU Project (such as TCL, FSP, and Kerberos V5). Autoconf continued to improve rapidly, as many people using the `configure' scripts reported problems they encountered. Autoconf turned out to be a good torture test for `m4' implementations. UNIX `m4' started to dump core because of the length of the macros that Autoconf defined, and several bugs showed up in GNU `m4' as well. Eventually, we realized that we needed to use some features that only GNU `m4' has. 4.3BSD `m4', in particular, has an impoverished set of builtin macros; the System V version is better, but still doesn't provide everything we need. More development occurred as people put Autoconf under more stresses (and to uses I hadn't anticipated). Karl Berry added checks for X11. david zuhn contributed C++ support. Franc,ois Pinard made it diagnose invalid arguments. Jim Blandy bravely coerced it into configuring GNU Emacs, laying the groundwork for several later improvements. Roland McGrath got it to configure the GNU C Library, wrote the `autoheader' script to automate the creation of C header file templates, and added a `--verbose' option to `configure'. Noah Friedman added the `--macrodir' option and `AC_MACRODIR' environment variable. Roland and Noah improved the quoting protection in `AC_DEFINE' and fixed many bugs, especially when I got sick of dealing with portability problems from February through June, 1993.  File: autoconf.info, Node: Deuteronomy, Prev: Numbers, Up: History Deuteronomy =========== A long wish list for major features had accumulated, and the effect of several years of patching by various people had left some residual cruft. In April 1994, while working for Cygnus Support, I began a major revision of Autoconf. I added most of the features of the Cygnus `configure' that Autoconf had lacked, largely by adapting the relevant parts of Cygnus `configure' with the help of david zuhn and Ken Raeburn. These features include support for using `config.sub', `config.guess', `--host', and `--target'; making links to files; and running `configure' scripts in subdirectories. Adding these features enabled Ken to convert GNU `as', and Rob Savoye to convert DejaGNU, to using Autoconf. I added more features in response to other peoples' requests. Many people had asked for `configure' scripts to share the results of the checks between runs, because (particularly when configuring a large source tree, like Cygnus does) they were frustratingly slow. Mike Haertel suggested adding site-specific initialization scripts. People distributing software that had to unpack on MS-DOS asked for a way to override the `.in' extension on the file names, which produced file names like `config.h.in' containing two dots. Jim Avera did an extensive examination of the problems with quoting in `AC_DEFINE' and `AC_SUBST'; his insights led to significant improvements. Richard Stallman asked that compiler output be sent to `config.log' instead of `/dev/null', to help people debug the Emacs `configure' script. I made some other changes because of my dissatisfaction with the quality of the program. I made the messages showing results of the checks less ambiguous, always printing a result. I regularized the names of the macros and cleaned up coding style inconsistencies. I added some auxiliary utilities that I had developed to help convert source code packages to use Autoconf. With the help of Franc,ois Pinard, I made the macros not interrupt each others' messages. (That feature revealed some performance bottlenecks in GNU `m4', which he hastily corrected!) I reorganized the documentation around problems people want to solve. And I began a testsuite, because experience had shown that Autoconf has a pronounced tendency to regress when we change it. Again, several alpha testers gave invaluable feedback, especially Franc,ois Pinard, Jim Meyering, Karl Berry, Rob Savoye, and Ken Raeburn. Finally, version 2.0 was ready. And there was much rejoicing. (And I have free time again. I think.)  File: autoconf.info, Node: Old Macro Names, Next: Environment Variable Index, Prev: History, Up: Top Old Macro Names *************** In version 2 of Autoconf, most of the macros were renamed to use a more uniform and descriptive naming scheme. Here are the old names of the macros that were renamed, followed by the current names of those macros. Although the old names are still accepted by the `autoconf' program for backward compatibility, the old names are considered obsolete. *Note Macro Names::, for a description of the new naming scheme. `AC_ALLOCA' `AC_FUNC_ALLOCA' `AC_ARG_ARRAY' removed because of limited usefulness `AC_CHAR_UNSIGNED' `AC_C_CHAR_UNSIGNED' `AC_CONST' `AC_C_CONST' `AC_CROSS_CHECK' `AC_C_CROSS' `AC_ERROR' `AC_MSG_ERROR' `AC_FIND_X' `AC_PATH_X' `AC_FIND_XTRA' `AC_PATH_XTRA' `AC_FUNC_CHECK' `AC_CHECK_FUNC' `AC_GCC_TRADITIONAL' `AC_PROG_GCC_TRADITIONAL' `AC_GETGROUPS_T' `AC_TYPE_GETGROUPS' `AC_GETLOADAVG' `AC_FUNC_GETLOADAVG' `AC_HAVE_FUNCS' `AC_CHECK_FUNCS' `AC_HAVE_HEADERS' `AC_CHECK_HEADERS' `AC_HAVE_POUNDBANG' `AC_SYS_INTERPRETER' (different calling convention) `AC_HEADER_CHECK' `AC_CHECK_HEADER' `AC_HEADER_EGREP' `AC_EGREP_HEADER' `AC_INLINE' `AC_C_INLINE' `AC_LN_S' `AC_PROG_LN_S' `AC_LONG_DOUBLE' `AC_C_LONG_DOUBLE' `AC_LONG_FILE_NAMES' `AC_SYS_LONG_FILE_NAMES' `AC_MAJOR_HEADER' `AC_HEADER_MAJOR' `AC_MINUS_C_MINUS_O' `AC_PROG_CC_C_O' `AC_MMAP' `AC_FUNC_MMAP' `AC_MODE_T' `AC_TYPE_MODE_T' `AC_OFF_T' `AC_TYPE_OFF_T' `AC_PID_T' `AC_TYPE_PID_T' `AC_PREFIX' `AC_PREFIX_PROGRAM' `AC_PROGRAMS_CHECK' `AC_CHECK_PROGS' `AC_PROGRAMS_PATH' `AC_PATH_PROGS' `AC_PROGRAM_CHECK' `AC_CHECK_PROG' `AC_PROGRAM_EGREP' `AC_EGREP_CPP' `AC_PROGRAM_PATH' `AC_PATH_PROG' `AC_REMOTE_TAPE' removed because of limited usefulness `AC_RESTARTABLE_SYSCALLS' `AC_SYS_RESTARTABLE_SYSCALLS' `AC_RETSIGTYPE' `AC_TYPE_SIGNAL' `AC_RSH' removed because of limited usefulness `AC_SETVBUF_REVERSED' `AC_FUNC_SETVBUF_REVERSED' `AC_SET_MAKE' `AC_PROG_MAKE_SET' `AC_SIZEOF_TYPE' `AC_CHECK_SIZEOF' `AC_SIZE_T' `AC_TYPE_SIZE_T' `AC_STAT_MACROS_BROKEN' `AC_HEADER_STAT' `AC_STDC_HEADERS' `AC_HEADER_STDC' `AC_STRCOLL' `AC_FUNC_STRCOLL' `AC_ST_BLKSIZE' `AC_STRUCT_ST_BLKSIZE' `AC_ST_BLOCKS' `AC_STRUCT_ST_BLOCKS' `AC_ST_RDEV' `AC_STRUCT_ST_RDEV' `AC_SYS_SIGLIST_DECLARED' `AC_DECL_SYS_SIGLIST' `AC_TEST_CPP' `AC_TRY_CPP' `AC_TEST_PROGRAM' `AC_TRY_RUN' `AC_TIMEZONE' `AC_STRUCT_TIMEZONE' `AC_TIME_WITH_SYS_TIME' `AC_HEADER_TIME' `AC_UID_T' `AC_TYPE_UID_T' `AC_UTIME_NULL' `AC_FUNC_UTIME_NULL' `AC_VFORK' `AC_FUNC_VFORK' `AC_VPRINTF' `AC_FUNC_VPRINTF' `AC_WAIT3' `AC_FUNC_WAIT3' `AC_WARN' `AC_MSG_WARN' `AC_WORDS_BIGENDIAN' `AC_C_BIGENDIAN' `AC_YYTEXT_POINTER' `AC_DECL_YYTEXT'  File: autoconf.info, Node: Environment Variable Index, Next: Output Variable Index, Prev: Old Macro Names, Up: Top Environment Variable Index ************************** This is an alphabetical list of the environment variables that Autoconf checks. * Menu: * AC_MACRODIR: Invoking autoupdate. * AC_MACRODIR: Invoking autoscan. * AC_MACRODIR: Invoking autoreconf. * AC_MACRODIR: Invoking ifnames. * AC_MACRODIR: Invoking autoheader. * AC_MACRODIR: Invoking autoconf. * CONFIG_FILES: Invoking config.status. * CONFIG_HEADERS: Invoking config.status. * CONFIG_SHELL: Invoking config.status. * CONFIG_SITE: Site Defaults. * CONFIG_STATUS: Invoking config.status. * SIMPLE_BACKUP_SUFFIX: Invoking autoupdate.