# Files that can be generated, but should be up to date for a distribution.
DISTDEP = info Makefile
# Files to distribute.
-DISTFILES = COPYING ChangeLog ChangeLog.1 ChangeLog.0 INSTALL \
+DISTFILES = COPYING ChangeLog ChangeLog.1 INSTALL \
Makefile.in NEWS README TODO \
acconfig.h acfunctions acgeneral.m4 acheaders acidentifiers \
acmakevars acoldnames.m4 acprograms acspecific.m4 autoconf.info* \
support deciding unguessable features based on the host and target types.
* AC_CONFIG_SUBDIRS to recursively configure a source tree.
* AC_CHECK_TYPE, which checks whether sys/types.h defines a given type.
+* AC_CHECK_LIB, which checks for a particular function in a library.
* AC_MSG_CHECKING and AC_MSG_RESULT to print test results, on a single line,
whether or not the test succeeds. They obsolete AC_CHECKING and AC_VERBOSE.
* AC_SUBST_FILE, to insert one file into another.
-*- outline -*-
-Required for 2.0:
-
-------------------------------------------------------------------------------
-
-* Doc: chapter addressing misconceptions and migration from v1.
-
-------------------------------------------------------------------------------
-
-* Try it on Emacs configure.in, and adapt that to use the new features.
-
-------------------------------------------------------------------------------
-
-\f
-Other things:
+Things it would be nice to maybe do someday:
------------------------------------------------------------------------------
M4 environment variable to its path name.
)m4exit(2)])dnl
dnl
-define(AC_ACVERSION, 1.104)dnl
+define(AC_ACVERSION, 1.105)dnl
dnl This is defined by the --version option of the autoconf script.
ifdef([AC_PRINT_VERSION], [Autoconf version AC_ACVERSION
m4exit(0)])dnl
ac_usage="Usage: configure [options] [host]
Options: [defaults in brackets after descriptions]
Configuration:
---cache-file=FILE cache test results in FILE
---help print this message
---no-create do not create output files
---quiet, --silent do not print \`checking...' messages
---version print the version of autoconf that created configure
+ --cache-file=FILE cache test results in FILE
+ --help print this message
+ --no-create do not create output files
+ --quiet, --silent do not print \`checking...' messages
+ --version print the version of autoconf that created configure
Directories:
---exec-prefix=PREFIX install host dependent files in PREFIX [/usr/local]
---prefix=PREFIX install host independent files in PREFIX [/usr/local]
---srcdir=DIR find the sources in DIR [configure dir or ..]
+ --exec-prefix=PREFIX install host dependent files in PREFIX [/usr/local]
+ --prefix=PREFIX install host independent files in PREFIX [/usr/local]
+ --srcdir=DIR find the sources in DIR [configure dir or ..]
Host type:
---build=BUILD configure for building on BUILD [BUILD=HOST]
---host=HOST configure for HOST [guessed]
---target=TARGET configure for TARGET [TARGET=HOST]
+ --build=BUILD configure for building on BUILD [BUILD=HOST]
+ --host=HOST configure for HOST [guessed]
+ --target=TARGET configure for TARGET [TARGET=HOST]
Features and packages:
---disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
---enable-FEATURE[=ARG] include FEATURE [ARG=yes]
---with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
---without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
---x-includes=DIR X include files are in DIR
---x-libraries=DIR X library files are in DIR
+ --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
+ --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
+ --with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
+ --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
+ --x-includes=DIR X include files are in DIR
+ --x-libraries=DIR X library files are in DIR
--enable/--with options recognized:$ac_help"
changequote([, ])dnl
dnl AC_CHECK_LIB(LIBRARY, FUNCTION, [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
dnl [, OTHER-LIBRARIES]]])
AC_DEFUN(AC_CHECK_LIB,
-[changequote(<<, >>)dnl
+[AC_MSG_CHECKING([for -l$1])
+AC_CACHE_VAL(ac_cv_lib_$1,
+[ac_save_LIBS="${LIBS}"
+LIBS="${LIBS} -l$1 $5"
+AC_TRY_LINK(, [$2()], eval "ac_cv_lib_$1=yes", eval "ac_cv_lib_$1=no")dnl
+LIBS="${ac_save_LIBS}"
+])dnl
+if eval "test \"`echo '$ac_cv_lib_'$1`\" = yes"; then
+ AC_MSG_RESULT(yes)
+ ifelse([$3], ,
+[changequote(, )dnl
+ ac_tr_lib=HAVE_LIB`echo $1 | tr '[a-z]' '[A-Z]'`
+changequote([, ])dnl
+ AC_DEFINE(${ac_tr_lib})
+ LIBS="${LIBS} -l$1"
+], [$3])
+else
+ AC_MSG_RESULT(no)
+ifelse([$4], , , [$4
+])dnl
+fi
+])dnl
+dnl
+dnl AC_HAVE_LIBRARY(LIBRARY, [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
+dnl [, OTHER-LIBRARIES]]])
+AC_DEFUN(AC_HAVE_LIBRARY,
+[AC_OBSOLETE([$0], [; instead use AC_CHECK_LIB])dnl
+changequote(<<, >>)dnl
define(<<AC_LIB_NAME>>, dnl
patsubst(patsubst($1, <<lib\([^\.]*\)\.a>>, <<\1>>), <<-l>>, <<>>))dnl
define(<<AC_CV_NAME>>, ac_cv_lib_<<>>AC_LIB_NAME)dnl
AC_MSG_CHECKING([for -l[]AC_LIB_NAME])
AC_CACHE_VAL(AC_CV_NAME,
[ac_save_LIBS="${LIBS}"
-LIBS="${LIBS} -l[]AC_LIB_NAME[] $5"
-AC_TRY_LINK( , [$2()], AC_CV_NAME=yes, AC_CV_NAME=no)dnl
+LIBS="${LIBS} -l[]AC_LIB_NAME[] $4"
+AC_TRY_LINK( , [main()], AC_CV_NAME=yes, AC_CV_NAME=no)dnl
LIBS="${ac_save_LIBS}"
])dnl
AC_MSG_RESULT($AC_CV_NAME)
if test "${AC_CV_NAME}" = yes; then
- ifelse([$3], ,
+ ifelse([$2], ,
[AC_DEFINE([HAVE_LIB]translit(AC_LIB_NAME, [a-z], [A-Z]))
LIBS="${LIBS} -l[]AC_LIB_NAME[]"
-], [$3])
-ifelse([$4], , , [else
- $4
+], [$2])
+ifelse([$3], , , [else
+ $3
])dnl
fi
undefine([AC_LIB_NAME])dnl
undefine([AC_CV_NAME])dnl
])dnl
dnl
-dnl AC_HAVE_LIBRARY(LIBRARY, [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
-dnl [, OTHER-LIBRARIES]]])
-AC_DEFUN(AC_HAVE_LIBRARY,
-[AC_OBSOLETE([$0], [; instead use AC_CHECK_LIB])dnl
-AC_CHECK_LIB([$1], main, [$2], [$3], [$4])dnl
-])dnl
-dnl
dnl
dnl ### Checking for C features - fundamental (no caching)
dnl
AC_DEFUN(AC_PROG_ECHO_N,
[if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then
# Stardent Vistra SVR4 grep lacks -e, says ghazi@caip.rutgers.edu.
- if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn > /dev/null; then
+ if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn >/dev/null; then
ac_n= ac_c='
' ac_t=' '
else
exit 69
' > conftest
chmod u+x conftest
-(SHELL=/bin/sh; export SHELL; ./conftest > /dev/null)
+(SHELL=/bin/sh; export SHELL; ./conftest >/dev/null)
if test $? -ne 69; then
ac_cv_sys_interpreter=yes
else
val=`cat $ac_dir/conftest9012345 2>/dev/null`
if test ! -f $ac_dir/conftest9012345 || test "$val" != 1; then
ac_cv_sys_long_file_names=no
- rm -f $ac_dir/conftest9012345 $ac_dir/conftest9012346 2> /dev/null
+ rm -f $ac_dir/conftest9012345 $ac_dir/conftest9012346 2>/dev/null
break
fi
- rm -f $ac_dir/conftest9012345 $ac_dir/conftest9012346 2> /dev/null
+ rm -f $ac_dir/conftest9012345 $ac_dir/conftest9012346 2>/dev/null
done])dnl
AC_MSG_RESULT($ac_cv_sys_long_file_names)
if test $ac_cv_sys_long_file_names = yes; then
@c @setchapternewpage odd
@c %**end of header
-@set EDITION 1.104
-@set VERSION 1.104
+@set EDITION 1.105
+@set VERSION 1.105
@set UPDATED August 1994
@iftex
@menu
* Introduction:: Autoconf's purpose, strengths, and weaknesses.
-* Distributing:: Legal restrictions on Autoconf output.
* Making configure Scripts:: How to organize and produce Autoconf scripts.
* Specific Tests:: Macros that check for particular features.
* General Purpose Macros:: Macros that check for kinds of features.
* Invoking configure:: How to use the Autoconf output.
* Invoking config.status:: Recreating a configuration.
* Site Default Values:: Providing local defaults for @code{configure}.
-* Old Macro Names:: Backward compatibility macros.
+* Concerns:: Concerns about Autoconf, with answers.
+* Upgrading:: Tips for upgrading from version 1.
* History:: History of Autoconf.
+* Old Macro Names:: Backward compatibility macros.
* Environment Variable Index:: Index of environment variables used.
* Preprocessor Symbol Index:: Index of C preprocessor symbols defined.
* Macro Index:: Index of Autoconf macros.
* System Type:: Specifying the system type.
* Optional Features:: Selecting optional features.
+Concerns About Autoconf
+
+* Copyright:: Legal restrictions on Autoconf output.
+* Why GNU m4:: Why not use the standard @code{m4}?
+* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Policy Decisions:: Configuring site policy.
+
+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.
+* Changed Results:: Changes in how to check test results.
+* Changed Macro Writing:: Better ways to write your own macros.
+
History of Autoconf
* Genesis:: Prehistory and naming of @code{configure}.
* Deuteronomy:: Approaching the promises of easy configuration.
@end menu
-@node Introduction, Distributing, Top, Top
+@node Introduction, Making configure Scripts, Top, Top
@chapter Introduction
@display
Autoconf requires GNU @code{m4} in order to generate the scripts. It
uses features that some UNIX versions of @code{m4} do not have. It also
overflows internal limits of some versions of @code{m4}, including GNU
-@code{m4} 1.0; so use version 1.1 or later of GNU @code{m4}.
-
-Autoconf does not work well with GNU C library releases before 1.06.
-The GNU C library contains stubs (which always return an error) for
-functions that are not available instead of omitting them from the
-library. As a result, Autoconf scripts are fooled into thinking that
-those functions are available. This problem does not exist with
-releases 1.06 and later of the GNU C library, which define C
-preprocessor macros that the Autoconf macros @code{AC_CHECK_FUNC} and
-@code{AC_REPLACE_FUNCS} test, indicating that certain functions are
-stubs (@pxref{C Features}, for more information on checking
-for functions).
+@code{m4} 1.0; you must use version 1.1 or later of GNU @code{m4}.
-@ifinfo
-Autoconf was written by David MacKenzie, with help from Franc,ois
-@end ifinfo
-@tex
-Autoconf was written by David MacKenzie, with help from Fran\c cois
-@end tex
-Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor, Roland McGrath,
-Noah Friedman, and david d zuhn. It was inspired by Brian Fox's
-automatic configuration system for Bash, by Larry Wall's Metaconfig, and
-by Richard Stallman, Richard Pixley, and John Gilmore's configuration
-tools for the GNU compiler and object file utilities.
+@xref{Concerns}, for answers to some common questions about Autoconf.
+@xref{Upgrading}, for information about upgrading from version 1.
+@xref{History}, for the story of Autoconf's development.
Mail suggestions and bug reports for Autoconf to
@code{bug-gnu-utils@@prep.ai.mit.edu}. Please include the Autoconf version
number, which you can get by running @samp{autoconf --version}.
-@node Distributing, Making configure Scripts, Introduction, Top
-@chapter Distributing Autoconf Output
-
-The configuration scripts that Autoconf produces are covered by the GNU
-General Public License. This is because they consist almost entirely of
-parts of Autoconf itself, rearranged somewhat, and Autoconf is
-distributed under the terms of the GPL. As applied to Autoconf, the GPL
-just means that you need to distribute @file{configure.in}, and
-@file{acsite.m4}, @file{aclocal.m4}, @file{acconfig.h}, and
-@file{@var{config}.h.top} and @file{@var{config}.h.bot} if you use them,
-along with @file{configure}.
-
-Programs that use Autoconf scripts to configure themselves do not
-automatically come under the GPL. Distributing an Autoconf
-configuration script as part of a program is considered to be @emph{mere
-aggregation} of that work with the Autoconf script. Such programs are
-not derivative works based on Autoconf; only their configuration scripts
-are. We still encourage software authors to distribute their work under
-terms like those of the GPL, but doing so is not required to use
-Autoconf.
-
-@node Making configure Scripts, Specific Tests, Distributing, Top
+@node Making configure Scripts, Specific Tests, Introduction, Top
@chapter Making @code{configure} Scripts
The configuration scripts that Autoconf produces are by convention
Create a test C program to see whether that program can be linked with
the library @var{library}. @var{function} should be the name of a
function that that library contains, to force the linker to try to link
-with the library to resolve the name.
+with the library to resolve the name. @var{library} must be the base
+name of the library; e.g., to check for @samp{-lmp}, use @samp{mp} as
+the @var{library} argument.
@var{action-if-found} is a list of shell commands to run if the link
succeeds (which means that the library is present);
@var{action-if-not-found} is a list of shell commands to run if the link
fails. If @var{action-if-found} and @var{action-if-not-found} are not
-specified, the default action is to add @samp{-lfoo} to @code{LIBS} and
-define @samp{HAVE_LIBfoo} for library @samp{foo}. @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}.
+specified, the default action is to add @samp{-l@var{library}} to
+@code{LIBS} and define @samp{HAVE_LIB@var{library}}.
If linking with @var{library} results in unresolved symbols, which would
be resolved by linking with additional libraries, give those libraries
@defmac AC_HAVE_LIBRARY (@var{library}, @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found} @r{[}, @var{other-libraries}@r{]]]})
@maindex HAVE_LIBRARY
This macro is equivalent to calling @code{AC_CHECK_LIB} with a
-@var{function} argument of @code{main}. It is considered obsolete,
-because some linkers (e.g., Apollo's) do not fail when asked to link
-with a nonexistent library if there are no unresolved sybols.
+@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}. This macro is
+considered obsolete, because some linkers (e.g., Apollo's) do not fail
+when asked to link with a nonexistent library if there are no unresolved
+sybols.
@end defmac
@defmac AC_PATH_PROG (@var{variable}, @var{prog-to-check-for} @r{[}, @var{value-if-not-found}@r{]})
@var{action-if-false}. @var{help-string} is a description of
the option which looks like this:
@example
---enable-readline support fancy command line editing
+ --enable-readline support fancy command line editing
@end example
@noindent
@var{help-string} may be more than one line long, if more detail is
needed. Just make sure the columns line up in @samp{configure --help}.
+Avoid tabs in the help string.
The name @var{feature} should consist only of alphanumeric characters
and dashes. The @var{feature} indicates an optional user-level
@var{action-if-false}. @var{help-string} is a description of
the option which looks like this:
@example
---with-gnu-as use the GNU assembler
+ --with-gnu-as use the GNU assembler
@end example
@noindent
@var{help-string} may be more than one line long, if more detail is
needed. Just make sure the columns line up in @samp{configure --help}.
+Avoid tabs in the help string.
The name @var{package} should consist only of alphanumeric characters
and dashes. The @var{package} indicates another software package that
(If @file{configure.in} does not call @code{AC_CONFIG_HEADER}, there is
no need to set @code{CONFIG_HEADERS} in the @code{make} rules.)
-@node Site Default Values, Old Macro Names, Invoking config.status, Top
+@node Site Default Values, Concerns, Invoking config.status, Top
@chapter Site Default Values
Autoconf-generated @code{configure} scripts support site and system wide
test $exec_prefix = NONE && exec_prefix=/usr/local/gnu
@end example
-@node Old Macro Names, History, Site Default Values, Top
+@node Concerns, Upgrading, Site Default Values, Top
+@chapter Concerns About Autoconf
+
+Several concerns about Autoconf come up regularly. Here some of them
+are addressed.
+
+@menu
+* Copyright:: Legal restrictions on Autoconf output.
+* Why GNU m4:: Why not use the standard @code{m4}?
+* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Policy Decisions:: Configuring site policy.
+@end menu
+
+@node Copyright, Why GNU m4, , Concerns
+@section Copyright on @code{configure} Scripts
+
+@display
+What are the restrictions on distributing @code{configure}
+scripts that Autoconf generated? How does that affect my
+programs that use them?
+@end display
+
+The configuration scripts that Autoconf produces are covered by the GNU
+General Public License. This is because they consist almost entirely of
+parts of Autoconf itself, rearranged somewhat, and Autoconf is
+distributed under the terms of the GPL. As applied to Autoconf, the GPL
+just means that you need to distribute @file{configure.in}, and
+@file{acsite.m4}, @file{aclocal.m4}, @file{acconfig.h}, and
+@file{@var{config}.h.top} and @file{@var{config}.h.bot} if you use them,
+along with @file{configure}.
+
+Programs that use Autoconf scripts to configure themselves do not
+automatically come under the GPL. Distributing an Autoconf
+configuration script as part of a program is considered to be @emph{mere
+aggregation} of that work with the Autoconf script. Such programs are
+not derivative works based on Autoconf; only their configuration scripts
+are. We still encourage software authors to distribute their work under
+terms like those of the GPL, but doing so is not required to use
+Autoconf.
+
+@node Why GNU m4, Bootstrapping, Copyright, Concerns
+@section Why Require GNU @code{m4}?
+
+@display
+Why does Autoconf require GNU @code{m4}?
+@end display
+
+Many @code{m4} implementations have hard-coded limitations on the size
+and number of macros. They also lack regular expression capabilities
+and other builtins that it would be difficult to get along without in a
+sophisticated application like Autoconf. Since only software
+maintainers need to use Autoconf, and since GNU @code{m4} is simple to
+configure and install, it does not seem like an unreasonable burden to
+require GNU @code{m4} to be installed also. Most maintainers of GNU and
+other free software already have most of the GNU utilities installed,
+since they prefer them.
+
+@node Bootstrapping, Policy Decisions, Why GNU m4, Concerns
+@section How Can I Bootstrap?
+
+@display
+If Autoconf requires GNU @code{m4} and GNU @code{m4} has an
+Autoconf @code{configure} script, how do I bootstrap? It seems
+like a chicken and egg problem!
+@end display
+
+Although GNU @code{m4} does come with a @code{configure} script produced
+by Autoconf, Autoconf is @emph{not} required in order to run the script
+and install GNU @code{m4}. Autoconf is only required if you want to
+@emph{change} the @code{m4} @code{configure} script, which few people
+have to do (mainly its maintainer).
+
+@node Policy Decisions, , Bootstrapping, Concerns
+@section Configuring Site Policy
+
+@display
+How do I configure in policy decisions, since the
+@code{configure} scripts aren't interactive?
+@end display
+
+There are two ways to do it. Simple decisions can be specified using
+@samp{--with} and @samp{--enable} options to @code{configure}
+(@pxref{Command Line}).
+
+More sophisticated site configuration information---company names, email
+addresses to contact, etc.---should be put in a file that is edited
+@emph{only by users}. The programs should examine that file at run
+time, rather than at compile time. That approach is more convenient for
+users and makes the configuration process simpler than asking for the
+information while configuring.
+
+@node Upgrading, History, Concerns, Top
+@chapter Upgrading From Version 1
+
+Autoconf version 2 is mostly backward compatible with version 1.
+However, it introduces better ways to do some things, and doesn't
+support some of the ugly things about 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; see the @file{NEWS} file in the distribution for a summary.
+
+@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
+
+@node Changed File Names, Changed Makefiles, , Upgrading
+@section Changed File Names
+
+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 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}.
+
+@node Changed Makefiles, Changed Macros, Changed File Names, Upgrading
+@section Changed Makefiles
+
+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} was run.
+This isn't necessary, but it's a convenience for users.
+
+If you have the following in @file{Makefile.in}:
+
+@example
+prefix = /usr/local
+exec_prefix = $@{prefix@}
+@end example
+
+@noindent
+you must change it to:
+
+@example
+prefix = @@prefix@@
+exec_prefix = @@exec_prefix@@
+@end example
+
+@noindent
+The old feature of replacing those variables without @samp{@@}
+characters around them has been removed.
+
+@node Changed Macros, Changed Results, Changed Makefiles, Upgrading
+@section Changed Macros
+
+Many of the macros were renamed in Autoconf version 2. You can still
+use the old names, but the new ones are clearer, and it's easier to find
+the documentation for them. @xref{Old Macro Names}, 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}.
+
+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 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}, 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 Values}.
+
+@node Changed Results, Changed Macro Writing, Changed Macros, Upgrading
+@section 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
+Variables}.
+
+For example, here is a @file{configure.in} fragment written for Autoconf
+version 1:
+
+@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
+
+Here is a way to write it for version 2:
+
+@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 $lib"; break])
+ done
+fi
+@end example
+
+If you were working around bugs in @code{AC_DEFINE_UNQUOTED} by adding
+backslashes, you probably need to remove them. It now works
+predictably, and does not treat quotes (except backquotes) specially.
+@xref{Setting Variables}.
+
+@node Changed Macro Writing, , Changed Results, Upgrading
+@section Changed Macro Writing
+
+When defining your own macros, you may now use @code{AC_DEFUN} instead of
+@code{define}, because @code{AC_DEFUN} automatically calls
+@code{AC_PROVIDE}. There's no harm in continuing to use the older way;
+it's just less convenient. @xref{Macro Format}.
+
+If you were doing tricky things with undocumented Autoconf internals
+(diversions, macros, variables), check whether you need to change
+anything to account for changes that have been made. Perhaps you can
+even use an officially supported technique in version 2 instead of
+kludging. Or perhaps not.
+
+To speed up your locally written feature tests, add caching to them. If
+you don't encapsulate your tests into macros, do so; don't be sloppy.
+(I've been guilty myself.) @xref{Caching Values}.
+
+@node History, Old Macro Names, Upgrading, Top
+@chapter History of Autoconf
+
+You may be wondering, Why was Autoconf originally written? How did it
+get into its present form? (Why does it look like gorilla spit?) If
+you're not wondering, then this chapter contains no information useful
+to you, and you might as well skip it. If you @emph{are} wondering,
+then let there be light.
+
+@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
+
+@node Genesis, Exodus, , History
+@section Genesis
+
+In June 1991 I was maintaining many of the GNU utilities for the Free
+Software Foundation. As they were ported to more platforms and more
+programs were added, the number of @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 GNU utilities packages. Brian Berliner also adapted one
+of my scripts for his CVS revision control system.
+
+Later that summer, I learned that Richard Stallman and Richard Pixley
+were developing similar scripts to use in the GNU compiler tools; so I
+adapted my @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.
+
+@node Exodus, Leviticus, Genesis, History
+@section Exodus
+
+As I got feedback from users, I incorporated many improvements, using
+Emacs to search and replace, cut and paste, similar changes in each of
+the scripts. As I adapted more GNU utilities packages to use
+@code{configure} scripts, updating them all by hand became burdensome.
+Rich Murphey, the maintainer of the GNU graphics utilities, sent me mail
+saying that the @code{configure} scripts were great, and asking if I had
+a program 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 bondage of hand-written @file{configure} scripts to the
+promise of Autoconf began.
+
+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.
+
+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.
+
+I looked briefly into using Larry Wall's Metaconfig program, 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); it
+was not being maintained, and its scripts didn't work on many modern
+systems (such as System V R4 and NeXT); it wasn't very flexible in what
+it could do in response to a feature's presence or absence; I found it
+confusing to learn; and it was too big and complex for my needs (I
+didn't realize then how much Autoconf would eventually have to grow).
+
+I considered using Perl to generate my style of @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 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 System V R3 file systems, so
+I shortened it to Autoconf.
+
+In the fall of 1991 I called together a group of priests of portability
+(er, 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; Karl
+Berry, who championed standardizing the @code{HAVE_@var{feature}} form
+for C preprocessor symbols; 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 it in 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 of GNU packages to use it. I was surprised by how
+positive the reaction to it was. More people started using it than I
+could keep track of, including people working on software that wasn't
+part of the GNU Project (such as TCL, FSP, @TeX{}, 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. Unix @code{m4} started to dump core because of the
+length of the macros that Autoconf defined, and several bugs showed up
+in GNU @code{m4} as well. Eventually, we realized that we needed to use
+some features that only GNU @code{m4} has. BSD @code{m4}, in
+particular, has an impoverished set of builtin macros; the System V
+version is better, but still doesn't have 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 GNU Emacs, laying the groundwork for several later
+improvements. Roland McGrath got it to configure the 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. 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
+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. Jim Avera did an
+extensive examination of the problems with quoting in @code{AC_DEFINE};
+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
+useful auxiliary utilities that I had developed to help convert source
+code packages to use Autoconf. And I began a testsuite, because
+experience had shown that Autoconf has a pronounced tendency to regress
+when we change it.
+
+Again, several alpha testers gave invaluable feedback, especially
+@ifinfo
+Franc,ois
+@end ifinfo
+@tex
+Fran\c cois
+@end tex
+Pinard, Rob Savoye, and Ken Raeburn.
+
+Finally, version 2.0 was ready. And there was much rejoicing.
+(And I have free time again. I think.)
+
+@node Old Macro Names, Environment Variable Index, History, Top
@chapter Old Macro Names
In version 2 of Autoconf, most of the macros were renamed to use a more
@code{AC_DECL_YYTEXT}
@end table
-@node History, Environment Variable Index, Old Macro Names, Top
-@chapter History of Autoconf
-
-You may be wondering, Why was Autoconf originally written? How did it
-get into its present form? (Why does it look like gorilla spit?) If
-you're not wondering, then this chapter contains no information useful
-to you, and you might as well skip it. If you @emph{are} wondering,
-then let there be light.
-
-@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
-
-@node Genesis, Exodus, , History
-@section Genesis
-
-In June 1991 I was maintaining many of the GNU utilities for the Free
-Software Foundation. As they were ported to more platforms and more
-programs were added, the number of @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 GNU utilities packages. Brian Berliner also adapted one
-of my scripts for his CVS revision control system.
-
-Later that summer, I learned that Richard Stallman and Richard Pixley
-were developing similar scripts to use in the GNU compiler tools; so I
-adapted my @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.
-
-@node Exodus, Leviticus, Genesis, History
-@section Exodus
-
-As I got feedback from users, I incorporated many improvements, using
-Emacs to search and replace, cut and paste, similar changes in each of
-the scripts. As I adapted more GNU utilities packages to use
-@code{configure} scripts, updating them all by hand became burdensome.
-Rich Murphey, the maintainer of the GNU graphics utilities, sent me mail
-saying that the @code{configure} scripts were great, and asking if I had
-a program 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 bondage of hand-written @file{configure} scripts to the
-promise of Autoconf began.
-
-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). 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.
-
-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.
-
-I looked briefly into using Larry Wall's Metaconfig program, 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); it
-was not being maintained, and its scripts didn't work on many modern
-systems (such as System V R4 and NeXT); it wasn't very flexible in what
-it could do in response to a feature's presence or absence; I found it
-confusing to learn; and it was too big and complex for my needs (I
-didn't realize then how much Autoconf would eventually have to grow).
-
-I considered using Perl to generate my style of @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 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 System V R3 file systems, so
-I shortened it to Autoconf.
-
-In the fall of 1991 I called together a group of priests of portability
-(er, 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; Karl
-Berry, who championed standardizing the @code{HAVE_@var{feature}} form
-for C preprocessor symbols; 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 it in 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 of GNU packages to use it. I was surprised by how
-positive the reaction to it was. More people started using it than I
-could keep track of, including people working on software that wasn't
-part of the GNU Project (such as TCL, FSP, @TeX{}, 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. Unix @code{m4} started to dump core because of the
-length of the macros that Autoconf defined, and several bugs showed up
-in GNU @code{m4} as well. Eventually, we realized that we needed to use
-some features that only GNU @code{m4} has. BSD @code{m4}, in
-particular, has an impoverished set of builtin macros; the System V
-version is better, but still doesn't have 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 GNU Emacs, laying the groundwork for several later
-improvements. Roland McGrath got it to configure the 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. 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
-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. Jim Avera did an
-extensive examination of the problems with quoting in @code{AC_DEFINE};
-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
-useful auxiliary utilities that I had developed to help convert source
-code packages to use Autoconf. And I began a testsuite, because
-experience had shown that Autoconf has a pronounced tendency to regress
-when we change it.
-
-Again, several alpha testers gave invaluable feedback, especially
-@ifinfo
-Franc,ois
-@end ifinfo
-@tex
-Fran\c cois
-@end tex
-Pinard, Rob Savoye, and Ken Raeburn.
-
-Finally, version 2.0 was ready. And there was much rejoicing.
-(And I have free time again. I think.)
-
-@node Environment Variable Index, Preprocessor Symbol Index, History, Top
+@node Environment Variable Index, Preprocessor Symbol Index, Old Macro Names, Top
@unnumbered Environment Variable Index
This is an alphabetical list of the environment variables that Autoconf
# Files that can be generated, but should be up to date for a distribution.
DISTDEP = info Makefile
# Files to distribute.
-DISTFILES = COPYING ChangeLog ChangeLog.1 ChangeLog.0 INSTALL \
+DISTFILES = COPYING ChangeLog ChangeLog.1 INSTALL \
Makefile.in NEWS README TODO \
acconfig.h acfunctions acgeneral.m4 acheaders acidentifiers \
acmakevars acoldnames.m4 acprograms acspecific.m4 autoconf.info* \
@c @setchapternewpage odd
@c %**end of header
-@set EDITION 1.104
-@set VERSION 1.104
+@set EDITION 1.105
+@set VERSION 1.105
@set UPDATED August 1994
@iftex
@menu
* Introduction:: Autoconf's purpose, strengths, and weaknesses.
-* Distributing:: Legal restrictions on Autoconf output.
* Making configure Scripts:: How to organize and produce Autoconf scripts.
* Specific Tests:: Macros that check for particular features.
* General Purpose Macros:: Macros that check for kinds of features.
* Invoking configure:: How to use the Autoconf output.
* Invoking config.status:: Recreating a configuration.
* Site Default Values:: Providing local defaults for @code{configure}.
-* Old Macro Names:: Backward compatibility macros.
+* Concerns:: Concerns about Autoconf, with answers.
+* Upgrading:: Tips for upgrading from version 1.
* History:: History of Autoconf.
+* Old Macro Names:: Backward compatibility macros.
* Environment Variable Index:: Index of environment variables used.
* Preprocessor Symbol Index:: Index of C preprocessor symbols defined.
* Macro Index:: Index of Autoconf macros.
* System Type:: Specifying the system type.
* Optional Features:: Selecting optional features.
+Concerns About Autoconf
+
+* Copyright:: Legal restrictions on Autoconf output.
+* Why GNU m4:: Why not use the standard @code{m4}?
+* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Policy Decisions:: Configuring site policy.
+
+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.
+* Changed Results:: Changes in how to check test results.
+* Changed Macro Writing:: Better ways to write your own macros.
+
History of Autoconf
* Genesis:: Prehistory and naming of @code{configure}.
* Deuteronomy:: Approaching the promises of easy configuration.
@end menu
-@node Introduction, Distributing, Top, Top
+@node Introduction, Making configure Scripts, Top, Top
@chapter Introduction
@display
Autoconf requires GNU @code{m4} in order to generate the scripts. It
uses features that some UNIX versions of @code{m4} do not have. It also
overflows internal limits of some versions of @code{m4}, including GNU
-@code{m4} 1.0; so use version 1.1 or later of GNU @code{m4}.
-
-Autoconf does not work well with GNU C library releases before 1.06.
-The GNU C library contains stubs (which always return an error) for
-functions that are not available instead of omitting them from the
-library. As a result, Autoconf scripts are fooled into thinking that
-those functions are available. This problem does not exist with
-releases 1.06 and later of the GNU C library, which define C
-preprocessor macros that the Autoconf macros @code{AC_CHECK_FUNC} and
-@code{AC_REPLACE_FUNCS} test, indicating that certain functions are
-stubs (@pxref{C Features}, for more information on checking
-for functions).
+@code{m4} 1.0; you must use version 1.1 or later of GNU @code{m4}.
-@ifinfo
-Autoconf was written by David MacKenzie, with help from Franc,ois
-@end ifinfo
-@tex
-Autoconf was written by David MacKenzie, with help from Fran\c cois
-@end tex
-Pinard, Karl Berry, Richard Pixley, Ian Lance Taylor, Roland McGrath,
-Noah Friedman, and david d zuhn. It was inspired by Brian Fox's
-automatic configuration system for Bash, by Larry Wall's Metaconfig, and
-by Richard Stallman, Richard Pixley, and John Gilmore's configuration
-tools for the GNU compiler and object file utilities.
+@xref{Concerns}, for answers to some common questions about Autoconf.
+@xref{Upgrading}, for information about upgrading from version 1.
+@xref{History}, for the story of Autoconf's development.
Mail suggestions and bug reports for Autoconf to
@code{bug-gnu-utils@@prep.ai.mit.edu}. Please include the Autoconf version
number, which you can get by running @samp{autoconf --version}.
-@node Distributing, Making configure Scripts, Introduction, Top
-@chapter Distributing Autoconf Output
-
-The configuration scripts that Autoconf produces are covered by the GNU
-General Public License. This is because they consist almost entirely of
-parts of Autoconf itself, rearranged somewhat, and Autoconf is
-distributed under the terms of the GPL. As applied to Autoconf, the GPL
-just means that you need to distribute @file{configure.in}, and
-@file{acsite.m4}, @file{aclocal.m4}, @file{acconfig.h}, and
-@file{@var{config}.h.top} and @file{@var{config}.h.bot} if you use them,
-along with @file{configure}.
-
-Programs that use Autoconf scripts to configure themselves do not
-automatically come under the GPL. Distributing an Autoconf
-configuration script as part of a program is considered to be @emph{mere
-aggregation} of that work with the Autoconf script. Such programs are
-not derivative works based on Autoconf; only their configuration scripts
-are. We still encourage software authors to distribute their work under
-terms like those of the GPL, but doing so is not required to use
-Autoconf.
-
-@node Making configure Scripts, Specific Tests, Distributing, Top
+@node Making configure Scripts, Specific Tests, Introduction, Top
@chapter Making @code{configure} Scripts
The configuration scripts that Autoconf produces are by convention
Create a test C program to see whether that program can be linked with
the library @var{library}. @var{function} should be the name of a
function that that library contains, to force the linker to try to link
-with the library to resolve the name.
+with the library to resolve the name. @var{library} must be the base
+name of the library; e.g., to check for @samp{-lmp}, use @samp{mp} as
+the @var{library} argument.
@var{action-if-found} is a list of shell commands to run if the link
succeeds (which means that the library is present);
@var{action-if-not-found} is a list of shell commands to run if the link
fails. If @var{action-if-found} and @var{action-if-not-found} are not
-specified, the default action is to add @samp{-lfoo} to @code{LIBS} and
-define @samp{HAVE_LIBfoo} for library @samp{foo}. @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}.
+specified, the default action is to add @samp{-l@var{library}} to
+@code{LIBS} and define @samp{HAVE_LIB@var{library}}.
If linking with @var{library} results in unresolved symbols, which would
be resolved by linking with additional libraries, give those libraries
@defmac AC_HAVE_LIBRARY (@var{library}, @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found} @r{[}, @var{other-libraries}@r{]]]})
@maindex HAVE_LIBRARY
This macro is equivalent to calling @code{AC_CHECK_LIB} with a
-@var{function} argument of @code{main}. It is considered obsolete,
-because some linkers (e.g., Apollo's) do not fail when asked to link
-with a nonexistent library if there are no unresolved sybols.
+@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}. This macro is
+considered obsolete, because some linkers (e.g., Apollo's) do not fail
+when asked to link with a nonexistent library if there are no unresolved
+sybols.
@end defmac
@defmac AC_PATH_PROG (@var{variable}, @var{prog-to-check-for} @r{[}, @var{value-if-not-found}@r{]})
@var{action-if-false}. @var{help-string} is a description of
the option which looks like this:
@example
---enable-readline support fancy command line editing
+ --enable-readline support fancy command line editing
@end example
@noindent
@var{help-string} may be more than one line long, if more detail is
needed. Just make sure the columns line up in @samp{configure --help}.
+Avoid tabs in the help string.
The name @var{feature} should consist only of alphanumeric characters
and dashes. The @var{feature} indicates an optional user-level
@var{action-if-false}. @var{help-string} is a description of
the option which looks like this:
@example
---with-gnu-as use the GNU assembler
+ --with-gnu-as use the GNU assembler
@end example
@noindent
@var{help-string} may be more than one line long, if more detail is
needed. Just make sure the columns line up in @samp{configure --help}.
+Avoid tabs in the help string.
The name @var{package} should consist only of alphanumeric characters
and dashes. The @var{package} indicates another software package that
(If @file{configure.in} does not call @code{AC_CONFIG_HEADER}, there is
no need to set @code{CONFIG_HEADERS} in the @code{make} rules.)
-@node Site Default Values, Old Macro Names, Invoking config.status, Top
+@node Site Default Values, Concerns, Invoking config.status, Top
@chapter Site Default Values
Autoconf-generated @code{configure} scripts support site and system wide
test $exec_prefix = NONE && exec_prefix=/usr/local/gnu
@end example
-@node Old Macro Names, History, Site Default Values, Top
+@node Concerns, Upgrading, Site Default Values, Top
+@chapter Concerns About Autoconf
+
+Several concerns about Autoconf come up regularly. Here some of them
+are addressed.
+
+@menu
+* Copyright:: Legal restrictions on Autoconf output.
+* Why GNU m4:: Why not use the standard @code{m4}?
+* Bootstrapping:: Autoconf and GNU @code{m4} require each other?
+* Policy Decisions:: Configuring site policy.
+@end menu
+
+@node Copyright, Why GNU m4, , Concerns
+@section Copyright on @code{configure} Scripts
+
+@display
+What are the restrictions on distributing @code{configure}
+scripts that Autoconf generated? How does that affect my
+programs that use them?
+@end display
+
+The configuration scripts that Autoconf produces are covered by the GNU
+General Public License. This is because they consist almost entirely of
+parts of Autoconf itself, rearranged somewhat, and Autoconf is
+distributed under the terms of the GPL. As applied to Autoconf, the GPL
+just means that you need to distribute @file{configure.in}, and
+@file{acsite.m4}, @file{aclocal.m4}, @file{acconfig.h}, and
+@file{@var{config}.h.top} and @file{@var{config}.h.bot} if you use them,
+along with @file{configure}.
+
+Programs that use Autoconf scripts to configure themselves do not
+automatically come under the GPL. Distributing an Autoconf
+configuration script as part of a program is considered to be @emph{mere
+aggregation} of that work with the Autoconf script. Such programs are
+not derivative works based on Autoconf; only their configuration scripts
+are. We still encourage software authors to distribute their work under
+terms like those of the GPL, but doing so is not required to use
+Autoconf.
+
+@node Why GNU m4, Bootstrapping, Copyright, Concerns
+@section Why Require GNU @code{m4}?
+
+@display
+Why does Autoconf require GNU @code{m4}?
+@end display
+
+Many @code{m4} implementations have hard-coded limitations on the size
+and number of macros. They also lack regular expression capabilities
+and other builtins that it would be difficult to get along without in a
+sophisticated application like Autoconf. Since only software
+maintainers need to use Autoconf, and since GNU @code{m4} is simple to
+configure and install, it does not seem like an unreasonable burden to
+require GNU @code{m4} to be installed also. Most maintainers of GNU and
+other free software already have most of the GNU utilities installed,
+since they prefer them.
+
+@node Bootstrapping, Policy Decisions, Why GNU m4, Concerns
+@section How Can I Bootstrap?
+
+@display
+If Autoconf requires GNU @code{m4} and GNU @code{m4} has an
+Autoconf @code{configure} script, how do I bootstrap? It seems
+like a chicken and egg problem!
+@end display
+
+Although GNU @code{m4} does come with a @code{configure} script produced
+by Autoconf, Autoconf is @emph{not} required in order to run the script
+and install GNU @code{m4}. Autoconf is only required if you want to
+@emph{change} the @code{m4} @code{configure} script, which few people
+have to do (mainly its maintainer).
+
+@node Policy Decisions, , Bootstrapping, Concerns
+@section Configuring Site Policy
+
+@display
+How do I configure in policy decisions, since the
+@code{configure} scripts aren't interactive?
+@end display
+
+There are two ways to do it. Simple decisions can be specified using
+@samp{--with} and @samp{--enable} options to @code{configure}
+(@pxref{Command Line}).
+
+More sophisticated site configuration information---company names, email
+addresses to contact, etc.---should be put in a file that is edited
+@emph{only by users}. The programs should examine that file at run
+time, rather than at compile time. That approach is more convenient for
+users and makes the configuration process simpler than asking for the
+information while configuring.
+
+@node Upgrading, History, Concerns, Top
+@chapter Upgrading From Version 1
+
+Autoconf version 2 is mostly backward compatible with version 1.
+However, it introduces better ways to do some things, and doesn't
+support some of the ugly things about 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; see the @file{NEWS} file in the distribution for a summary.
+
+@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
+
+@node Changed File Names, Changed Makefiles, , Upgrading
+@section Changed File Names
+
+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 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}.
+
+@node Changed Makefiles, Changed Macros, Changed File Names, Upgrading
+@section Changed Makefiles
+
+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} was run.
+This isn't necessary, but it's a convenience for users.
+
+If you have the following in @file{Makefile.in}:
+
+@example
+prefix = /usr/local
+exec_prefix = $@{prefix@}
+@end example
+
+@noindent
+you must change it to:
+
+@example
+prefix = @@prefix@@
+exec_prefix = @@exec_prefix@@
+@end example
+
+@noindent
+The old feature of replacing those variables without @samp{@@}
+characters around them has been removed.
+
+@node Changed Macros, Changed Results, Changed Makefiles, Upgrading
+@section Changed Macros
+
+Many of the macros were renamed in Autoconf version 2. You can still
+use the old names, but the new ones are clearer, and it's easier to find
+the documentation for them. @xref{Old Macro Names}, 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}.
+
+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 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}, 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 Values}.
+
+@node Changed Results, Changed Macro Writing, Changed Macros, Upgrading
+@section 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
+Variables}.
+
+For example, here is a @file{configure.in} fragment written for Autoconf
+version 1:
+
+@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
+
+Here is a way to write it for version 2:
+
+@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 $lib"; break])
+ done
+fi
+@end example
+
+If you were working around bugs in @code{AC_DEFINE_UNQUOTED} by adding
+backslashes, you probably need to remove them. It now works
+predictably, and does not treat quotes (except backquotes) specially.
+@xref{Setting Variables}.
+
+@node Changed Macro Writing, , Changed Results, Upgrading
+@section Changed Macro Writing
+
+When defining your own macros, you may now use @code{AC_DEFUN} instead of
+@code{define}, because @code{AC_DEFUN} automatically calls
+@code{AC_PROVIDE}. There's no harm in continuing to use the older way;
+it's just less convenient. @xref{Macro Format}.
+
+If you were doing tricky things with undocumented Autoconf internals
+(diversions, macros, variables), check whether you need to change
+anything to account for changes that have been made. Perhaps you can
+even use an officially supported technique in version 2 instead of
+kludging. Or perhaps not.
+
+To speed up your locally written feature tests, add caching to them. If
+you don't encapsulate your tests into macros, do so; don't be sloppy.
+(I've been guilty myself.) @xref{Caching Values}.
+
+@node History, Old Macro Names, Upgrading, Top
+@chapter History of Autoconf
+
+You may be wondering, Why was Autoconf originally written? How did it
+get into its present form? (Why does it look like gorilla spit?) If
+you're not wondering, then this chapter contains no information useful
+to you, and you might as well skip it. If you @emph{are} wondering,
+then let there be light.
+
+@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
+
+@node Genesis, Exodus, , History
+@section Genesis
+
+In June 1991 I was maintaining many of the GNU utilities for the Free
+Software Foundation. As they were ported to more platforms and more
+programs were added, the number of @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 GNU utilities packages. Brian Berliner also adapted one
+of my scripts for his CVS revision control system.
+
+Later that summer, I learned that Richard Stallman and Richard Pixley
+were developing similar scripts to use in the GNU compiler tools; so I
+adapted my @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.
+
+@node Exodus, Leviticus, Genesis, History
+@section Exodus
+
+As I got feedback from users, I incorporated many improvements, using
+Emacs to search and replace, cut and paste, similar changes in each of
+the scripts. As I adapted more GNU utilities packages to use
+@code{configure} scripts, updating them all by hand became burdensome.
+Rich Murphey, the maintainer of the GNU graphics utilities, sent me mail
+saying that the @code{configure} scripts were great, and asking if I had
+a program 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 bondage of hand-written @file{configure} scripts to the
+promise of Autoconf began.
+
+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.
+
+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.
+
+I looked briefly into using Larry Wall's Metaconfig program, 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); it
+was not being maintained, and its scripts didn't work on many modern
+systems (such as System V R4 and NeXT); it wasn't very flexible in what
+it could do in response to a feature's presence or absence; I found it
+confusing to learn; and it was too big and complex for my needs (I
+didn't realize then how much Autoconf would eventually have to grow).
+
+I considered using Perl to generate my style of @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 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 System V R3 file systems, so
+I shortened it to Autoconf.
+
+In the fall of 1991 I called together a group of priests of portability
+(er, 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; Karl
+Berry, who championed standardizing the @code{HAVE_@var{feature}} form
+for C preprocessor symbols; 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 it in 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 of GNU packages to use it. I was surprised by how
+positive the reaction to it was. More people started using it than I
+could keep track of, including people working on software that wasn't
+part of the GNU Project (such as TCL, FSP, @TeX{}, 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. Unix @code{m4} started to dump core because of the
+length of the macros that Autoconf defined, and several bugs showed up
+in GNU @code{m4} as well. Eventually, we realized that we needed to use
+some features that only GNU @code{m4} has. BSD @code{m4}, in
+particular, has an impoverished set of builtin macros; the System V
+version is better, but still doesn't have 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 GNU Emacs, laying the groundwork for several later
+improvements. Roland McGrath got it to configure the 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. 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
+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. Jim Avera did an
+extensive examination of the problems with quoting in @code{AC_DEFINE};
+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
+useful auxiliary utilities that I had developed to help convert source
+code packages to use Autoconf. And I began a testsuite, because
+experience had shown that Autoconf has a pronounced tendency to regress
+when we change it.
+
+Again, several alpha testers gave invaluable feedback, especially
+@ifinfo
+Franc,ois
+@end ifinfo
+@tex
+Fran\c cois
+@end tex
+Pinard, Rob Savoye, and Ken Raeburn.
+
+Finally, version 2.0 was ready. And there was much rejoicing.
+(And I have free time again. I think.)
+
+@node Old Macro Names, Environment Variable Index, History, Top
@chapter Old Macro Names
In version 2 of Autoconf, most of the macros were renamed to use a more
@code{AC_DECL_YYTEXT}
@end table
-@node History, Environment Variable Index, Old Macro Names, Top
-@chapter History of Autoconf
-
-You may be wondering, Why was Autoconf originally written? How did it
-get into its present form? (Why does it look like gorilla spit?) If
-you're not wondering, then this chapter contains no information useful
-to you, and you might as well skip it. If you @emph{are} wondering,
-then let there be light.
-
-@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
-
-@node Genesis, Exodus, , History
-@section Genesis
-
-In June 1991 I was maintaining many of the GNU utilities for the Free
-Software Foundation. As they were ported to more platforms and more
-programs were added, the number of @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 GNU utilities packages. Brian Berliner also adapted one
-of my scripts for his CVS revision control system.
-
-Later that summer, I learned that Richard Stallman and Richard Pixley
-were developing similar scripts to use in the GNU compiler tools; so I
-adapted my @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.
-
-@node Exodus, Leviticus, Genesis, History
-@section Exodus
-
-As I got feedback from users, I incorporated many improvements, using
-Emacs to search and replace, cut and paste, similar changes in each of
-the scripts. As I adapted more GNU utilities packages to use
-@code{configure} scripts, updating them all by hand became burdensome.
-Rich Murphey, the maintainer of the GNU graphics utilities, sent me mail
-saying that the @code{configure} scripts were great, and asking if I had
-a program 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 bondage of hand-written @file{configure} scripts to the
-promise of Autoconf began.
-
-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). 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.
-
-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.
-
-I looked briefly into using Larry Wall's Metaconfig program, 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); it
-was not being maintained, and its scripts didn't work on many modern
-systems (such as System V R4 and NeXT); it wasn't very flexible in what
-it could do in response to a feature's presence or absence; I found it
-confusing to learn; and it was too big and complex for my needs (I
-didn't realize then how much Autoconf would eventually have to grow).
-
-I considered using Perl to generate my style of @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 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 System V R3 file systems, so
-I shortened it to Autoconf.
-
-In the fall of 1991 I called together a group of priests of portability
-(er, 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; Karl
-Berry, who championed standardizing the @code{HAVE_@var{feature}} form
-for C preprocessor symbols; 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 it in 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 of GNU packages to use it. I was surprised by how
-positive the reaction to it was. More people started using it than I
-could keep track of, including people working on software that wasn't
-part of the GNU Project (such as TCL, FSP, @TeX{}, 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. Unix @code{m4} started to dump core because of the
-length of the macros that Autoconf defined, and several bugs showed up
-in GNU @code{m4} as well. Eventually, we realized that we needed to use
-some features that only GNU @code{m4} has. BSD @code{m4}, in
-particular, has an impoverished set of builtin macros; the System V
-version is better, but still doesn't have 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 GNU Emacs, laying the groundwork for several later
-improvements. Roland McGrath got it to configure the 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. 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
-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. Jim Avera did an
-extensive examination of the problems with quoting in @code{AC_DEFINE};
-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
-useful auxiliary utilities that I had developed to help convert source
-code packages to use Autoconf. And I began a testsuite, because
-experience had shown that Autoconf has a pronounced tendency to regress
-when we change it.
-
-Again, several alpha testers gave invaluable feedback, especially
-@ifinfo
-Franc,ois
-@end ifinfo
-@tex
-Fran\c cois
-@end tex
-Pinard, Rob Savoye, and Ken Raeburn.
-
-Finally, version 2.0 was ready. And there was much rejoicing.
-(And I have free time again. I think.)
-
-@node Environment Variable Index, Preprocessor Symbol Index, History, Top
+@node Environment Variable Index, Preprocessor Symbol Index, Old Macro Names, Top
@unnumbered Environment Variable Index
This is an alphabetical list of the environment variables that Autoconf
M4 environment variable to its path name.
)m4exit(2)])dnl
dnl
-define(AC_ACVERSION, 1.104)dnl
+define(AC_ACVERSION, 1.105)dnl
dnl This is defined by the --version option of the autoconf script.
ifdef([AC_PRINT_VERSION], [Autoconf version AC_ACVERSION
m4exit(0)])dnl
ac_usage="Usage: configure [options] [host]
Options: [defaults in brackets after descriptions]
Configuration:
---cache-file=FILE cache test results in FILE
---help print this message
---no-create do not create output files
---quiet, --silent do not print \`checking...' messages
---version print the version of autoconf that created configure
+ --cache-file=FILE cache test results in FILE
+ --help print this message
+ --no-create do not create output files
+ --quiet, --silent do not print \`checking...' messages
+ --version print the version of autoconf that created configure
Directories:
---exec-prefix=PREFIX install host dependent files in PREFIX [/usr/local]
---prefix=PREFIX install host independent files in PREFIX [/usr/local]
---srcdir=DIR find the sources in DIR [configure dir or ..]
+ --exec-prefix=PREFIX install host dependent files in PREFIX [/usr/local]
+ --prefix=PREFIX install host independent files in PREFIX [/usr/local]
+ --srcdir=DIR find the sources in DIR [configure dir or ..]
Host type:
---build=BUILD configure for building on BUILD [BUILD=HOST]
---host=HOST configure for HOST [guessed]
---target=TARGET configure for TARGET [TARGET=HOST]
+ --build=BUILD configure for building on BUILD [BUILD=HOST]
+ --host=HOST configure for HOST [guessed]
+ --target=TARGET configure for TARGET [TARGET=HOST]
Features and packages:
---disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
---enable-FEATURE[=ARG] include FEATURE [ARG=yes]
---with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
---without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
---x-includes=DIR X include files are in DIR
---x-libraries=DIR X library files are in DIR
+ --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no)
+ --enable-FEATURE[=ARG] include FEATURE [ARG=yes]
+ --with-PACKAGE[=ARG] use PACKAGE [ARG=yes]
+ --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no)
+ --x-includes=DIR X include files are in DIR
+ --x-libraries=DIR X library files are in DIR
--enable/--with options recognized:$ac_help"
changequote([, ])dnl
dnl AC_CHECK_LIB(LIBRARY, FUNCTION, [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
dnl [, OTHER-LIBRARIES]]])
AC_DEFUN(AC_CHECK_LIB,
-[changequote(<<, >>)dnl
+[AC_MSG_CHECKING([for -l$1])
+AC_CACHE_VAL(ac_cv_lib_$1,
+[ac_save_LIBS="${LIBS}"
+LIBS="${LIBS} -l$1 $5"
+AC_TRY_LINK(, [$2()], eval "ac_cv_lib_$1=yes", eval "ac_cv_lib_$1=no")dnl
+LIBS="${ac_save_LIBS}"
+])dnl
+if eval "test \"`echo '$ac_cv_lib_'$1`\" = yes"; then
+ AC_MSG_RESULT(yes)
+ ifelse([$3], ,
+[changequote(, )dnl
+ ac_tr_lib=HAVE_LIB`echo $1 | tr '[a-z]' '[A-Z]'`
+changequote([, ])dnl
+ AC_DEFINE(${ac_tr_lib})
+ LIBS="${LIBS} -l$1"
+], [$3])
+else
+ AC_MSG_RESULT(no)
+ifelse([$4], , , [$4
+])dnl
+fi
+])dnl
+dnl
+dnl AC_HAVE_LIBRARY(LIBRARY, [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
+dnl [, OTHER-LIBRARIES]]])
+AC_DEFUN(AC_HAVE_LIBRARY,
+[AC_OBSOLETE([$0], [; instead use AC_CHECK_LIB])dnl
+changequote(<<, >>)dnl
define(<<AC_LIB_NAME>>, dnl
patsubst(patsubst($1, <<lib\([^\.]*\)\.a>>, <<\1>>), <<-l>>, <<>>))dnl
define(<<AC_CV_NAME>>, ac_cv_lib_<<>>AC_LIB_NAME)dnl
AC_MSG_CHECKING([for -l[]AC_LIB_NAME])
AC_CACHE_VAL(AC_CV_NAME,
[ac_save_LIBS="${LIBS}"
-LIBS="${LIBS} -l[]AC_LIB_NAME[] $5"
-AC_TRY_LINK( , [$2()], AC_CV_NAME=yes, AC_CV_NAME=no)dnl
+LIBS="${LIBS} -l[]AC_LIB_NAME[] $4"
+AC_TRY_LINK( , [main()], AC_CV_NAME=yes, AC_CV_NAME=no)dnl
LIBS="${ac_save_LIBS}"
])dnl
AC_MSG_RESULT($AC_CV_NAME)
if test "${AC_CV_NAME}" = yes; then
- ifelse([$3], ,
+ ifelse([$2], ,
[AC_DEFINE([HAVE_LIB]translit(AC_LIB_NAME, [a-z], [A-Z]))
LIBS="${LIBS} -l[]AC_LIB_NAME[]"
-], [$3])
-ifelse([$4], , , [else
- $4
+], [$2])
+ifelse([$3], , , [else
+ $3
])dnl
fi
undefine([AC_LIB_NAME])dnl
undefine([AC_CV_NAME])dnl
])dnl
dnl
-dnl AC_HAVE_LIBRARY(LIBRARY, [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND
-dnl [, OTHER-LIBRARIES]]])
-AC_DEFUN(AC_HAVE_LIBRARY,
-[AC_OBSOLETE([$0], [; instead use AC_CHECK_LIB])dnl
-AC_CHECK_LIB([$1], main, [$2], [$3], [$4])dnl
-])dnl
-dnl
dnl
dnl ### Checking for C features - fundamental (no caching)
dnl
AC_DEFUN(AC_PROG_ECHO_N,
[if (echo "testing\c"; echo 1,2,3) | grep c >/dev/null; then
# Stardent Vistra SVR4 grep lacks -e, says ghazi@caip.rutgers.edu.
- if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn > /dev/null; then
+ if (echo -n testing; echo 1,2,3) | sed s/-n/xn/ | grep xn >/dev/null; then
ac_n= ac_c='
' ac_t=' '
else
exit 69
' > conftest
chmod u+x conftest
-(SHELL=/bin/sh; export SHELL; ./conftest > /dev/null)
+(SHELL=/bin/sh; export SHELL; ./conftest >/dev/null)
if test $? -ne 69; then
ac_cv_sys_interpreter=yes
else
val=`cat $ac_dir/conftest9012345 2>/dev/null`
if test ! -f $ac_dir/conftest9012345 || test "$val" != 1; then
ac_cv_sys_long_file_names=no
- rm -f $ac_dir/conftest9012345 $ac_dir/conftest9012346 2> /dev/null
+ rm -f $ac_dir/conftest9012345 $ac_dir/conftest9012346 2>/dev/null
break
fi
- rm -f $ac_dir/conftest9012345 $ac_dir/conftest9012346 2> /dev/null
+ rm -f $ac_dir/conftest9012345 $ac_dir/conftest9012346 2>/dev/null
done])dnl
AC_MSG_RESULT($ac_cv_sys_long_file_names)
if test $ac_cv_sys_long_file_names = yes; then
AC_PROG_CC AC_PROG_CXX AC_PROG_GCC_TRADITIONAL AC_PROG_CC_C_O
AC_PROG_MAKE_SET AC_PROG_RANLIB AC_PROG_AWK AC_PROG_YACC AC_PROG_CPP
AC_PROG_CXXCPP AC_REQUIRE_CPP AC_PROG_LEX AC_DECL_YYTEXT
-AC_PROG_INSTALL AC_PROG_LN_S AC_PROG_RSH AC_HEADER_STDC AC_UNISTD_H
+AC_PROG_INSTALL AC_PROG_LN_S AC_HEADER_STDC AC_UNISTD_H
AC_USG AC_MEMORY_H AC_HEADER_MAJOR AC_DIR_HEADER AC_HEADER_DIRENT
AC_HEADER_STAT AC_DECL_SYS_SIGLIST AC_TYPE_GETGROUPS AC_TYPE_UID_T
AC_TYPE_SIZE_T AC_TYPE_PID_T AC_TYPE_OFF_T AC_TYPE_MODE_T
projects / thirdparty / autoconf.git / commitdiff
