From: Akim Demaille Date: Fri, 26 May 2000 14:34:21 +0000 (+0000) Subject: Merge `Upgrading' and `Obsolete Constructs' together. X-Git-Tag: autoconf-2.50~859 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=76f1dd675cd969947f107ba77186a955bc7b65c8;p=thirdparty%2Fautoconf.git Merge `Upgrading' and `Obsolete Constructs' together. * doc/autoconf.texi (Obsolete Constructs): Move right after `Recreation a Configuration. (Invoking autoupdate): Be a subsection of `Obsolete Constructs'. (Upgrading): Demote from chapter to section. Be a section of `Obsolete Constructs'. Rename as `Autoconf 1'. --- diff --git a/ChangeLog b/ChangeLog index f900d5700..71e19ab5e 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,15 @@ +2000-05-26 Akim Demaille + + Merge `Upgrading' and `Obsolete Constructs' together. + + * doc/autoconf.texi (Obsolete Constructs): Move right after + `Recreation a Configuration. + (Invoking autoupdate): Be a subsection of + `Obsolete Constructs'. + (Upgrading): Demote from chapter to section. + Be a section of `Obsolete Constructs'. + Rename as `Autoconf 1'. + 2000-05-26 Akim Demaille Find a means to extract integers from the compiler. diff --git a/doc/autoconf.texi b/doc/autoconf.texi index f542efb40..104ef520a 100644 --- a/doc/autoconf.texi +++ b/doc/autoconf.texi @@ -132,10 +132,9 @@ package. This is edition @value{EDITION}, for Autoconf version * 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 @@ -326,22 +325,29 @@ Running @code{configure} Scripts * 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} @@ -350,12 +356,6 @@ History of Autoconf * 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 @@ -429,7 +429,7 @@ It uses features that some @sc{unix} versions of @code{m4} do not have, 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. @@ -6807,7 +6807,7 @@ may use comes with 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} @@ -6919,1474 +6919,1470 @@ The calling convention of @file{config.status} has changed, see @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 + 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 - 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