* Site Configuration:: Local defaults for @code{configure}
* Running configure scripts:: How to use the Autoconf output
* Invoking config.status:: Recreating a configuration
+* Obsolete Constructs:: Kept for backward compatibility
* Questions:: Questions about Autoconf, with answers
-* Upgrading:: Tips for upgrading from version 1
* History:: History of Autoconf
-* Obsolete Constructs:: Kept for backward compatibility
* Environment Variable Index:: Index of environment variables used
* Output Variable Index:: Index of variables set in output files
* Preprocessor Symbol Index:: Index of C preprocessor symbols defined
* Environment Variables:: Defining environment variables.
* Invoking configure:: Changing how @code{configure} runs
-Questions About Autoconf
+Obsolete Constructs
-* Distributing:: Distributing @code{configure} scripts
-* Why GNU m4:: Why not use the standard @code{m4}?
-* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
-* Why Not Imake:: Why GNU uses @code{configure} instead of Imake
+* Obsolete config.status Use:: Different calling convention
+* acconfig.h:: Additional entries in @file{config.h.in}
+* Invoking autoupdate:: Automatic update of @file{configure.in}
+* Obsolete Macros:: Backward compatibility macros
+* Autoconf 1:: Tips for upgrading your files
Upgrading From Version 1
* Changed File Names:: Files you might rename
* Changed Makefiles:: New things to put in @file{Makefile.in}
* Changed Macros:: Macro calls you might replace
-* Invoking autoupdate:: Replacing old macros in @code{configure.in}
* Changed Results:: Changes in how to check test results
* Changed Macro Writing:: Better ways to write your own macros
+Questions About Autoconf
+
+* Distributing:: Distributing @code{configure} scripts
+* Why GNU m4:: Why not use the standard @code{m4}?
+* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Why Not Imake:: Why GNU uses @code{configure} instead of Imake
+
History of Autoconf
* Genesis:: Prehistory and naming of @code{configure}
* Numbers:: Growth and contributors
* Deuteronomy:: Approaching the promises of easy configuration
-Obsolete Constructs
-
-* Obsolete config.status Use:: Different calling convention
-* acconfig.h:: Additional entries in @file{config.h.in}
-* Obsolete Macros:: Backward compatibility macros
-
@end detailmenu
@end menu
including @sc{gnu} @code{m4} 1.3. You must use version 1.4 or later of
@sc{gnu} @code{m4}.
-@xref{Upgrading}, for information about upgrading from version 1.
+@xref{Autoconf 1}, for information about upgrading from version 1.
@xref{History}, for the story of Autoconf's development.
@xref{Questions}, for answers to some common questions about Autoconf.
@c ============================================== Recreating a Configuration
-@node Invoking config.status, Questions, Running configure scripts, Top
+@node Invoking config.status, Obsolete Constructs, Running configure scripts, Top
@chapter Recreating a Configuration
@cindex @code{config.status}
@ref{Obsolete config.status Use}, for details.
-@c ================================================ Questions About Autoconf.
+@c =================================================== Obsolete Constructs
-@node Questions, Upgrading, Invoking config.status, Top
-@chapter Questions About Autoconf
+@node Obsolete Constructs, Questions, Invoking config.status, Top
+@chapter Obsolete Constructs
-Several questions about Autoconf come up occasionally. Here some of them
-are addressed.
+Autoconf changes, and along the years, some constructs are obsoleted.
+Most of the changes involve the macros, but the tools themselves, or
+even some concepts, are now considered obsolete.
+
+You may completely skip this chapter if you are new to Autoconf, it's
+intention is mainly to help maintainers updating their packages by
+understanding how to move to more modern constructs.
@menu
-* Distributing:: Distributing @code{configure} scripts
-* Why GNU m4:: Why not use the standard @code{m4}?
-* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
-* Why Not Imake:: Why GNU uses @code{configure} instead of Imake
+* Obsolete config.status Use:: Different calling convention
+* acconfig.h:: Additional entries in @file{config.h.in}
+* Invoking autoupdate:: Automatic update of @file{configure.in}
+* Obsolete Macros:: Backward compatibility macros
+* Autoconf 1:: Tips for upgrading your files
@end menu
-@node Distributing, Why GNU m4, Questions, Questions
-@section Distributing @code{configure} Scripts
+@node Obsolete config.status Use, acconfig.h, Obsolete Constructs, Obsolete Constructs
+@section Obsolete @file{config.status} Invocation
-@display
-What are the restrictions on distributing @code{configure}
-scripts that Autoconf generates? How does that affect my
-programs that use them?
-@end display
+@file{config.status} now supports arguments to specify the files to
+instantiate, see @ref{Invoking config.status}, for more details.
+Before, environment variables had to be used.
-There are no restrictions on how the configuration scripts that Autoconf
-produces may be distributed or used. In Autoconf version 1, they were
-covered by the @sc{gnu} General Public License. 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.
+@defvar CONFIG_COMMANDS
+@evindex CONFIG_COMMANDS
+The tags of the commands to execute. The default is the arguments given
+to @code{AC_OUTPUT} and @code{AC_CONFIG_COMMANDS} in
+@file{configure.in}.
+@end defvar
-Of the other files that might be used with @code{configure},
-@file{config.h.in} is under whatever copyright you use for your
-@file{configure.in}, since it is derived from that file and from the
-public domain file @file{acconfig.h}. @file{config.sub} and
-@file{config.guess} have an exception to the GPL when they are used with
-an Autoconf-generated @code{configure} script, which permits you to
-distribute them under the same terms as the rest of your package.
-@file{install-sh} is from the X Consortium and is not copyrighted.
+@defvar CONFIG_FILES
+@evindex CONFIG_FILES
+The files in which to perform @samp{@@@var{variable}@@} substitutions.
+The default is the arguments given to @code{AC_OUTPUT} and
+@code{AC_CONFIG_FILES} in @file{configure.in}.
+@end defvar
-@node Why GNU m4, Bootstrapping, Distributing, Questions
-@section Why Require @sc{gnu} @code{m4}?
+@defvar CONFIG_HEADERS
+@evindex CONFIG_HEADERS
+The files in which to substitute C @code{#define} statements. The
+default is the arguments given to @code{AC_CONFIG_HEADERS}; if that
+macro was not called, @file{config.status} ignores this variable.
+@end defvar
-@display
-Why does Autoconf require @sc{gnu} @code{m4}?
-@end display
+@defvar CONFIG_LINKS
+@evindex CONFIG_LINKS
+The symbolic links to establish. The default is the arguments given to
+@code{AC_CONFIG_LINKS}; if that macro was not called,
+@file{config.status} ignores this variable.
+@end defvar
-Many @code{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:
+In @ref{Invoking config.status}, using this old interface, the example
+would be:
@example
-builtin
-indir
-patsubst
-__file__
-__line__
-@end example
-
-Autoconf requires version 1.4 or above of @sc{gnu} @code{m4} because it
-uses frozen state files.
+@group
+config.h: stamp-h
+stamp-h: config.h.in config.status
+ CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_FILES= \
+ CONFIG_HEADERS=config.h ./config.status
+ echo > stamp-h
-Since only software maintainers need to use Autoconf, and since @sc{gnu}
-@code{m4} is simple to configure and install, it seems reasonable to
-require @sc{gnu} @code{m4} to be installed also. Many maintainers of
-@sc{gnu} and other free software already have most of the @sc{gnu}
-utilities installed, since they prefer them.
+Makefile: Makefile.in config.status
+ CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_HEADERS= \
+ CONFIG_FILES=Makefile ./config.status
+@end group
+@end example
-@node Bootstrapping, Why Not Imake, Why GNU m4, Questions
-@section How Can I Bootstrap?
+@noindent
+(If @file{configure.in} does not call @code{AC_CONFIG_HEADERS}, there is
+no need to set @code{CONFIG_HEADERS} in the @code{make} rules, equally
+for @code{CONFIG_COMMANDS} etc.)
-@display
-If Autoconf requires @sc{gnu} @code{m4} and @sc{gnu} @code{m4} has an
-Autoconf @code{configure} script, how do I bootstrap? It seems like a
-chicken and egg problem!
-@end display
-This is a misunderstanding. Although @sc{gnu} @code{m4} does come with
-a @code{configure} script produced by Autoconf, Autoconf is not required
-in order to run the script and install @sc{gnu} @code{m4}. Autoconf is
-only required if you want to change the @code{m4} @code{configure}
-script, which few people have to do (mainly its maintainer).
+@node acconfig.h, Invoking autoupdate, Obsolete config.status Use, Obsolete Constructs
+@section @file{acconfig.h}
-@node Why Not Imake, , Bootstrapping, Questions
-@section Why Not Imake?
+@cindex @file{acconfig.h}
+@cindex @file{config.h.top}
+@cindex @file{config.h.bot}
-@display
-Why not use Imake instead of @code{configure} scripts?
-@end display
+@code{autoheader} scans @file{configure.in} and figures out which C
+preprocessor symbols it might define. It copies comments and
+@code{#define} and @code{#undef} statements from a file called
+@file{acconfig.h} in the current directory, if present. This file used
+to be mandatory if you @code{AC_DEFINE} any additional symbols. Now,
+you are encouraged to use the @code{AH} series of macros
+(@pxref{Autoheader Macros}).
-Several people have written addressing this question, so I include
-adaptations of their explanations here.
+The file that @code{autoheader} creates contains mainly @code{#define}
+and @code{#undef} statements and their accompanying comments. If
+@file{./acconfig.h} contains the string @samp{@@TOP@@},
+@code{autoheader} copies the lines before the line containing
+@samp{@@TOP@@} into the top of the file that it generates. Similarly,
+if @file{./acconfig.h} contains the string @samp{@@BOTTOM@@},
+@code{autoheader} copies the lines after that line to the end of the
+file it generates. Either or both of those strings may be omitted.
-The following answer is based on one written by Richard Pixley:
+An alternate way to produce the same effect is to create the files
+@file{@var{file}.top} (typically @file{config.h.top}) and/or
+@file{@var{file}.bot} in the current directory. If they exist,
+@code{autoheader} copies them to the beginning and end, respectively, of
+its output. Their use is discouraged because they have file names that
+contain two periods, and so cannot be stored on MS-DOS; also, they are
+two more files to clutter up the directory. But if you use the
+@samp{--localdir=@var{dir}} option to use an @file{acconfig.h} in
+another directory, they give you a way to put custom boilerplate in each
+individual @file{config.h.in}.
-@quotation
-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.
+@node Invoking autoupdate, Obsolete Macros, acconfig.h, Obsolete Constructs
+@section Using @code{autoupdate} to Modernize @code{configure}
+@cindex @code{autoupdate}
-@sc{gnu} tools are not released this way. Each @sc{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.
+The @code{autoupdate} program updates a @file{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. @xref{Macro Names}, for a
+description of the new scheme. Although the old names still work
+(@pxref{Obsolete Macros}, for a list of the old macros and the corresponding
+new names), you can make your @file{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 you view the @sc{gnu} suite as a collection of native tools, then the
-problems are similar. But the @sc{gnu} 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.
+@evindex SIMPLE_BACKUP_SUFFIX
+If given no arguments, @code{autoupdate} updates @file{configure.in},
+backing up the original version with the suffix @file{~} (or the value
+of the environment variable @code{SIMPLE_BACKUP_SUFFIX}, if that is
+set). If you give @code{autoupdate} an argument, it reads that file
+instead of @file{configure.in} and writes the updated file to the
+standard output.
-Imake templates are a form of standardization. The @sc{gnu} coding
-standards address the same issues without necessarily imposing the same
-restrictions.
-@end quotation
+@noindent
+@code{autoupdate} accepts the following options:
+@table @code
+@item --help
+@itemx -h
+Print a summary of the command line options and exit.
-Here is some further explanation, written by Per Bothner:
+@item --version
+@itemx -V
+Print the version number of Autoconf and exit.
-@quotation
-One of the advantages of Imake is that it easy to generate large
-Makefiles using @code{cpp}'s @samp{#include} and macro mechanisms.
-However, @code{cpp} is not programmable: it has limited conditional
-facilities, and no looping. And @code{cpp} cannot inspect its
-environment.
+@item --verbose
+@itemx -v
+Report processing steps.
-All of these problems are solved by using @code{sh} instead of
-@code{cpp}. The shell is fully programmable, has macro substitution,
-can execute (or source) other shell scripts, and can inspect its
-environment.
-@end quotation
+@item --debug
+@itemx -d
+Don't remove the temporary files.
+@item --macrodir=@var{dir}
+@itemx -m @var{dir}
+@evindex AC_MACRODIR
+Look for the installed macro files in directory @var{dir}. You can also
+set the @code{AC_MACRODIR} environment variable to a directory; this
+option overrides the environment variable.
-Paul Eggert elaborates more:
-
-@quotation
-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
-supported 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
-@code{make} and the installer's C preprocessor. The fundamental problem
-here is that the C preprocessor was designed to preprocess C programs,
-not @file{Makefile}s. This is much less of a problem with Autoconf,
-which uses the general-purpose preprocessor @code{m4}, and where the
-package's author (rather than the installer) does the preprocessing in a
-standard way.
-@end quotation
-
-
-Finally, Mark Eichin notes:
+@item --localdir=@var{dir}
+@itemx -l @var{dir}
+Look for the package file @file{aclocal.m4} in directory @var{dir}
+instead of in the current directory.
+@end table
-@quotation
-Imake isn't all that extensible, either. In order to add new features to
-Imake, you need to provide your 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).
+@node Obsolete Macros, Autoconf 1, Invoking autoupdate, Obsolete Constructs
+@section Obsolete Macros
-On the other side, though:
+Several macros are obsoleted in Autoconf, for various reasons (typically
+they failed to quote properly, couldn't be extended for more recent
+issues etc.). They are still supported, but deprecated: their use
+should be avoided.
-The one advantage that Imake has over @code{configure}:
-@file{Imakefile}s tend to be much shorter (likewise, less redundant)
-than @file{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
-@file{post.in} and @file{pre.in} @file{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 @code{configure} setups.
-@end quotation
+During the jump between Autoconf version 1 and version 2, most of the
+macros were renamed to use a more uniform and descriptive naming scheme,
+but their signature did not change. @xref{Macro Names}, for a
+description of the new naming scheme. Below, there is just the mapping
+from old names to new names for these macros, the reader is invited to
+refer to the definition of the new macro for the signature, and the
+description.
+@defmac AC_ALLOCA
+@maindex ALLOCA
+@code{AC_FUNC_ALLOCA}
+@end defmac
+@defmac AC_ARG_ARRAY
+@maindex ARG_ARRAY
+removed because of limited usefulness
+@end defmac
-@c ================================================= Upgrading From Version 1.
+@defmac AC_C_CROSS
+@maindex C_CROSS
+This macro is obsolete; it does nothing.
+@end defmac
-@node Upgrading, History, Questions, Top
-@chapter Upgrading From Version 1
+@defmac AC_CANONICAL_SYSTEM
+@maindex CANONICAL_SYSTEM
+Determine the system type and set output variables to the names of the
+canonical system types. @xref{System Type Variables}, for details about
+the variables this macro sets.
-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 @file{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
-@code{configure} scripts could benefit from some of the new features in
-version 2; the changes are summarized in the file @file{NEWS} in the
-Autoconf distribution.
+The user is encouraged to explicitly use either
+@code{AC_CANONICAL_BUILD}, or @code{AC_CANONICAL_HOST}, or
+@code{AC_CANONICAL_TARGET}, depending on her needs. Using
+@code{AC_CANONICAL_TARGET} is enough to run the three macros.
+@end defmac
-First, make sure you have @sc{gnu} @code{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,
-@sc{gnu} @code{m4} has a more efficient implementation of diversions and
-can freeze its internal state in a file that it can read back quickly.
+@defmac AC_CHAR_UNSIGNED
+@maindex CHAR_UNSIGNED
+@code{AC_C_CHAR_UNSIGNED}
+@end defmac
-@menu
-* Changed File Names:: Files you might rename
-* Changed Makefiles:: New things to put in @file{Makefile.in}
-* Changed Macros:: Macro calls you might replace
-* Invoking autoupdate:: Replacing old macros in @code{configure.in}
-* Changed Results:: Changes in how to check test results
-* Changed Macro Writing:: Better ways to write your own macros
-@end menu
+@defmac AC_CHECK_TYPE (@var{type}, @var{default})
+@maindex CHECK_TYPE
+Autoconf, up to 2.13, used to provide to this version of
+@code{AC_CHECK_TYPE}, broken by design. First, although it is a member
+of the @code{CHECK} clan, singular sub-family, it does more than just
+checking. Second, missing types are not typedef'd, they are defined,
+which can lead to incompatible code in the case of pointer types.
-@node Changed File Names, Changed Makefiles, Upgrading, Upgrading
-@section Changed File Names
+This use of @code{AC_CHECK_TYPE} is obsolete and discouraged, see
+@ref{Generic Types}, for the description of the current macro.
-If you have an @file{aclocal.m4} installed with Autoconf (as opposed to
-in a particular package's source directory), you must rename it to
-@file{acsite.m4}. @xref{Invoking autoconf}.
+If the type @var{type} is not defined, define it to be the C (or C++)
+builtin type @var{default}; e.g., @samp{short} or @samp{unsigned}.
-If you distribute @file{install.sh} with your package, rename it to
-@file{install-sh} so @code{make} builtin rules won't inadvertently
-create a file called @file{install} from it. @code{AC_PROG_INSTALL}
-looks for the script under both names, but it is best to use the new name.
+This macro is equivalent to
+@example
+AC_CHECK_TYPE([@var{type}],
+ [AC_DEFINE([@var{type}], [@var{default}],
+ [Define to `@var{default}' if <sys/types.h>
+ does not define.])])
+@end example
+In order to keep backward compatibility, the two versions of
+@code{AC_CHECK_TYPE} are implemented, selected by a simple heuristics:
+@itemize @bullet
+@item
+if there are three or four arguments, the modern version is used;
-If you were using @file{config.h.top} or @file{config.h.bot}, you still
-can, but you will have less clutter if you merge them into
-@file{acconfig.h}. @xref{Invoking autoheader}.
+@item
+if the second argument is a C or C++ @strong{builtin} type, then the
+obsolete version is used;
-@node Changed Makefiles, Changed Macros, Changed File Names, Upgrading
-@section Changed Makefiles
+@item
+if the second argument is spelled with the alphabet of valid C and C++
+types, the user is warned and the modern version is used;
-Add @samp{@@CFLAGS@@}, @samp{@@CPPFLAGS@@}, and @samp{@@LDFLAGS@@} in
-your @file{Makefile.in} files, so they can take advantage of the values
-of those variables in the environment when @code{configure} is run.
-Doing this isn't necessary, but it's a convenience for users.
+@item
+otherwise, the modern version is used.
+@end itemize
-Also add @samp{@@configure_input@@} in a comment to each input file for
-@code{AC_OUTPUT}, so that the output files will contain a comment saying
-they were produced by @code{configure}. Automatically selecting the
-right comment syntax for all the kinds of files that people call
-@code{AC_OUTPUT} on became too much work.
+@noindent
+In particular, the following code, which was invalid but functional:
-Add @file{config.log} and @file{config.cache} to the list of files you
-remove in @code{distclean} targets.
+@example
+AC_CHECK_TYPE(loff_t, off_t)
+@end example
-If you have the following in @file{Makefile.in}:
+@noindent
+will be improperly branched to the modern implementation. You are
+encouraged either to use a valid builtin type, or to use the equivalent
+modern code (see above), or better yet, to use @code{AC_CHECK_TYPES}
+together with
@example
-prefix = /usr/local
-exec_prefix = $(prefix)
+#if !HAVE_LOFF_T
+typedef loff_t off_t;
+#endif
@end example
+@end defmac
+@c end of AC_CHECK_TYPE
-@noindent
-you must change it to:
+@defmac AC_CHECKING (@var{feature-description})
+@maindex CHECKING
+This macro is similar to @code{AC_MSG_CHECKING}, except that it prints a
+newline after the @var{feature-description}. It is useful mainly to
+print a general description of the overall purpose of a group of feature
+checks, e.g.,
@example
-prefix = @@prefix@@
-exec_prefix = @@exec_prefix@@
+AC_CHECKING(if stack overflow is detectable)
@end example
+@end defmac
-@noindent
-The old behavior of replacing those variables without @samp{@@}
-characters around them has been removed.
+@defmac AC_COMPILE_CHECK (@var{echo-text}, @var{includes}, @var{function-body}, @var{action-if-found}, @ovar{action-if-not-found})
+@maindex COMPILE_CHECK
+This is an obsolete version of @code{AC_TRY_LINK} (@pxref{Examining
+Libraries}), with the addition that it prints @samp{checking for
+@var{echo-text}} to the standard output first, if @var{echo-text} is
+non-empty. Use @code{AC_MSG_CHECKING} and @code{AC_MSG_RESULT} instead
+to print messages (@pxref{Printing Messages}).
+@end defmac
-@node Changed Macros, Invoking autoupdate, Changed Makefiles, Upgrading
-@section Changed Macros
+@defmac AC_CONST
+@maindex CONST
+@code{AC_C_CONST}
+@end defmac
-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. @xref{Obsolete Macros}, for a table showing the
-new names for the old macros. Use the @code{autoupdate} program to
-convert your @file{configure.in} to using the new macro names.
-@xref{Invoking autoupdate}.
+@defmac AC_CROSS_CHECK
+@maindex CROSS_CHECK
+@code{AC_C_CROSS}
+@end defmac
-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 @code{autoconf}, you may safely ignore them, but
-your @code{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 @code{echo} or @code{AC_VERBOSE} (perhaps
-via @code{AC_COMPILE_CHECK}), your @code{configure} script's output will
-look better if you switch to @code{AC_MSG_CHECKING} and
-@code{AC_MSG_RESULT}. @xref{Printing Messages}. Those macros work best
-in conjunction with cache variables. @xref{Caching Results}.
+@defmac AC_CYGWIN
+@maindex CYGWIN
+Checked for the Cygwin environment in which case the shell variable
+@code{CYGWIN} is set to @samp{yes}. @code{AC_EXEEXT} now handles this
+task.
+@end defmac
-@node Invoking autoupdate, Changed Results, Changed Macros, Upgrading
-@section Using @code{autoupdate} to Modernize @code{configure}
-@cindex @code{autoupdate}
+@defmac AC_DECL_YYTEXT
+Does nothing, now integrated in @code{AC_PROG_LEX}.
+@end defmac
-The @code{autoupdate} program updates a @file{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. @xref{Macro Names}, for a
-description of the new scheme. Although the old names still work
-(@pxref{Obsolete Macros}, for a list of the old macros and the corresponding
-new names), you can make your @file{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.
+@defmac AC_DYNIX_SEQ
+@maindex DYNIX_SEQ
+If on Dynix/PTX (Sequent @sc{unix}), add @samp{-lseq} to output variable
+@code{LIBS}. This macro used to be defined as
-@evindex SIMPLE_BACKUP_SUFFIX
-If given no arguments, @code{autoupdate} updates @file{configure.in},
-backing up the original version with the suffix @file{~} (or the value
-of the environment variable @code{SIMPLE_BACKUP_SUFFIX}, if that is
-set). If you give @code{autoupdate} an argument, it reads that file
-instead of @file{configure.in} and writes the updated file to the
-standard output.
+@example
+AC_CHECK_LIB(seq, getmntent, LIBS="-lseq $LIBS")
+@end example
@noindent
-@code{autoupdate} accepts the following options:
+now it is just @code{AC_FUNC_GETMNTENT}.
+@end defmac
-@table @code
-@item --help
-@itemx -h
-Print a summary of the command line options and exit.
+@defmac AC_EXEEXT
+@maindex EXEEXT
+@ovindex EXEEXT
+@ovindex CYGWIN
+@ovindex EMXOS2
+@ovindex MINGW32
+Defined the output variable @code{EXEEXT} based on the output of the
+compiler, after @samp{.$ac_ext} (i.e. source files of the current
+language), @samp{.o}, @samp{.obj} and @samp{.xcoff} files have been
+excluded. Typically set to empty string if Unix and @samp{.exe} if
+Win32 or OS/2.
-@item --version
-@itemx -V
-Print the version number of Autoconf and exit.
+This macro sets the shell variable @code{CYGWIN} to @samp{yes} if run in
+the Cygwin environment, @code{EMXOS2} to @samp{yes} if in the EMX
+environment on OS/2, and @code{MINGW32} to @samp{yes} with the MingW32
+compiler.
-@item --verbose
-@itemx -v
-Report processing steps.
+Now handled by the macros checking for the compiler.
+@end defmac
-@item --debug
-@itemx -d
-Don't remove the temporary files.
+@defmac AC_EMXOS2
+@maindex EMXOS2
+Checks for the EMX environment on OS/2in which case the shell variable
+@code{EMXOS2} is set to @samp{yes}. @code{AC_EXEEXT} now handles this
+task.
+@end defmac
-@item --macrodir=@var{dir}
-@itemx -m @var{dir}
-@evindex AC_MACRODIR
-Look for the installed macro files in directory @var{dir}. You can also
-set the @code{AC_MACRODIR} environment variable to a directory; this
-option overrides the environment variable.
+@defmac AC_ERROR
+@maindex ERROR
+@code{AC_MSG_ERROR}
+@end defmac
-@item --localdir=@var{dir}
-@itemx -l @var{dir}
-Look for the package file @file{aclocal.m4} in directory @var{dir}
-instead of in the current directory.
-@end table
+@defmac AC_FIND_X
+@maindex FIND_X
+@code{AC_PATH_X}
+@end defmac
-@node Changed Results, Changed Macro Writing, Invoking autoupdate, Upgrading
-@section Changed Results
+@defmac AC_FIND_XTRA
+@maindex FIND_XTRA
+@code{AC_PATH_XTRA}
+@end defmac
-If you were checking the results of previous tests by examining the
-shell variable @code{DEFS}, you need to switch to checking the values of
-the cache variables for those tests. @code{DEFS} no longer exists while
-@code{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 @code{AC_DEFINE} is called. @xref{Cache
-Variable Names}.
+@defmac AC_FUNC_CHECK
+@maindex FUNC_CHECK
+@code{AC_CHECK_FUNC}
+@end defmac
-For example, here is a @file{configure.in} fragment written for Autoconf
-version 1:
+@defmac AC_GCC_TRADITIONAL
+@maindex GCC_TRADITIONAL
+@code{AC_PROG_GCC_TRADITIONAL}
+@end defmac
-@example
-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
-@end example
+@defmac AC_GETGROUPS_T
+@maindex GETGROUPS_T
+@code{AC_TYPE_GETGROUPS}
+@end defmac
-Here is a way to write it for version 2:
+@defmac AC_GETLOADAVG
+@maindex GETLOADAVG
+@code{AC_FUNC_GETLOADAVG}
+@end defmac
-@example
-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 -l$lib"; break])
- done
-fi
-@end example
+@defmac AC_HAVE_FUNCS
+@maindex HAVE_FUNCS
+@code{AC_CHECK_FUNCS}
+@end defmac
-If you were working around bugs in @code{AC_DEFINE_UNQUOTED} by adding
-backslashes before quotes, you need to remove them. It now works
-predictably, and does not treat quotes (except back quotes) specially.
-@xref{Setting Output Variables}.
+@defmac AC_HAVE_HEADERS
+@maindex HAVE_HEADERS
+@code{AC_CHECK_HEADERS}
+@end defmac
-All of the boolean shell variables set by Autoconf macros now use
-@samp{yes} for the true value. Most of them use @samp{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
-@samp{t} for true, you need to change your tests.
+@defmac AC_HAVE_LIBRARY (@var{library}, @ovar{action-if-found}, @ovar{action-if-not-found}, @ovar{other-libraries})
+@maindex HAVE_LIBRARY
+This macro is equivalent to calling @code{AC_CHECK_LIB} with a
+@var{function} argument of @code{main}. In addition, @var{library} can
+be written as any of @samp{foo}, @samp{-lfoo}, or @samp{libfoo.a}. In
+all of those cases, the compiler is passed @samp{-lfoo}. However,
+@var{library} cannot be a shell variable; it must be a literal name.
+@end defmac
-@node Changed Macro Writing, , Changed Results, Upgrading
-@section Changed Macro Writing
+@defmac AC_HAVE_POUNDBANG
+@maindex HAVE_POUNDBANG
+@code{AC_SYS_INTERPRETER} (different calling convention)
+@end defmac
-When defining your own macros, you should now use @code{AC_DEFUN}
-instead of @code{define}. @code{AC_DEFUN} automatically calls
-@code{AC_PROVIDE} and ensures that macros called via @code{AC_REQUIRE}
-do not interrupt other macros, to prevent nested @samp{checking@dots{}}
-messages on the screen. There's no actual harm in continuing to use the
-older way, but it's less convenient and attractive. @xref{Macro
-Definitions}.
+@defmac AC_HEADER_CHECK
+@maindex HEADER_CHECK
+@code{AC_CHECK_HEADER}
+@end defmac
-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.
+@defmac AC_HEADER_EGREP
+@maindex HEADER_EGREP
+@code{AC_EGREP_HEADER}
+@end defmac
-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.
+@defmac AC_INIT (@var{unique-file-in-source-dir})
+@maindex INIT
+Formerly @code{AC_INIT} used to have a single argument, and was
+equivalent to:
-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.
+@example
+AC_INIT
+AC_CONFIG_SRCDIR(@var{unique-file-in-source-dir})
+@end example
+@end defmac
+@defmac AC_INLINE
+@maindex INLINE
+@code{AC_C_INLINE}
+@end defmac
-@c ===================================================== History of Autoconf.
+@defmac AC_IRIX_SUN
+@maindex IRIX_SUN
+If on IRIX (Silicon Graphics @sc{unix}), add @samp{-lsun} to output
+@code{LIBS}. If you were using it to get @code{getmntent}, use
+@code{AC_FUNC_GETMNTENT} instead. If you used it for the NIS versions
+of the password and group functions, use @samp{AC_CHECK_LIB(sun,
+getpwnam)}. Up to Autoconf 2.13, it used to be
-@node History, Obsolete Constructs, Upgrading, Top
-@chapter History of Autoconf
+@example
+AC_CHECK_LIB(sun, getmntent, LIBS="-lsun $LIBS")
+@end example
-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 @emph{are} wondering,
-then let there be light@dots{}
+@noindent
+now it is defined as
-@menu
-* Genesis:: Prehistory and naming of @code{configure}
-* Exodus:: The plagues of @code{m4} and Perl
-* Leviticus:: The priestly code of portability arrives
-* Numbers:: Growth and contributors
-* Deuteronomy:: Approaching the promises of easy configuration
-@end menu
+@example
+AC_FUNC_GETMNTENT
+AC_CHECK_LIB(sun, getpwnam)
+@end example
+@end defmac
-@node Genesis, Exodus, History, History
-@section Genesis
+@defmac AC_LANG_C
+@maindex LANG_C
+Same as @samp{AC_LANG(C)}.
+@end defmac
-In June 1991 I was maintaining many of the @sc{gnu} utilities for the
-Free Software Foundation. As they were ported to more platforms and
-more programs were added, the number of @samp{-D} options that users had
-to select in the @file{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 @code{configure} script worked well enough that
-the next month I adapted it (by hand) to create similar @code{configure}
-scripts for several other @sc{gnu} utilities packages. Brian Berliner
-also adapted one of my scripts for his CVS revision control system.
+@defmac AC_LANG_CPLUSPLUS
+@maindex LANG_CPLUSPLUS
+Same as @samp{AC_LANG(C++)}.
+@end defmac
-Later that summer, I learned that Richard Stallman and Richard Pixley
-were developing similar scripts to use in the @sc{gnu} compiler tools;
-so I adapted my @code{configure} scripts to support their evolving
-interface: using the file name @file{Makefile.in} as the templates;
-adding @samp{+srcdir}, the first option (of many); and creating
-@file{config.status} files.
+@defmac AC_LANG_FORTRAN77
+@maindex LANG_FORTRAN77
+Same as @samp{AC_LANG(Fortran 77)}.
+@end defmac
-@node Exodus, Leviticus, Genesis, History
-@section Exodus
+@defmac AC_LANG_RESTORE
+@maindex LANG_RESTORE
+Select the @var{language} that is saved on the top of the stack, as set
+by @code{AC_LANG_SAVE}, remove it from the stack, and call
+@code{AC_LANG(@var{language})}.
+@end defmac
-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 @sc{gnu} utilities packages to use
-@code{configure} scripts, updating them all by hand became impractical.
-Rich Murphey, the maintainer of the @sc{gnu} graphics utilities, sent me
-mail saying that the @code{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 @code{configure} scripts to the
-abundance and ease of Autoconf began.
+@defmac AC_LANG_SAVE
+@maindex LANG_SAVE
+Remember the current language (as set by @code{AC_LANG}) on a stack.
+Doe not change which language is current. @code{AC_LANG_PUSH} is
+preferred.
+@end defmac
-Cygnus @code{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.
+@defmac AC_LINK_FILES (@var{source}@dots{}, @var{dest}@dots{})
+@maindex LINK_FILES
+This is an obsolete version of @code{AC_CONFIG_LINKS}. An updated
+version of:
-I considered using an architecture similar to that of Cygnus
-@code{configure}, where there is a single @code{configure} script that
-reads pieces of @file{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 @code{configure} made from each
-@file{configure.in} by a preprocessor. That approach also offered more
-control and flexibility.
+@example
+AC_LINK_FILES(config/$machine.h config/$obj_format.h,
+ host.h object.h)
+@end example
-I looked briefly into using the Metaconfig package, by Larry Wall,
-Harlan Stenn, and Raphael Manfredi, but I decided not to for several
-reasons. The @code{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); I didn't know that it was
-still being maintained, and the @code{Configure} scripts I had
-seen 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).
+@noindent
+is:
-I considered using Perl to generate my style of @code{configure}
-scripts, but decided that @code{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 @sc{gnu} extensions to @code{m4}.) Also, some of my friends at the
-University of Maryland had recently been putting @code{m4} front ends on
-several programs, including @code{tvtwm}, and I was interested in trying
-out a new language.
+@example
+AC_CONFIG_LINKS(host.h:config/$machine.h
+ object.h:config/$obj_format.h)
+@end example
+@end defmac
-@node Leviticus, Numbers, Exodus, History
-@section Leviticus
+@defmac AC_LN_S
+@maindex LN_S
+@code{AC_PROG_LN_S}
+@end defmac
-Since my @code{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 @sc{unix} file systems,
-so I shortened it to Autoconf.
+@defmac AC_LONG_DOUBLE
+@maindex LONG_DOUBLE
+@code{AC_C_LONG_DOUBLE}
+@end defmac
-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 @code{m4}
-macros and continued to add features and improve the techniques used in
-the checks. Prominent among the testers were
-@ifinfo
-Franc,ois
-@end ifinfo
-@tex
-Fran\c cois
-@end tex
-Pinard, who came up with the idea of making an @file{autoconf} shell
-script to run @code{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 @samp{-D} options
-in a @file{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.
+@defmac AC_LONG_FILE_NAMES
+@maindex LONG_FILE_NAMES
+@code{AC_SYS_LONG_FILE_NAMES}
+@end defmac
-@node Numbers, Deuteronomy, Leviticus, History
-@section Numbers
+@defmac AC_MAJOR_HEADER
+@maindex MAJOR_HEADER
+@code{AC_HEADER_MAJOR}
+@end defmac
-In July 1992, after months of alpha testing, I released Autoconf 1.0,
-and converted many @sc{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 @sc{gnu} Project (such as TCL, FSP, and Kerberos V5).
-Autoconf continued to improve rapidly, as many people using the
-@code{configure} scripts reported problems they encountered.
+@defmac AC_MINGW32
+@maindex MINGW32
+Checked for the MingW32 compiler environment, in which case the shell
+variable @code{MINGW32} is set to @samp{yes}. @code{AC_EXEEXT} now
+handles this task.
+@end defmac
-Autoconf turned out to be a good torture test for @code{m4}
-implementations. @sc{unix} @code{m4} started to dump core because of
-the length of the macros that Autoconf defined, and several bugs showed
-up in @sc{gnu} @code{m4} as well. Eventually, we realized that we
-needed to use some features that only @sc{gnu} @code{m4} has.
-4.3@sc{bsd} @code{m4}, in particular, has an impoverished set of builtin
-macros; the System V version is better, but still doesn't provide
-everything we need.
+@defmac AC_MINUS_C_MINUS_O
+@maindex MINUS_C_MINUS_O
+@code{AC_PROG_CC_C_O}
+@end defmac
-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.
-@ifinfo
-Franc,ois
-@end ifinfo
-@tex
-Fran\c cois
-@end tex
-Pinard made it diagnose invalid arguments. Jim Blandy bravely coerced
-it into configuring @sc{gnu} Emacs, laying the groundwork for several
-later improvements. Roland McGrath got it to configure the @sc{gnu} C
-Library, wrote the @code{autoheader} script to automate the creation of
-C header file templates, and added a @samp{--verbose} option to
-@code{configure}. Noah Friedman added the @samp{--macrodir} option and
-@code{AC_MACRODIR} environment variable. (He also coined the term
-@dfn{autoconfiscate} to mean ``adapt a software package to use
-Autoconf''.) Roland and Noah improved the quoting protection in
-@code{AC_DEFINE} and fixed many bugs, especially when I got sick of
-dealing with portability problems from February through June, 1993.
+@defmac AC_MMAP
+@maindex MMAP
+@code{AC_FUNC_MMAP}
+@end defmac
-@node Deuteronomy, , Numbers, History
-@section Deuteronomy
+@defmac AC_MODE_T
+@maindex MODE_T
+@code{AC_TYPE_MODE_T}
+@end defmac
-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
-@code{configure} that Autoconf had lacked, largely by adapting the
-relevant parts of Cygnus @code{configure} with the help of david zuhn
-and Ken Raeburn. These features include support for using
-@file{config.sub}, @file{config.guess}, @samp{--host}, and
-@samp{--target}; making links to files; and running @code{configure}
-scripts in subdirectories. Adding these features enabled Ken to convert
-@sc{gnu} @code{as}, and Rob Savoye to convert DejaGNU, to using
-Autoconf.
+@defmac AC_OBJEXT
+@maindex OBJEXT
+@ovindex OBJEXT
+Defined the output variable @code{OBJEXT} based on the output of the
+compiler, after .c files have been excluded. Typically set to @samp{o}
+if Unix, @samp{obj} if Win32. Now the compiler checking macros handle
+this.
+@end defmac
-I added more features in response to other peoples' requests. Many
-people had asked for @code{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 @file{.in} extension on the file names, which produced file
-names like @file{config.h.in} containing two dots. Jim Avera did an
-extensive examination of the problems with quoting in @code{AC_DEFINE}
-and @code{AC_SUBST}; his insights led to significant improvements.
-Richard Stallman asked that compiler output be sent to @file{config.log}
-instead of @file{/dev/null}, to help people debug the Emacs
-@code{configure} script.
+@defmac AC_OBSOLETE (@var{this-macro-name}, @ovar{suggestion})
+@maindex OBSOLETE
+Make @code{m4} print a message on the standard error output warning that
+@var{this-macro-name} is obsolete, and giving the file and line number
+where it was called. @var{this-macro-name} should be the name of the
+macro that is calling @code{AC_OBSOLETE}. If @var{suggestion} is given,
+it is printed at the end of the warning message; for example, it can be
+a suggestion for what to use instead of @var{this-macro-name}.
-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
-@ifinfo
-Franc,ois
-@end ifinfo
-@tex
-Fran\c cois
-@end tex
-Pinard, I made the macros not interrupt each others' messages. (That
-feature revealed some performance bottlenecks in @sc{gnu} @code{m4},
-which he hastily corrected!) I reorganized the documentation around
-problems people want to solve. And I began a test suite, because
-experience had shown that Autoconf has a pronounced tendency to regress
-when we change it.
+For instance
-Again, several alpha testers gave invaluable feedback, especially
-@ifinfo
-Franc,ois
-@end ifinfo
-@tex
-Fran\c cois
-@end tex
-Pinard, Jim Meyering, Karl Berry, Rob Savoye, Ken Raeburn, and Mark
-Eichin.
+@example
+AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl
+@end example
-Finally, version 2.0 was ready. And there was much rejoicing. (And I
-have free time again. I think. Yeah, right.)
+You are encouraged to use @code{AU_DEFUN} instead, since it gives better
+services to the user.
+@end defmac
+@defmac AC_OFF_T
+@maindex OFF_T
+@code{AC_TYPE_OFF_T}
+@end defmac
-@c =================================================== Obsolete Constructs
+@defmac AC_OUTPUT (@ovar{file}@dots{}, @ovar{extra-cmds}, @ovar{init-cmds})
+@maindex OUTPUT
+The use of @code{AC_OUTPUT} with argument is deprecated, this obsoleted
+interface is equivalent to:
-@node Obsolete Constructs, Environment Variable Index, History, Top
-@chapter Obsolete Constructs
-
-Autoconf changes, and along the years, some constructs are obsoleted.
-Most of the changes involve the macros, but the tools themselves, or
-even some concepts, are now considered obsolete.
-
-You may completely skip this chapter if you are new to Autoconf, it's
-intention is mainly to help maintainers updating their packages by
-understanding how to move to more modern constructs.
-
-@menu
-* Obsolete config.status Use:: Different calling convention
-* acconfig.h:: Additional entries in @file{config.h.in}
-* Obsolete Macros:: Backward compatibility macros
-@end menu
-
-@node Obsolete config.status Use, acconfig.h, Obsolete Constructs, Obsolete Constructs
-@section Obsolete @file{config.status} Invocation
+@example
+@group
+AC_CONFIG_FILES(@var{file}@dots{})
+AC_CONFIG_COMMANDS([default],
+ @var{extra-cmds}, @var{init-cmds})
+AC_OUTPUT
+@end group
+@end example
+@end defmac
-@file{config.status} now supports arguments to specify the files to
-instantiate, see @ref{Invoking config.status}, for more details.
-Before, environment variables had to be used.
+@defmac AC_OUTPUT_COMMANDS (@var{extra-cmds}, @ovar{init-cmds})
+@maindex OUTPUT_COMMANDS
+Specify additional shell commands to run at the end of
+@file{config.status}, and shell commands to initialize any variables
+from @code{configure}. This macro may be called multiple times. It is
+obsolete, replaced by @code{AC_CONFIG_COMMANDS}.
-@defvar CONFIG_COMMANDS
-@evindex CONFIG_COMMANDS
-The tags of the commands to execute. The default is the arguments given
-to @code{AC_OUTPUT} and @code{AC_CONFIG_COMMANDS} in
-@file{configure.in}.
-@end defvar
+Here is an unrealistic example:
-@defvar CONFIG_FILES
-@evindex CONFIG_FILES
-The files in which to perform @samp{@@@var{variable}@@} substitutions.
-The default is the arguments given to @code{AC_OUTPUT} and
-@code{AC_CONFIG_FILES} in @file{configure.in}.
-@end defvar
+@example
+fubar=27
+AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.],
+ fubar=$fubar)
+AC_OUTPUT_COMMANDS([echo this is another, extra, bit],
+ [echo init bit])
+@end example
-@defvar CONFIG_HEADERS
-@evindex CONFIG_HEADERS
-The files in which to substitute C @code{#define} statements. The
-default is the arguments given to @code{AC_CONFIG_HEADERS}; if that
-macro was not called, @file{config.status} ignores this variable.
-@end defvar
+Aside from the fact that @code{AC_CONFIG_COMMANDS} requires an
+additional key, an important difference is that
+@code{AC_OUTPUT_COMMANDS} is quoting its arguments twice, while
+@code{AC_CONFIG_COMMANDS}. This means that @code{AC_CONFIG_COMMANDS}
+can safely be given macro calls as arguments:
-@defvar CONFIG_LINKS
-@evindex CONFIG_LINKS
-The symbolic links to establish. The default is the arguments given to
-@code{AC_CONFIG_LINKS}; if that macro was not called,
-@file{config.status} ignores this variable.
-@end defvar
+@example
+AC_CONFIG_COMMANDS(foo, [my_FOO()])
+@end example
-In @ref{Invoking config.status}, using this old interface, the example
-would be:
+@noindent
+conversely, where one level of quoting was enough for literal strings
+with @code{AC_OUTPUT_COMMANDS}, you need two with
+@code{AC_CONFIG_COMMANDS}. The following lines are equivalent:
@example
@group
-config.h: stamp-h
-stamp-h: config.h.in config.status
- CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_FILES= \
- CONFIG_HEADERS=config.h ./config.status
- echo > stamp-h
-
-Makefile: Makefile.in config.status
- CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_HEADERS= \
- CONFIG_FILES=Makefile ./config.status
+AC_OUTPUT_COMMANDS([echo "Square brackets: []"])
+AC_CONFIG_COMMANDS(default, [[echo "Square brackets: []"]])
@end group
@end example
+@end defmac
-@noindent
-(If @file{configure.in} does not call @code{AC_CONFIG_HEADERS}, there is
-no need to set @code{CONFIG_HEADERS} in the @code{make} rules, equally
-for @code{CONFIG_COMMANDS} etc.)
+@defmac AC_PID_T
+@maindex PID_T
+@code{AC_TYPE_PID_T}
+@end defmac
+@defmac AC_PREFIX
+@maindex PREFIX
+@code{AC_PREFIX_PROGRAM}
+@end defmac
-@node acconfig.h, Obsolete Macros, Obsolete config.status Use, Obsolete Constructs
-@section @file{acconfig.h}
+@defmac AC_PROGRAMS_CHECK
+@maindex PROGRAMS_CHECK
+@code{AC_CHECK_PROGS}
+@end defmac
-@cindex @file{acconfig.h}
-@cindex @file{config.h.top}
-@cindex @file{config.h.bot}
+@defmac AC_PROGRAMS_PATH
+@maindex PROGRAMS_PATH
+@code{AC_PATH_PROGS}
+@end defmac
-@code{autoheader} scans @file{configure.in} and figures out which C
-preprocessor symbols it might define. It copies comments and
-@code{#define} and @code{#undef} statements from a file called
-@file{acconfig.h} in the current directory, if present. This file used
-to be mandatory if you @code{AC_DEFINE} any additional symbols. Now,
-you are encouraged to use the @code{AH} series of macros
-(@pxref{Autoheader Macros}).
+@defmac AC_PROGRAM_CHECK
+@maindex PROGRAM_CHECK
+@code{AC_CHECK_PROG}
+@end defmac
-The file that @code{autoheader} creates contains mainly @code{#define}
-and @code{#undef} statements and their accompanying comments. If
-@file{./acconfig.h} contains the string @samp{@@TOP@@},
-@code{autoheader} copies the lines before the line containing
-@samp{@@TOP@@} into the top of the file that it generates. Similarly,
-if @file{./acconfig.h} contains the string @samp{@@BOTTOM@@},
-@code{autoheader} copies the lines after that line to the end of the
-file it generates. Either or both of those strings may be omitted.
+@defmac AC_PROGRAM_EGREP
+@maindex PROGRAM_EGREP
+@code{AC_EGREP_CPP}
+@end defmac
-An alternate way to produce the same effect is to create the files
-@file{@var{file}.top} (typically @file{config.h.top}) and/or
-@file{@var{file}.bot} in the current directory. If they exist,
-@code{autoheader} copies them to the beginning and end, respectively, of
-its output. Their use is discouraged because they have file names that
-contain two periods, and so cannot be stored on MS-DOS; also, they are
-two more files to clutter up the directory. But if you use the
-@samp{--localdir=@var{dir}} option to use an @file{acconfig.h} in
-another directory, they give you a way to put custom boilerplate in each
-individual @file{config.h.in}.
+@defmac AC_PROGRAM_PATH
+@maindex PROGRAM_PATH
+@code{AC_PATH_PROG}
+@end defmac
+@defmac AC_REMOTE_TAPE
+@maindex REMOTE_TAPE
+removed because of limited usefulness
+@end defmac
-@node Obsolete Macros, , acconfig.h, Obsolete Constructs
-@section Obsolete Macros
+@defmac AC_RESTARTABLE_SYSCALLS
+@maindex RESTARTABLE_SYSCALLS
+@code{AC_SYS_RESTARTABLE_SYSCALLS}
+@end defmac
-Several macros are obsoleted in Autoconf, for various reasons (typically
-they failed to quote properly, couldn't be extended for more recent
-issues etc.). They are still supported, but deprecated: their use
-should be avoided.
+@defmac AC_RETSIGTYPE
+@maindex RETSIGTYPE
+@code{AC_TYPE_SIGNAL}
+@end defmac
-During the jump between Autoconf version 1 and version 2, most of the
-macros were renamed to use a more uniform and descriptive naming scheme,
-but their signature did not change. @xref{Macro Names}, for a
-description of the new naming scheme. Below, there is just the mapping
-from old names to new names for these macros, the reader is invited to
-refer to the definition of the new macro for the signature, and the
-description.
+@defmac AC_RSH
+@maindex RSH
+removed because of limited usefulness
+@end defmac
-@defmac AC_ALLOCA
-@maindex ALLOCA
-@code{AC_FUNC_ALLOCA}
+@defmac AC_SCO_INTL
+@maindex SCO_INTL
+@ovindex LIBS
+If on SCO UNIX, add @samp{-lintl} to output variable @code{LIBS}. This
+macro used to
+
+@example
+AC_CHECK_LIB(intl, strftime, LIBS="-lintl $LIBS")
+@end example
+
+@noindent
+now it just calls @code{AC_FUNC_STRFTIME} instead.
@end defmac
-@defmac AC_ARG_ARRAY
-@maindex ARG_ARRAY
-removed because of limited usefulness
+@defmac AC_SETVBUF_REVERSED
+@maindex SETVBUF_REVERSED
+@code{AC_FUNC_SETVBUF_REVERSED}
@end defmac
-@defmac AC_C_CROSS
-@maindex C_CROSS
-This macro is obsolete; it does nothing.
+@defmac AC_SET_MAKE
+@maindex SET_MAKE
+@code{AC_PROG_MAKE_SET}
@end defmac
-@defmac AC_CANONICAL_SYSTEM
-@maindex CANONICAL_SYSTEM
-Determine the system type and set output variables to the names of the
-canonical system types. @xref{System Type Variables}, for details about
-the variables this macro sets.
+@defmac AC_SIZEOF_TYPE
+@maindex SIZEOF_TYPE
+@code{AC_CHECK_SIZEOF}
+@end defmac
-The user is encouraged to explicitly use either
-@code{AC_CANONICAL_BUILD}, or @code{AC_CANONICAL_HOST}, or
-@code{AC_CANONICAL_TARGET}, depending on her needs. Using
-@code{AC_CANONICAL_TARGET} is enough to run the three macros.
+@defmac AC_SIZE_T
+@maindex SIZE_T
+@code{AC_TYPE_SIZE_T}
@end defmac
-@defmac AC_CHAR_UNSIGNED
-@maindex CHAR_UNSIGNED
-@code{AC_C_CHAR_UNSIGNED}
+@defmac AC_STAT_MACROS_BROKEN
+@maindex STAT_MACROS_BROKEN
+@code{AC_HEADER_STAT}
@end defmac
-@defmac AC_CHECK_TYPE (@var{type}, @var{default})
-@maindex CHECK_TYPE
-Autoconf, up to 2.13, used to provide to this version of
-@code{AC_CHECK_TYPE}, broken by design. First, although it is a member
-of the @code{CHECK} clan, singular sub-family, it does more than just
-checking. Second, missing types are not typedef'd, they are defined,
-which can lead to incompatible code in the case of pointer types.
+@defmac AC_STDC_HEADERS
+@maindex STDC_HEADERS
+@code{AC_HEADER_STDC}
+@end defmac
-This use of @code{AC_CHECK_TYPE} is obsolete and discouraged, see
-@ref{Generic Types}, for the description of the current macro.
+@defmac AC_STRCOLL
+@maindex STRCOLL
+@code{AC_FUNC_STRCOLL}
+@end defmac
-If the type @var{type} is not defined, define it to be the C (or C++)
-builtin type @var{default}; e.g., @samp{short} or @samp{unsigned}.
+@defmac AC_ST_BLKSIZE
+@maindex ST_BLKSIZE
+@code{AC_STRUCT_ST_BLKSIZE}
+@end defmac
-This macro is equivalent to
-@example
-AC_CHECK_TYPE([@var{type}],
- [AC_DEFINE([@var{type}], [@var{default}],
- [Define to `@var{default}' if <sys/types.h>
- does not define.])])
-@end example
-In order to keep backward compatibility, the two versions of
-@code{AC_CHECK_TYPE} are implemented, selected by a simple heuristics:
-@itemize @bullet
-@item
-if there are three or four arguments, the modern version is used;
-
-@item
-if the second argument is a C or C++ @strong{builtin} type, then the
-obsolete version is used;
-
-@item
-if the second argument is spelled with the alphabet of valid C and C++
-types, the user is warned and the modern version is used;
-
-@item
-otherwise, the modern version is used.
-@end itemize
-
-@noindent
-In particular, the following code, which was invalid but functional:
-
-@example
-AC_CHECK_TYPE(loff_t, off_t)
-@end example
-
-@noindent
-will be improperly branched to the modern implementation. You are
-encouraged either to use a valid builtin type, or to use the equivalent
-modern code (see above), or better yet, to use @code{AC_CHECK_TYPES}
-together with
-
-@example
-#if !HAVE_LOFF_T
-typedef loff_t off_t;
-#endif
-@end example
+@defmac AC_ST_BLOCKS
+@maindex ST_BLOCKS
+@code{AC_STRUCT_ST_BLOCKS}
@end defmac
-@c end of AC_CHECK_TYPE
-
-@defmac AC_CHECKING (@var{feature-description})
-@maindex CHECKING
-This macro is similar to @code{AC_MSG_CHECKING}, except that it prints a
-newline after the @var{feature-description}. It is useful mainly to
-print a general description of the overall purpose of a group of feature
-checks, e.g.,
-@example
-AC_CHECKING(if stack overflow is detectable)
-@end example
+@defmac AC_ST_RDEV
+@maindex ST_RDEV
+@code{AC_STRUCT_ST_RDEV}
@end defmac
-@defmac AC_COMPILE_CHECK (@var{echo-text}, @var{includes}, @var{function-body}, @var{action-if-found}, @ovar{action-if-not-found})
-@maindex COMPILE_CHECK
-This is an obsolete version of @code{AC_TRY_LINK} (@pxref{Examining
-Libraries}), with the addition that it prints @samp{checking for
-@var{echo-text}} to the standard output first, if @var{echo-text} is
-non-empty. Use @code{AC_MSG_CHECKING} and @code{AC_MSG_RESULT} instead
-to print messages (@pxref{Printing Messages}).
+@defmac AC_SYS_SIGLIST_DECLARED
+@maindex SYS_SIGLIST_DECLARED
+@code{AC_DECL_SYS_SIGLIST}
@end defmac
-@defmac AC_CONST
-@maindex CONST
-@code{AC_C_CONST}
+@defmac AC_TEST_CPP
+@maindex TEST_CPP
+@code{AC_TRY_CPP}
@end defmac
-@defmac AC_CROSS_CHECK
-@maindex CROSS_CHECK
-@code{AC_C_CROSS}
+@defmac AC_TEST_PROGRAM
+@maindex TEST_PROGRAM
+@code{AC_TRY_RUN}
@end defmac
-@defmac AC_CYGWIN
-@maindex CYGWIN
-Checked for the Cygwin environment in which case the shell variable
-@code{CYGWIN} is set to @samp{yes}. @code{AC_EXEEXT} now handles this
-task.
+@defmac AC_TIMEZONE
+@maindex TIMEZONE
+@code{AC_STRUCT_TIMEZONE}
@end defmac
-@defmac AC_DECL_YYTEXT
-Does nothing, now integrated in @code{AC_PROG_LEX}.
+@defmac AC_TIME_WITH_SYS_TIME
+@maindex TIME_WITH_SYS_TIME
+@code{AC_HEADER_TIME}
@end defmac
-@defmac AC_DYNIX_SEQ
-@maindex DYNIX_SEQ
-If on Dynix/PTX (Sequent @sc{unix}), add @samp{-lseq} to output variable
-@code{LIBS}. This macro used to be defined as
-
-@example
-AC_CHECK_LIB(seq, getmntent, LIBS="-lseq $LIBS")
-@end example
-
-@noindent
-now it is just @code{AC_FUNC_GETMNTENT}.
+@defmac AC_UID_T
+@maindex UID_T
+@code{AC_TYPE_UID_T}
@end defmac
-@defmac AC_EXEEXT
-@maindex EXEEXT
-@ovindex EXEEXT
-@ovindex CYGWIN
-@ovindex EMXOS2
-@ovindex MINGW32
-Defined the output variable @code{EXEEXT} based on the output of the
-compiler, after @samp{.$ac_ext} (i.e. source files of the current
-language), @samp{.o}, @samp{.obj} and @samp{.xcoff} files have been
-excluded. Typically set to empty string if Unix and @samp{.exe} if
-Win32 or OS/2.
-
-This macro sets the shell variable @code{CYGWIN} to @samp{yes} if run in
-the Cygwin environment, @code{EMXOS2} to @samp{yes} if in the EMX
-environment on OS/2, and @code{MINGW32} to @samp{yes} with the MingW32
-compiler.
-
-Now handled by the macros checking for the compiler.
+@defmac AC_UTIME_NULL
+@maindex UTIME_NULL
+@code{AC_FUNC_UTIME_NULL}
@end defmac
-@defmac AC_EMXOS2
-@maindex EMXOS2
-Checks for the EMX environment on OS/2in which case the shell variable
-@code{EMXOS2} is set to @samp{yes}. @code{AC_EXEEXT} now handles this
-task.
+@defmac AC_VERBOSE (@var{result-description})
+@maindex VERBOSE
+This macro is similar to @code{AC_MSG_RESULT}, except that it is meant
+to follow a call to @code{AC_CHECKING} instead of
+@code{AC_MSG_CHECKING}; it starts the message it prints with a tab. It
+is considered obsolete.
@end defmac
-@defmac AC_ERROR
-@maindex ERROR
-@code{AC_MSG_ERROR}
+@defmac AC_VFORK
+@maindex VFORK
+@code{AC_FUNC_VFORK}
@end defmac
-@defmac AC_FIND_X
-@maindex FIND_X
-@code{AC_PATH_X}
+@defmac AC_VPRINTF
+@maindex VPRINTF
+@code{AC_FUNC_VPRINTF}
@end defmac
-@defmac AC_FIND_XTRA
-@maindex FIND_XTRA
-@code{AC_PATH_XTRA}
+@defmac AC_WAIT3
+@maindex WAIT3
+@code{AC_FUNC_WAIT3}
@end defmac
-@defmac AC_FUNC_CHECK
-@maindex FUNC_CHECK
-@code{AC_CHECK_FUNC}
+@defmac AC_WARN
+@maindex WARN
+@code{AC_MSG_WARN}
@end defmac
-@defmac AC_GCC_TRADITIONAL
-@maindex GCC_TRADITIONAL
-@code{AC_PROG_GCC_TRADITIONAL}
+@defmac AC_WORDS_BIGENDIAN
+@maindex WORDS_BIGENDIAN
+@code{AC_C_BIGENDIAN}
@end defmac
-@defmac AC_GETGROUPS_T
-@maindex GETGROUPS_T
-@code{AC_TYPE_GETGROUPS}
-@end defmac
+@defmac AC_XENIX_DIR
+@maindex XENIX_DIR
+@ovindex LIBS
+This macro used to add @samp{-lx} to output variable @code{LIBS} if on
+Xenix. Also, if @file{dirent.h} is being checked for, added
+@samp{-ldir} to @code{LIBS}. Now it is merely an alias of
+@code{AC_HEADER_DIRENT} instead, plus some code to detect whether
+running @sc{xenix} on which you should not depend:
-@defmac AC_GETLOADAVG
-@maindex GETLOADAVG
-@code{AC_FUNC_GETLOADAVG}
+@example
+AC_MSG_CHECKING(for Xenix)
+AC_EGREP_CPP(yes,
+[#if defined(M_XENIX) && !defined(M_UNIX)
+ yes
+#endif],
+ [AC_MSG_RESULT(yes); XENIX=yes],
+ [AC_MSG_RESULT(no); XENIX=])
+@end example
@end defmac
-@defmac AC_HAVE_FUNCS
-@maindex HAVE_FUNCS
-@code{AC_CHECK_FUNCS}
+@defmac AC_YYTEXT_POINTER
+@maindex YYTEXT_POINTER
+@code{AC_DECL_YYTEXT}
@end defmac
-@defmac AC_HAVE_HEADERS
-@maindex HAVE_HEADERS
-@code{AC_CHECK_HEADERS}
-@end defmac
+@node Autoconf 1, , Obsolete Macros, Obsolete Constructs
+@section Upgrading From Version 1
-@defmac AC_HAVE_LIBRARY (@var{library}, @ovar{action-if-found}, @ovar{action-if-not-found}, @ovar{other-libraries})
-@maindex HAVE_LIBRARY
-This macro is equivalent to calling @code{AC_CHECK_LIB} with a
-@var{function} argument of @code{main}. In addition, @var{library} can
-be written as any of @samp{foo}, @samp{-lfoo}, or @samp{libfoo.a}. In
-all of those cases, the compiler is passed @samp{-lfoo}. However,
-@var{library} cannot be a shell variable; it must be a literal name.
-@end defmac
+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 @file{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
+@code{configure} scripts could benefit from some of the new features in
+version 2; the changes are summarized in the file @file{NEWS} in the
+Autoconf distribution.
-@defmac AC_HAVE_POUNDBANG
-@maindex HAVE_POUNDBANG
-@code{AC_SYS_INTERPRETER} (different calling convention)
-@end defmac
+@menu
+* Changed File Names:: Files you might rename
+* Changed Makefiles:: New things to put in @file{Makefile.in}
+* Changed Macros:: Macro calls you might replace
+* Changed Results:: Changes in how to check test results
+* Changed Macro Writing:: Better ways to write your own macros
+@end menu
-@defmac AC_HEADER_CHECK
-@maindex HEADER_CHECK
-@code{AC_CHECK_HEADER}
-@end defmac
+@node Changed File Names, Changed Makefiles, Autoconf 1, Autoconf 1
+@subsection Changed File Names
-@defmac AC_HEADER_EGREP
-@maindex HEADER_EGREP
-@code{AC_EGREP_HEADER}
-@end defmac
+If you have an @file{aclocal.m4} installed with Autoconf (as opposed to
+in a particular package's source directory), you must rename it to
+@file{acsite.m4}. @xref{Invoking autoconf}.
-@defmac AC_INIT (@var{unique-file-in-source-dir})
-@maindex INIT
-Formerly @code{AC_INIT} used to have a single argument, and was
-equivalent to:
+If you distribute @file{install.sh} with your package, rename it to
+@file{install-sh} so @code{make} builtin rules won't inadvertently
+create a file called @file{install} from it. @code{AC_PROG_INSTALL}
+looks for the script under both names, but it is best to use the new name.
-@example
-AC_INIT
-AC_CONFIG_SRCDIR(@var{unique-file-in-source-dir})
-@end example
-@end defmac
+If you were using @file{config.h.top} or @file{config.h.bot}, you still
+can, but you will have less clutter if you merge them into
+@file{acconfig.h}. @xref{Invoking autoheader}.
-@defmac AC_INLINE
-@maindex INLINE
-@code{AC_C_INLINE}
-@end defmac
+@node Changed Makefiles, Changed Macros, Changed File Names, Autoconf 1
+@subsection Changed Makefiles
-@defmac AC_IRIX_SUN
-@maindex IRIX_SUN
-If on IRIX (Silicon Graphics @sc{unix}), add @samp{-lsun} to output
-@code{LIBS}. If you were using it to get @code{getmntent}, use
-@code{AC_FUNC_GETMNTENT} instead. If you used it for the NIS versions
-of the password and group functions, use @samp{AC_CHECK_LIB(sun,
-getpwnam)}. Up to Autoconf 2.13, it used to be
+Add @samp{@@CFLAGS@@}, @samp{@@CPPFLAGS@@}, and @samp{@@LDFLAGS@@} in
+your @file{Makefile.in} files, so they can take advantage of the values
+of those variables in the environment when @code{configure} is run.
+Doing this isn't necessary, but it's a convenience for users.
+
+Also add @samp{@@configure_input@@} in a comment to each input file for
+@code{AC_OUTPUT}, so that the output files will contain a comment saying
+they were produced by @code{configure}. Automatically selecting the
+right comment syntax for all the kinds of files that people call
+@code{AC_OUTPUT} on became too much work.
+
+Add @file{config.log} and @file{config.cache} to the list of files you
+remove in @code{distclean} targets.
+
+If you have the following in @file{Makefile.in}:
@example
-AC_CHECK_LIB(sun, getmntent, LIBS="-lsun $LIBS")
+prefix = /usr/local
+exec_prefix = $(prefix)
@end example
@noindent
-now it is defined as
+you must change it to:
@example
-AC_FUNC_GETMNTENT
-AC_CHECK_LIB(sun, getpwnam)
+prefix = @@prefix@@
+exec_prefix = @@exec_prefix@@
@end example
-@end defmac
-@defmac AC_LANG_C
-@maindex LANG_C
-Same as @samp{AC_LANG(C)}.
-@end defmac
+@noindent
+The old behavior of replacing those variables without @samp{@@}
+characters around them has been removed.
-@defmac AC_LANG_CPLUSPLUS
-@maindex LANG_CPLUSPLUS
-Same as @samp{AC_LANG(C++)}.
-@end defmac
+@node Changed Macros, Changed Results, Changed Makefiles, Autoconf 1
+@subsection Changed Macros
-@defmac AC_LANG_FORTRAN77
-@maindex LANG_FORTRAN77
-Same as @samp{AC_LANG(Fortran 77)}.
-@end defmac
+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. @xref{Obsolete Macros}, for a table showing the
+new names for the old macros. Use the @code{autoupdate} program to
+convert your @file{configure.in} to using the new macro names.
+@xref{Invoking autoupdate}.
-@defmac AC_LANG_RESTORE
-@maindex LANG_RESTORE
-Select the @var{language} that is saved on the top of the stack, as set
-by @code{AC_LANG_SAVE}, remove it from the stack, and call
-@code{AC_LANG(@var{language})}.
-@end defmac
+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 @code{autoconf}, you may safely ignore them, but
+your @code{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 @code{echo} or @code{AC_VERBOSE} (perhaps
+via @code{AC_COMPILE_CHECK}), your @code{configure} script's output will
+look better if you switch to @code{AC_MSG_CHECKING} and
+@code{AC_MSG_RESULT}. @xref{Printing Messages}. Those macros work best
+in conjunction with cache variables. @xref{Caching Results}.
-@defmac AC_LANG_SAVE
-@maindex LANG_SAVE
-Remember the current language (as set by @code{AC_LANG}) on a stack.
-Doe not change which language is current. @code{AC_LANG_PUSH} is
-preferred.
-@end defmac
-@defmac AC_LINK_FILES (@var{source}@dots{}, @var{dest}@dots{})
-@maindex LINK_FILES
-This is an obsolete version of @code{AC_CONFIG_LINKS}. An updated
-version of:
+
+@node Changed Results, Changed Macro Writing, Changed Macros, Autoconf 1
+@subsection Changed Results
+
+If you were checking the results of previous tests by examining the
+shell variable @code{DEFS}, you need to switch to checking the values of
+the cache variables for those tests. @code{DEFS} no longer exists while
+@code{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 @code{AC_DEFINE} is called. @xref{Cache
+Variable Names}.
+
+For example, here is a @file{configure.in} fragment written for Autoconf
+version 1:
@example
-AC_LINK_FILES(config/$machine.h config/$obj_format.h,
- host.h object.h)
+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
@end example
-@noindent
-is:
+Here is a way to write it for version 2:
@example
-AC_CONFIG_LINKS(host.h:config/$machine.h
- object.h:config/$obj_format.h)
+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 -l$lib"; break])
+ done
+fi
@end example
-@end defmac
-@defmac AC_LN_S
-@maindex LN_S
-@code{AC_PROG_LN_S}
-@end defmac
+If you were working around bugs in @code{AC_DEFINE_UNQUOTED} by adding
+backslashes before quotes, you need to remove them. It now works
+predictably, and does not treat quotes (except back quotes) specially.
+@xref{Setting Output Variables}.
-@defmac AC_LONG_DOUBLE
-@maindex LONG_DOUBLE
-@code{AC_C_LONG_DOUBLE}
-@end defmac
+All of the boolean shell variables set by Autoconf macros now use
+@samp{yes} for the true value. Most of them use @samp{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
+@samp{t} for true, you need to change your tests.
-@defmac AC_LONG_FILE_NAMES
-@maindex LONG_FILE_NAMES
-@code{AC_SYS_LONG_FILE_NAMES}
-@end defmac
+@node Changed Macro Writing, , Changed Results, Autoconf 1
+@subsection Changed Macro Writing
-@defmac AC_MAJOR_HEADER
-@maindex MAJOR_HEADER
-@code{AC_HEADER_MAJOR}
-@end defmac
+When defining your own macros, you should now use @code{AC_DEFUN}
+instead of @code{define}. @code{AC_DEFUN} automatically calls
+@code{AC_PROVIDE} and ensures that macros called via @code{AC_REQUIRE}
+do not interrupt other macros, to prevent nested @samp{checking@dots{}}
+messages on the screen. There's no actual harm in continuing to use the
+older way, but it's less convenient and attractive. @xref{Macro
+Definitions}.
-@defmac AC_MINGW32
-@maindex MINGW32
-Checked for the MingW32 compiler environment, in which case the shell
-variable @code{MINGW32} is set to @samp{yes}. @code{AC_EXEEXT} now
-handles this task.
-@end defmac
+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.
-@defmac AC_MINUS_C_MINUS_O
-@maindex MINUS_C_MINUS_O
-@code{AC_PROG_CC_C_O}
-@end defmac
+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.
-@defmac AC_MMAP
-@maindex MMAP
-@code{AC_FUNC_MMAP}
-@end defmac
+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.
-@defmac AC_MODE_T
-@maindex MODE_T
-@code{AC_TYPE_MODE_T}
-@end defmac
-@defmac AC_OBJEXT
-@maindex OBJEXT
-@ovindex OBJEXT
-Defined the output variable @code{OBJEXT} based on the output of the
-compiler, after .c files have been excluded. Typically set to @samp{o}
-if Unix, @samp{obj} if Win32. Now the compiler checking macros handle
-this.
-@end defmac
+@c ================================================ Questions About Autoconf.
-@defmac AC_OBSOLETE (@var{this-macro-name}, @ovar{suggestion})
-@maindex OBSOLETE
-Make @code{m4} print a message on the standard error output warning that
-@var{this-macro-name} is obsolete, and giving the file and line number
-where it was called. @var{this-macro-name} should be the name of the
-macro that is calling @code{AC_OBSOLETE}. If @var{suggestion} is given,
-it is printed at the end of the warning message; for example, it can be
-a suggestion for what to use instead of @var{this-macro-name}.
+@node Questions, History, Obsolete Constructs, Top
+@chapter Questions About Autoconf
-For instance
+Several questions about Autoconf come up occasionally. Here some of them
+are addressed.
-@example
-AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl
-@end example
+@menu
+* Distributing:: Distributing @code{configure} scripts
+* Why GNU m4:: Why not use the standard @code{m4}?
+* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Why Not Imake:: Why GNU uses @code{configure} instead of Imake
+@end menu
-You are encouraged to use @code{AU_DEFUN} instead, since it gives better
-services to the user.
-@end defmac
+@node Distributing, Why GNU m4, Questions, Questions
+@section Distributing @code{configure} Scripts
-@defmac AC_OFF_T
-@maindex OFF_T
-@code{AC_TYPE_OFF_T}
-@end defmac
+@display
+What are the restrictions on distributing @code{configure}
+scripts that Autoconf generates? How does that affect my
+programs that use them?
+@end display
-@defmac AC_OUTPUT (@ovar{file}@dots{}, @ovar{extra-cmds}, @ovar{init-cmds})
-@maindex OUTPUT
-The use of @code{AC_OUTPUT} with argument is deprecated, this obsoleted
-interface is equivalent to:
+There are no restrictions on how the configuration scripts that Autoconf
+produces may be distributed or used. In Autoconf version 1, they were
+covered by the @sc{gnu} General Public License. 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.
-@example
-@group
-AC_CONFIG_FILES(@var{file}@dots{})
-AC_CONFIG_COMMANDS([default],
- @var{extra-cmds}, @var{init-cmds})
-AC_OUTPUT
-@end group
-@end example
-@end defmac
+Of the other files that might be used with @code{configure},
+@file{config.h.in} is under whatever copyright you use for your
+@file{configure.in}, since it is derived from that file and from the
+public domain file @file{acconfig.h}. @file{config.sub} and
+@file{config.guess} have an exception to the GPL when they are used with
+an Autoconf-generated @code{configure} script, which permits you to
+distribute them under the same terms as the rest of your package.
+@file{install-sh} is from the X Consortium and is not copyrighted.
-@defmac AC_OUTPUT_COMMANDS (@var{extra-cmds}, @ovar{init-cmds})
-@maindex OUTPUT_COMMANDS
-Specify additional shell commands to run at the end of
-@file{config.status}, and shell commands to initialize any variables
-from @code{configure}. This macro may be called multiple times. It is
-obsolete, replaced by @code{AC_CONFIG_COMMANDS}.
+@node Why GNU m4, Bootstrapping, Distributing, Questions
+@section Why Require @sc{gnu} @code{m4}?
-Here is an unrealistic example:
+@display
+Why does Autoconf require @sc{gnu} @code{m4}?
+@end display
+
+Many @code{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:
@example
-fubar=27
-AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.],
- fubar=$fubar)
-AC_OUTPUT_COMMANDS([echo this is another, extra, bit],
- [echo init bit])
+builtin
+indir
+patsubst
+__file__
+__line__
@end example
-Aside from the fact that @code{AC_CONFIG_COMMANDS} requires an
-additional key, an important difference is that
-@code{AC_OUTPUT_COMMANDS} is quoting its arguments twice, while
-@code{AC_CONFIG_COMMANDS}. This means that @code{AC_CONFIG_COMMANDS}
-can safely be given macro calls as arguments:
+Autoconf requires version 1.4 or above of @sc{gnu} @code{m4} because it
+uses frozen state files.
-@example
-AC_CONFIG_COMMANDS(foo, [my_FOO()])
-@end example
+Since only software maintainers need to use Autoconf, and since @sc{gnu}
+@code{m4} is simple to configure and install, it seems reasonable to
+require @sc{gnu} @code{m4} to be installed also. Many maintainers of
+@sc{gnu} and other free software already have most of the @sc{gnu}
+utilities installed, since they prefer them.
-@noindent
-conversely, where one level of quoting was enough for literal strings
-with @code{AC_OUTPUT_COMMANDS}, you need two with
-@code{AC_CONFIG_COMMANDS}. The following lines are equivalent:
+@node Bootstrapping, Why Not Imake, Why GNU m4, Questions
+@section How Can I Bootstrap?
-@example
-@group
-AC_OUTPUT_COMMANDS([echo "Square brackets: []"])
-AC_CONFIG_COMMANDS(default, [[echo "Square brackets: []"]])
-@end group
-@end example
-@end defmac
+@display
+If Autoconf requires @sc{gnu} @code{m4} and @sc{gnu} @code{m4} has an
+Autoconf @code{configure} script, how do I bootstrap? It seems like a
+chicken and egg problem!
+@end display
-@defmac AC_PID_T
-@maindex PID_T
-@code{AC_TYPE_PID_T}
-@end defmac
+This is a misunderstanding. Although @sc{gnu} @code{m4} does come with
+a @code{configure} script produced by Autoconf, Autoconf is not required
+in order to run the script and install @sc{gnu} @code{m4}. Autoconf is
+only required if you want to change the @code{m4} @code{configure}
+script, which few people have to do (mainly its maintainer).
-@defmac AC_PREFIX
-@maindex PREFIX
-@code{AC_PREFIX_PROGRAM}
-@end defmac
+@node Why Not Imake, , Bootstrapping, Questions
+@section Why Not Imake?
-@defmac AC_PROGRAMS_CHECK
-@maindex PROGRAMS_CHECK
-@code{AC_CHECK_PROGS}
-@end defmac
+@display
+Why not use Imake instead of @code{configure} scripts?
+@end display
-@defmac AC_PROGRAMS_PATH
-@maindex PROGRAMS_PATH
-@code{AC_PATH_PROGS}
-@end defmac
+Several people have written addressing this question, so I include
+adaptations of their explanations here.
-@defmac AC_PROGRAM_CHECK
-@maindex PROGRAM_CHECK
-@code{AC_CHECK_PROG}
-@end defmac
+The following answer is based on one written by Richard Pixley:
-@defmac AC_PROGRAM_EGREP
-@maindex PROGRAM_EGREP
-@code{AC_EGREP_CPP}
-@end defmac
+@quotation
+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.
-@defmac AC_PROGRAM_PATH
-@maindex PROGRAM_PATH
-@code{AC_PATH_PROG}
-@end defmac
+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.
-@defmac AC_REMOTE_TAPE
-@maindex REMOTE_TAPE
-removed because of limited usefulness
-@end defmac
+@sc{gnu} tools are not released this way. Each @sc{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.
-@defmac AC_RESTARTABLE_SYSCALLS
-@maindex RESTARTABLE_SYSCALLS
-@code{AC_SYS_RESTARTABLE_SYSCALLS}
-@end defmac
+If you view the @sc{gnu} suite as a collection of native tools, then the
+problems are similar. But the @sc{gnu} 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.
-@defmac AC_RETSIGTYPE
-@maindex RETSIGTYPE
-@code{AC_TYPE_SIGNAL}
-@end defmac
+Imake templates are a form of standardization. The @sc{gnu} coding
+standards address the same issues without necessarily imposing the same
+restrictions.
+@end quotation
-@defmac AC_RSH
-@maindex RSH
-removed because of limited usefulness
-@end defmac
-@defmac AC_SCO_INTL
-@maindex SCO_INTL
-@ovindex LIBS
-If on SCO UNIX, add @samp{-lintl} to output variable @code{LIBS}. This
-macro used to
+Here is some further explanation, written by Per Bothner:
-@example
-AC_CHECK_LIB(intl, strftime, LIBS="-lintl $LIBS")
-@end example
+@quotation
+One of the advantages of Imake is that it easy to generate large
+Makefiles using @code{cpp}'s @samp{#include} and macro mechanisms.
+However, @code{cpp} is not programmable: it has limited conditional
+facilities, and no looping. And @code{cpp} cannot inspect its
+environment.
-@noindent
-now it just calls @code{AC_FUNC_STRFTIME} instead.
-@end defmac
+All of these problems are solved by using @code{sh} instead of
+@code{cpp}. The shell is fully programmable, has macro substitution,
+can execute (or source) other shell scripts, and can inspect its
+environment.
+@end quotation
-@defmac AC_SETVBUF_REVERSED
-@maindex SETVBUF_REVERSED
-@code{AC_FUNC_SETVBUF_REVERSED}
-@end defmac
-@defmac AC_SET_MAKE
-@maindex SET_MAKE
-@code{AC_PROG_MAKE_SET}
-@end defmac
+Paul Eggert elaborates more:
-@defmac AC_SIZEOF_TYPE
-@maindex SIZEOF_TYPE
-@code{AC_CHECK_SIZEOF}
-@end defmac
+@quotation
+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
+supported by the host. These problems are much rarer with Autoconf,
+where each package comes with its own independent configuration
+processor.
-@defmac AC_SIZE_T
-@maindex SIZE_T
-@code{AC_TYPE_SIZE_T}
-@end defmac
+Also, Imake often suffers from unexpected interactions between
+@code{make} and the installer's C preprocessor. The fundamental problem
+here is that the C preprocessor was designed to preprocess C programs,
+not @file{Makefile}s. This is much less of a problem with Autoconf,
+which uses the general-purpose preprocessor @code{m4}, and where the
+package's author (rather than the installer) does the preprocessing in a
+standard way.
+@end quotation
-@defmac AC_STAT_MACROS_BROKEN
-@maindex STAT_MACROS_BROKEN
-@code{AC_HEADER_STAT}
-@end defmac
-@defmac AC_STDC_HEADERS
-@maindex STDC_HEADERS
-@code{AC_HEADER_STDC}
-@end defmac
+Finally, Mark Eichin notes:
-@defmac AC_STRCOLL
-@maindex STRCOLL
-@code{AC_FUNC_STRCOLL}
-@end defmac
+@quotation
+Imake isn't all that extensible, either. In order to add new features to
+Imake, you need to provide your 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).
-@defmac AC_ST_BLKSIZE
-@maindex ST_BLKSIZE
-@code{AC_STRUCT_ST_BLKSIZE}
-@end defmac
+On the other side, though:
-@defmac AC_ST_BLOCKS
-@maindex ST_BLOCKS
-@code{AC_STRUCT_ST_BLOCKS}
-@end defmac
+The one advantage that Imake has over @code{configure}:
+@file{Imakefile}s tend to be much shorter (likewise, less redundant)
+than @file{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
+@file{post.in} and @file{pre.in} @file{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 @code{configure} setups.
+@end quotation
-@defmac AC_ST_RDEV
-@maindex ST_RDEV
-@code{AC_STRUCT_ST_RDEV}
-@end defmac
-@defmac AC_SYS_SIGLIST_DECLARED
-@maindex SYS_SIGLIST_DECLARED
-@code{AC_DECL_SYS_SIGLIST}
-@end defmac
-@defmac AC_TEST_CPP
-@maindex TEST_CPP
-@code{AC_TRY_CPP}
-@end defmac
-@defmac AC_TEST_PROGRAM
-@maindex TEST_PROGRAM
-@code{AC_TRY_RUN}
-@end defmac
+@c ===================================================== History of Autoconf.
-@defmac AC_TIMEZONE
-@maindex TIMEZONE
-@code{AC_STRUCT_TIMEZONE}
-@end defmac
+@node History, Environment Variable Index, Questions, Top
+@chapter History of Autoconf
-@defmac AC_TIME_WITH_SYS_TIME
-@maindex TIME_WITH_SYS_TIME
-@code{AC_HEADER_TIME}
-@end defmac
+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 @emph{are} wondering,
+then let there be light@dots{}
-@defmac AC_UID_T
-@maindex UID_T
-@code{AC_TYPE_UID_T}
-@end defmac
+@menu
+* Genesis:: Prehistory and naming of @code{configure}
+* Exodus:: The plagues of @code{m4} and Perl
+* Leviticus:: The priestly code of portability arrives
+* Numbers:: Growth and contributors
+* Deuteronomy:: Approaching the promises of easy configuration
+@end menu
-@defmac AC_UTIME_NULL
-@maindex UTIME_NULL
-@code{AC_FUNC_UTIME_NULL}
-@end defmac
+@node Genesis, Exodus, History, History
+@section Genesis
-@defmac AC_VERBOSE (@var{result-description})
-@maindex VERBOSE
-This macro is similar to @code{AC_MSG_RESULT}, except that it is meant
-to follow a call to @code{AC_CHECKING} instead of
-@code{AC_MSG_CHECKING}; it starts the message it prints with a tab. It
-is considered obsolete.
-@end defmac
+In June 1991 I was maintaining many of the @sc{gnu} utilities for the
+Free Software Foundation. As they were ported to more platforms and
+more programs were added, the number of @samp{-D} options that users had
+to select in the @file{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 @code{configure} script worked well enough that
+the next month I adapted it (by hand) to create similar @code{configure}
+scripts for several other @sc{gnu} utilities packages. Brian Berliner
+also adapted one of my scripts for his CVS revision control system.
-@defmac AC_VFORK
-@maindex VFORK
-@code{AC_FUNC_VFORK}
-@end defmac
+Later that summer, I learned that Richard Stallman and Richard Pixley
+were developing similar scripts to use in the @sc{gnu} compiler tools;
+so I adapted my @code{configure} scripts to support their evolving
+interface: using the file name @file{Makefile.in} as the templates;
+adding @samp{+srcdir}, the first option (of many); and creating
+@file{config.status} files.
-@defmac AC_VPRINTF
-@maindex VPRINTF
-@code{AC_FUNC_VPRINTF}
-@end defmac
+@node Exodus, Leviticus, Genesis, History
+@section Exodus
-@defmac AC_WAIT3
-@maindex WAIT3
-@code{AC_FUNC_WAIT3}
-@end defmac
+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 @sc{gnu} utilities packages to use
+@code{configure} scripts, updating them all by hand became impractical.
+Rich Murphey, the maintainer of the @sc{gnu} graphics utilities, sent me
+mail saying that the @code{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 @code{configure} scripts to the
+abundance and ease of Autoconf began.
-@defmac AC_WARN
-@maindex WARN
-@code{AC_MSG_WARN}
-@end defmac
+Cygnus @code{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.
-@defmac AC_WORDS_BIGENDIAN
-@maindex WORDS_BIGENDIAN
-@code{AC_C_BIGENDIAN}
-@end defmac
+I considered using an architecture similar to that of Cygnus
+@code{configure}, where there is a single @code{configure} script that
+reads pieces of @file{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 @code{configure} made from each
+@file{configure.in} by a preprocessor. That approach also offered more
+control and flexibility.
-@defmac AC_XENIX_DIR
-@maindex XENIX_DIR
-@ovindex LIBS
-This macro used to add @samp{-lx} to output variable @code{LIBS} if on
-Xenix. Also, if @file{dirent.h} is being checked for, added
-@samp{-ldir} to @code{LIBS}. Now it is merely an alias of
-@code{AC_HEADER_DIRENT} instead, plus some code to detect whether
-running @sc{xenix} on which you should not depend:
+I looked briefly into using the Metaconfig package, by Larry Wall,
+Harlan Stenn, and Raphael Manfredi, but I decided not to for several
+reasons. The @code{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); I didn't know that it was
+still being maintained, and the @code{Configure} scripts I had
+seen 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).
-@example
-AC_MSG_CHECKING(for Xenix)
-AC_EGREP_CPP(yes,
-[#if defined(M_XENIX) && !defined(M_UNIX)
- yes
-#endif],
- [AC_MSG_RESULT(yes); XENIX=yes],
- [AC_MSG_RESULT(no); XENIX=])
-@end example
-@end defmac
+I considered using Perl to generate my style of @code{configure}
+scripts, but decided that @code{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 @sc{gnu} extensions to @code{m4}.) Also, some of my friends at the
+University of Maryland had recently been putting @code{m4} front ends on
+several programs, including @code{tvtwm}, and I was interested in trying
+out a new language.
+
+@node Leviticus, Numbers, Exodus, History
+@section Leviticus
+
+Since my @code{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 @sc{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 @code{m4}
+macros and continued to add features and improve the techniques used in
+the checks. Prominent among the testers were
+@ifinfo
+Franc,ois
+@end ifinfo
+@tex
+Fran\c cois
+@end tex
+Pinard, who came up with the idea of making an @file{autoconf} shell
+script to run @code{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 @samp{-D} options
+in a @file{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.
+
+@node Numbers, Deuteronomy, Leviticus, History
+@section Numbers
+
+In July 1992, after months of alpha testing, I released Autoconf 1.0,
+and converted many @sc{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 @sc{gnu} Project (such as TCL, FSP, and Kerberos V5).
+Autoconf continued to improve rapidly, as many people using the
+@code{configure} scripts reported problems they encountered.
+
+Autoconf turned out to be a good torture test for @code{m4}
+implementations. @sc{unix} @code{m4} started to dump core because of
+the length of the macros that Autoconf defined, and several bugs showed
+up in @sc{gnu} @code{m4} as well. Eventually, we realized that we
+needed to use some features that only @sc{gnu} @code{m4} has.
+4.3@sc{bsd} @code{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.
+@ifinfo
+Franc,ois
+@end ifinfo
+@tex
+Fran\c cois
+@end tex
+Pinard made it diagnose invalid arguments. Jim Blandy bravely coerced
+it into configuring @sc{gnu} Emacs, laying the groundwork for several
+later improvements. Roland McGrath got it to configure the @sc{gnu} C
+Library, wrote the @code{autoheader} script to automate the creation of
+C header file templates, and added a @samp{--verbose} option to
+@code{configure}. Noah Friedman added the @samp{--macrodir} option and
+@code{AC_MACRODIR} environment variable. (He also coined the term
+@dfn{autoconfiscate} to mean ``adapt a software package to use
+Autoconf''.) Roland and Noah improved the quoting protection in
+@code{AC_DEFINE} and fixed many bugs, especially when I got sick of
+dealing with portability problems from February through June, 1993.
+
+@node Deuteronomy, , Numbers, History
+@section 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
+@code{configure} that Autoconf had lacked, largely by adapting the
+relevant parts of Cygnus @code{configure} with the help of david zuhn
+and Ken Raeburn. These features include support for using
+@file{config.sub}, @file{config.guess}, @samp{--host}, and
+@samp{--target}; making links to files; and running @code{configure}
+scripts in subdirectories. Adding these features enabled Ken to convert
+@sc{gnu} @code{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 @code{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 @file{.in} extension on the file names, which produced file
+names like @file{config.h.in} containing two dots. Jim Avera did an
+extensive examination of the problems with quoting in @code{AC_DEFINE}
+and @code{AC_SUBST}; his insights led to significant improvements.
+Richard Stallman asked that compiler output be sent to @file{config.log}
+instead of @file{/dev/null}, to help people debug the Emacs
+@code{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
+@ifinfo
+Franc,ois
+@end ifinfo
+@tex
+Fran\c cois
+@end tex
+Pinard, I made the macros not interrupt each others' messages. (That
+feature revealed some performance bottlenecks in @sc{gnu} @code{m4},
+which he hastily corrected!) I reorganized the documentation around
+problems people want to solve. And I began a test suite, because
+experience had shown that Autoconf has a pronounced tendency to regress
+when we change it.
+
+Again, several alpha testers gave invaluable feedback, especially
+@ifinfo
+Franc,ois
+@end ifinfo
+@tex
+Fran\c cois
+@end tex
+Pinard, Jim Meyering, Karl Berry, Rob Savoye, Ken Raeburn, and Mark
+Eichin.
+
+Finally, version 2.0 was ready. And there was much rejoicing. (And I
+have free time again. I think. Yeah, right.)
-@defmac AC_YYTEXT_POINTER
-@maindex YYTEXT_POINTER
-@code{AC_DECL_YYTEXT}
-@end defmac
+@c ========================================================== Appendices
-@node Environment Variable Index, Output Variable Index, Obsolete Constructs, Top
+@node Environment Variable Index, Output Variable Index, History, Top
@unnumbered Environment Variable Index
This is an alphabetical list of the environment variables that Autoconf
projects / thirdparty / autoconf.git / commitdiff
