Autoconf is a tool for producing shell scripts that automatically
configure software source code packages to adapt to many kinds of
-UNIX-like systems. The configuration scripts produced by Autoconf are
-independent of Autoconf when they are run, so their users do not need to
-have Autoconf.
+@sc{unix}-like systems. The configuration scripts produced by Autoconf
+are independent of Autoconf when they are run, so their users do not
+need to have Autoconf.
The configuration scripts produced by Autoconf require no manual user
intervention when run; they do not normally even need an argument
(Before each check, they print a one-line message stating what they are
checking for, so the user doesn't get too bored while waiting for the
script to finish.) As a result, they deal well with systems that are
-hybrids or customized from the more common UNIX variants. There is no
-need to maintain files that list the features supported by each release
-of each variant of UNIX.
+hybrids or customized from the more common @sc{unix} variants. There is
+no need to maintain files that list the features supported by each
+release of each variant of @sc{unix}.
For each software package that Autoconf is used with, it creates a
configuration script from a template file that lists the system features
Autoconf imposes some restrictions on the names of macros used with
@code{#if} in C programs (@pxref{Preprocessor Symbol Index}).
-Autoconf requires GNU @code{m4} in order to generate the scripts. It
-uses features that some UNIX versions of @code{m4} do not have,
-including GNU @code{m4} 1.3. You must use version 1.4 or later of GNU
-@code{m4}.
+Autoconf requires @sc{gnu} @code{m4} in order to generate the scripts.
+It uses features that some @sc{unix} versions of @code{m4} do not have,
+including @sc{gnu} @code{m4} 1.3. You must use version 1.4 or later of
+@sc{gnu} @code{m4}.
@xref{Upgrading}, for information about upgrading from version 1.
@xref{History}, for the story of Autoconf's development.
@c The asis prevents RCS from changing the example in the manual.
@example
-AC_REVISION($@asis{Revision: 1.30 }$)dnl
+AC_REVISION($@asis{Revision: 1.30 }$)
@end example
@noindent
for each architecture are kept in their own directory.
To support doing this, @code{make} uses the @code{VPATH} variable to
-find the files that are in the source directory. GNU @code{make} and
-most other recent @code{make} programs can do this. Older @code{make}
-programs do not support @code{VPATH}; when using them, the source code
-must be in the same directory as the object files.
+find the files that are in the source directory. @sc{gnu} @code{make}
+and most other recent @code{make} programs can do this. Older
+@code{make} programs do not support @code{VPATH}; when using them, the
+source code must be in the same directory as the object files.
To support @code{VPATH}, each @file{Makefile.in} should contain two
lines that look like:
configuration header files. Omit from the @file{Makefile.in} rules any
of these files that your package does not use.
-The @samp{$@{srcdir@}/} prefix is included because of limitations in the
+The @samp{$(srcdir)/} prefix is included because of limitations in the
@code{VPATH} mechanism.
The @file{stamp-} files are necessary because the timestamps of
them does not change their contents. This feature avoids unnecessary
recompilation. You should include the file @file{stamp-h.in} your
package's distribution, so @code{make} will consider @file{config.h.in}
-up to date. On some old BSD systems, @code{touch} or any command that
-results in an empty file does not update the timestamps, so use a
+up to date. On some old @sc{bsd} systems, @code{touch} or any command
+that results in an empty file does not update the timestamps, so use a
command like @code{echo} as a workaround.
@c Using @code{date} would cause needless CVS conflicts.
@example
@group
-$@{srcdir@}/configure: configure.in aclocal.m4
- cd $@{srcdir@} && autoconf
+$(srcdir)/configure: configure.in aclocal.m4
+ cd $(srcdir) && autoconf
# autoheader might not change config.h.in, so touch a stamp file.
-$@{srcdir@}/config.h.in: stamp-h.in
-$@{srcdir@}/stamp-h.in: configure.in aclocal.m4 acconfig.h \
+$(srcdir)/config.h.in: stamp-h.in
+$(srcdir)/stamp-h.in: configure.in aclocal.m4 acconfig.h \
config.h.top config.h.bot
- cd $@{srcdir@} && autoheader
- echo timestamp > $@{srcdir@}/stamp-h.in
+ cd $(srcdir) && autoheader
+ echo timestamp > $(srcdir)/stamp-h.in
config.h: stamp-h
stamp-h: config.h.in config.status
For example, this call:
@example
-AC_CONFIG_LINKS(host.h:config/$@{machine@}.h
- object.h:config/$@{obj_format@}.h)
+AC_CONFIG_LINKS(host.h:config/$machine.h
+ object.h:config/$obj_format.h)
@end example
@noindent
creates in the current directory @file{host.h}, which is a link to
-@file{@var{srcdir}/config/$@{machine@}.h}, and @file{object.h}, which is
-a link to @file{@var{srcdir}/config/$@{obj_format@}.h}.
+@file{@var{srcdir}/config/$machine.h}, and @file{object.h}, which is a
+link to @file{@var{srcdir}/config/$obj_format.h}.
The tempting value @samp{.} for @var{dest} is invalid: it makes it
impossible for @samp{config.status} to guess the links to establish. It
AC_PROG_CC(cl egcs gcc cc)
@end example
-If using the GNU C compiler, set shell variable @code{GCC} to
-@samp{yes}, empty otherwise. If output variable @code{CFLAGS} was
-not already set, set it to @samp{-g -O2} for the GNU C compiler
-(@samp{-O2} on systems where GCC does not accept @samp{-g}), or @samp{-g}
-for other compilers.
+If using the @sc{gnu} C compiler, set shell variable @code{GCC} to
+@samp{yes}, empty otherwise. If output variable @code{CFLAGS} was not
+already set, set it to @samp{-g -O2} for the @sc{gnu} C compiler
+(@samp{-O2} on systems where GCC does not accept @samp{-g}), or
+@samp{-g} for other compilers.
If the C compiler being used does not produce executables that can run
on the system where @code{configure} is being run, set the shell
simultaneously, define @code{NO_MINUS_C_MINUS_O}. This macro actually
tests both the compiler found by @code{AC_PROG_CC}, and, if different,
the first @code{cc} in the path. The test fails if one fails. This
-macro was created for GNU Make to choose the default C compilation rule.
+macro was created for @sc{gnu} Make to choose the default C compilation
+rule.
@end defmac
@defmac AC_PROG_CC_STDC
@maindex PROG_CC_STDC
@ovindex CC
-If the C compiler in not in ANSI C mode by default, try to add an option
-to output variable @code{CC} to make it so. This macro tries various
-options that select ANSI C on some system or another. It considers the
-compiler to be in ANSI C mode if it handles function prototypes
-correctly.
+If the C compiler in not in @sc{ansi} C mode by default, try to add an
+option to output variable @code{CC} to make it so. This macro tries
+various options that select @sc{ansi} C on some system or another. It
+considers the compiler to be in @sc{ansi} C mode if it handles function
+prototypes correctly.
If you use this macro, you should check after calling it whether the C
-compiler has been set to accept ANSI C; if not, the shell variable
+compiler has been set to accept @sc{ansi} C; if not, the shell variable
@code{ac_cv_prog_cc_stdc} is set to @samp{no}. If you wrote your source
-code in ANSI C, you can make an un-ANSIfied copy of it by using the
-program @code{ansi2knr}, which comes with Ghostscript.
+code in @sc{ansi} C, you can make an un-@sc{ansi}fied copy of it by
+using the program @code{ansi2knr}, which comes with Ghostscript.
@end defmac
AC_PROG_CXX(cl KCC CC cxx cc++ xlC aCC c++ g++ egcs gcc)
@end example
-If using the GNU C++ compiler, set shell variable @code{GXX} to
+If using the @sc{gnu} C++ compiler, set shell variable @code{GXX} to
@samp{yes}, empty otherwise. If output variable @code{CXXFLAGS} was not
-already set, set it to @samp{-g -O2} for the GNU C++ compiler
+already set, set it to @samp{-g -O2} for the @sc{gnu} C++ compiler
(@samp{-O2} on systems where G++ does not accept @samp{-g}), or
@samp{-g} for other compilers.
AC_PROG_F77(fl32 f77 fort77 xlf cf77 g77 f90 xlf90 f2c)
@end example
-If using @code{g77} (the GNU Fortran 77 compiler), then
+If using @code{g77} (the @sc{gnu} Fortran 77 compiler), then
@code{AC_PROG_F77} will set the shell variable @code{G77} to @samp{yes},
and empty otherwise. If the output variable @code{FFLAGS} was not
already set in the environment, then set it to @samp{-g -02} for
@maindex PROG_GCC_TRADITIONAL
@ovindex CC
Add @samp{-traditional} to output variable @code{CC} if using the
-GNU C compiler and @code{ioctl} does not work properly without
+@sc{gnu} C compiler and @code{ioctl} does not work properly without
@samp{-traditional}. That usually happens when the fixed header files
have not been installed on an old system. Since recent versions of the
-GNU C compiler fix the header files automatically when installed, this
-is becoming a less prevalent problem.
+@sc{gnu} C compiler fix the header files automatically when installed,
+this is becoming a less prevalent problem.
@end defmac
@defmac AC_PROG_INSTALL
@ovindex INSTALL_PROGRAM
@ovindex INSTALL_DATA
@ovindex INSTALL_SCRIPT
-Set output variable @code{INSTALL} to the path of a BSD compatible
+Set output variable @code{INSTALL} to the path of a @sc{bsd} compatible
@code{install} program, if one is found in the current @code{PATH}.
Otherwise, set @code{INSTALL} to @samp{@var{dir}/install-sh -c},
checking the directories specified to @code{AC_CONFIG_AUX_DIR} (or its
default directories) to determine @var{dir} (@pxref{Output}). Also set
the variables @code{INSTALL_PROGRAM} and @code{INSTALL_SCRIPT} to
-@samp{$@{INSTALL@}} and @code{INSTALL_DATA} to @samp{$@{INSTALL@} -m
-644}.
+@samp{$INSTALL} and @code{INSTALL_DATA} to @samp{$INSTALL -m 644}.
This macro screens out various instances of @code{install} known to not
work. It prefers to find a C program rather than a shell script, for
them---even if the system you're on has a good @code{install} program.
This check is a safety measure to prevent you from accidentally leaving
that file out, which would prevent your package from installing on
-systems that don't have a BSD-compatible @code{install} program.
+systems that don't have a @sc{bsd}-compatible @code{install} program.
If you need to use your own installation program because it has features
not found in standard @code{install} programs, there is no reason to use
@defmac AC_PROG_GNU_M4
@maindex PROG_GNU_M4
@ovindex GNU_M4
-If GNU @code{m4} version 1.4 or above is found, set output variable
+If @sc{gnu} @code{m4} version 1.4 or above is found, set output variable
@code{M4} to @samp{m4}.
@end defmac
like the following, to declare it properly. In some versions of AIX,
the declaration of @code{alloca} must precede everything else except for
comments and preprocessor directives. The @code{#pragma} directive is
-indented so that pre-ANSI C compilers will ignore it, rather than choke
-on it.
+indented so that pre-@sc{ansi} C compilers will ignore it, rather than
+choke on it.
@example
@group
@defmac AC_FUNC_GETPGRP
@maindex FUNC_GETPGRP
@cvindex GETPGRP_VOID
-If @code{getpgrp} takes no argument (the POSIX.1 version), define
-@code{GETPGRP_VOID}. Otherwise, it is the BSD version, which takes a
-process ID as an argument. This macro does not check whether
+If @code{getpgrp} takes no argument (the @sc{posix.1} version), define
+@code{GETPGRP_VOID}. Otherwise, it is the @sc{bsd} version, which takes
+a process ID as an argument. This macro does not check whether
@code{getpgrp} exists at all; if you need to work in that situation,
first call @code{AC_CHECK_FUNC} for @code{getpgrp}.
@end defmac
@defmac AC_FUNC_SETPGRP
@maindex FUNC_SETPGRP
@cvindex SETPGRP_VOID
-If @code{setpgrp} takes no argument (the POSIX.1 version), define
-@code{SETPGRP_VOID}. Otherwise, it is the BSD version, which takes two
-process ID as arguments. This macro does not check whether
+If @code{setpgrp} takes no argument (the @sc{posix.1} version), define
+@code{SETPGRP_VOID}. Otherwise, it is the @sc{bsd} version, which takes
+two process ID as arguments. This macro does not check whether
@code{setpgrp} exists at all; if you need to work in that situation,
first call @code{AC_CHECK_FUNC} for @code{setpgrp}.
@end defmac
@defmac AC_FUNC_STRFTIME
@maindex FUNC_STRFTIME
@cvindex HAVE_STRFTIME
-Check for @code{strftime} in the @file{intl} library, for SCO UNIX.
+Check for @code{strftime} in the @file{intl} library, for SCO @sc{unix}.
Then, if @code{strftime} is available, define @code{HAVE_STRFTIME}.
@end defmac
@var{action-if-found}, otherwise @var{action-if-not-found}. If you just
want to define a symbol if the function is available, consider using
@code{AC_CHECK_FUNCS} instead. This macro checks for functions with C
-linkage even when @code{AC_LANG_CPLUSPLUS} has been called, since C++ is
-more standardized than C is. (@pxref{Language Choice}, for more
-information about selecting the language for checks.)
+linkage even when @code{AC_LANG(C++)} has been called, since C++ is more
+standardized than C is. (@pxref{Language Choice}, for more information
+about selecting the language for checks.)
@end defmac
@defmac AC_CHECK_FUNCS (@var{function}@dots{}, @ovar{action-if-found}, @ovar{action-if-not-found})
Specify that @samp{@var{function}.c} must be included in the executables
to replace a missing or broken implementation of @var{function}.
-Technically it adds @samp{@var{function}.$@{ac_objext@}} to the output
+Technically it adds @samp{@var{function}.$ac_objext} to the output
variable @code{LIBOBJS}, nevertheless you must not directly change
@code{LIBOBJS} since this is not traceable.
@end defmac
@defmac AC_HEADER_STDC
@maindex HEADER_STDC
@cvindex STDC_HEADERS
-Define @code{STDC_HEADERS} if the system has ANSI C header files.
+Define @code{STDC_HEADERS} if the system has @sc{ansi} C header files.
Specifically, this macro checks for @file{stdlib.h}, @file{stdarg.h},
@file{string.h}, and @file{float.h}; if the system has those, it
-probably has the rest of the ANSI C header files. This macro also
+probably has the rest of the @sc{ansi} C header files. This macro also
checks whether @file{string.h} declares @code{memchr} (and thus
presumably the other @code{mem} functions), whether @file{stdlib.h}
declare @code{free} (and thus presumably @code{malloc} and other related
functions), and whether the @file{ctype.h} macros work on characters
-with the high bit set, as ANSI C requires.
+with the high bit set, as @sc{ansi} C requires.
Use @code{STDC_HEADERS} instead of @code{__STDC__} to determine whether
-the system has ANSI-compliant header files (and probably C library
-functions) because many systems that have GCC do not have ANSI C header
-files.
-
-On systems without ANSI C headers, there is so much variation that it is
-probably easier to declare the functions you use than to figure out
-exactly what the system header files declare. Some systems contain a
-mix of functions ANSI and BSD; some are mostly ANSI but lack
-@samp{memmove}; some define the BSD functions as macros in
-@file{string.h} or @file{strings.h}; some have only the BSD functions
-but @file{string.h}; some declare the memory functions in
+the system has @sc{ansi}-compliant header files (and probably C library
+functions) because many systems that have GCC do not have @sc{ansi} C
+header files.
+
+On systems without @sc{ansi} C headers, there is so much variation that
+it is probably easier to declare the functions you use than to figure
+out exactly what the system header files declare. Some systems contain
+a mix of functions @sc{ansi} and @sc{bsd}; some are mostly @sc{ansi} but
+lack @samp{memmove}; some define the @sc{bsd} functions as macros in
+@file{string.h} or @file{strings.h}; some have only the @sc{bsd}
+functions but @file{string.h}; some declare the memory functions in
@file{memory.h}, some in @file{string.h}; etc. It is probably
sufficient to check for one string function and one memory function; if
-the library has the ANSI versions of those then it probably has most of
-the others. If you put the following in @file{configure.in}:
+the library has the @sc{ansi} versions of those then it probably has
+most of the others. If you put the following in @file{configure.in}:
@example
AC_HEADER_STDC
@noindent
If you use a function like @code{memchr}, @code{memset}, @code{strtok},
-or @code{strspn}, which have no BSD equivalent, then macros won't
+or @code{strspn}, which have no @sc{bsd} equivalent, then macros won't
suffice; you must provide an implementation of each function. An easy
way to incorporate your implementations only when needed (since the ones
in system C libraries may be hand optimized) is to, taking @code{memchr}
@defmac AC_HEADER_SYS_WAIT
@maindex HEADER_SYS_WAIT
@cvindex HAVE_SYS_WAIT_H
-If @file{sys/wait.h} exists and is compatible with POSIX.1, define
+If @file{sys/wait.h} exists and is compatible with @sc{posix.1}, define
@code{HAVE_SYS_WAIT_H}. Incompatibility can occur if @file{sys/wait.h}
-does not exist, or if it uses the old BSD @code{union wait} instead of
-@code{int} to store a status value. If @file{sys/wait.h} is not POSIX.1
-compatible, then instead of including it, define the POSIX.1 macros with
-their usual interpretations. Here is an example:
+does not exist, or if it uses the old @sc{bsd} @code{union wait} instead
+of @code{int} to store a status value. If @file{sys/wait.h} is not
+@sc{posix.1} compatible, then instead of including it, define the
+@sc{posix.1} macros with their usual interpretations. Here is an
+example:
@example
@group
@cvindex _POSIX_VERSION
@code{_POSIX_VERSION} is defined when @file{unistd.h} is included on
-POSIX.1 systems. If there is no @file{unistd.h}, it is definitely not a
-POSIX.1 system. However, some non-POSIX.1 systems do have
-@file{unistd.h}.
+@sc{posix.1} systems. If there is no @file{unistd.h}, it is definitely
+not a @sc{posix.1} system. However, some non-@sc{posix.1} systems do
+have @file{unistd.h}.
-The way to check if the system supports POSIX.1 is:
+The way to check if the system supports @sc{posix.1} is:
@example
@group
@defmac AC_C_CONST
@maindex C_CONST
@cvindex const
-If the C compiler does not fully support the ANSI C qualifier
+If the C compiler does not fully support the @sc{ansi} C qualifier
@code{const}, define @code{const} to be empty. Some C compilers that do
not define @code{__STDC__} do support @code{const}; some compilers that
define @code{__STDC__} do not completely support @code{const}. Programs
@code{volatile}, you are at its mercy anyway. At least your
program will compile, when it wouldn't before.
-In general, the @code{volatile} keyword is a feature of ANSI C, so you
-might expect that @code{volatile} is available only when @code{__STDC__}
-is defined. However, Ultrix 4.3's native compiler does support
-volatile, but does not defined @code{__STDC__}.
+In general, the @code{volatile} keyword is a feature of @sc{ansi} C, so
+you might expect that @code{volatile} is available only when
+@code{__STDC__} is defined. However, Ultrix 4.3's native compiler does
+support volatile, but does not defined @code{__STDC__}.
@end defmac
@defmac AC_C_INLINE
@end defmac
@node UNIX Variants, , System Services, Existing Tests
-@section UNIX Variants
+@section @sc{unix} Variants
The following macros check for certain operating systems that need
special treatment for some programs, due to exceptional oddities in
@defmac AC_AIX
@maindex AIX
@cvindex _ALL_SOURCE
-If on AIX, define @code{_ALL_SOURCE}. Allows the use of some BSD
+If on AIX, define @code{_ALL_SOURCE}. Allows the use of some @sc{bsd}
functions. Should be called before any macros that run the C compiler.
@end defmac
@maindex ISC_POSIX
@cvindex _POSIX_SOURCE
@ovindex CC
-If on a POSIXized ISC UNIX, define @code{_POSIX_SOURCE} and add
-@samp{-posix} (for the GNU C compiler) or @samp{-Xp} (for other C
+If on a POSIXized ISC @sc{unix}, define @code{_POSIX_SOURCE} and add
+@samp{-posix} (for the @sc{gnu} C compiler) or @samp{-Xp} (for other C
compilers) to output variable @code{CC}. This allows the use of
-POSIX facilities. Must be called after @code{AC_PROG_CC} and before
-any other macros that run the C compiler.
+@sc{posix} facilities. Must be called after @code{AC_PROG_CC} and
+before any other macros that run the C compiler.
@end defmac
@defmac AC_MINIX
@cvindex _POSIX_SOURCE
@cvindex _POSIX_1_SOURCE
If on Minix, define @code{_MINIX} and @code{_POSIX_SOURCE} and define
-@code{_POSIX_1_SOURCE} to be 2. This allows the use of POSIX
+@code{_POSIX_1_SOURCE} to be 2. This allows the use of @sc{posix}
facilities. Should be called before any macros that run the C compiler.
@end defmac
Test programs can use @code{#if} or @code{#ifdef} to check the values of
preprocessor macros defined by tests that have already run. For
example, if you call @code{AC_HEADER_STDC}, then later on in
-@file{configure.in} you can have a test program that includes an ANSI C
-header file conditionally:
+@file{configure.in} you can have a test program that includes an
+@sc{ansi} C header file conditionally:
@example
@group
techniques you should avoid in order to make your code portable. The
Bourne shell and upward-compatible shells like Bash and the Korn shell
have evolved over the years, but to prevent trouble, do not take
-advantage of features that were added after UNIX version 7, circa 1977.
-You should not use shell functions, aliases, negated character classes,
-or other features that are not found in all Bourne-compatible shells;
-restrict yourself to the lowest common denominator. Even @code{unset}
-is not supported by all shells! Also, include a space after the
-exclamation point in interpreter specifications, like this:
+advantage of features that were added after @sc{unix} version 7, circa
+1977. You should not use shell functions, aliases, negated character
+classes, or other features that are not found in all Bourne-compatible
+shells; restrict yourself to the lowest common denominator. Even
+@code{unset} is not supported by all shells! Also, include a space
+after the exclamation point in interpreter specifications, like this:
@example
#! /usr/bin/perl
@end example
@noindent
-If you omit the space before the path, then 4.2BSD based systems (such
-as Sequent DYNIX) will ignore the line, because they interpret @samp{#! /}
-as a 4-byte magic number.
+If you omit the space before the path, then 4.2@sc{bsd} based systems
+(such as Sequent DYNIX) will ignore the line, because they interpret
+@samp{#! /} as a 4-byte magic number.
The set of external programs you should run in a @code{configure} script
is fairly small. @xref{Utilities in Makefiles,, Utilities in
that name in Autoconf code is asking for trouble since it is an
@code{m4} quote character.
-If you need to make multiple checks using @code{test}, combine
-them with the shell operators @samp{&&} and @samp{||} instead of using
-the @code{test} operators @samp{-a} and @samp{-o}. On System V, the
+If you need to make multiple checks using @code{test}, combine them with
+the shell operators @samp{&&} and @samp{||} instead of using the
+@code{test} operators @samp{-a} and @samp{-o}. On System V, the
precedence of @samp{-a} and @samp{-o} is wrong relative to the unary
-operators; consequently, POSIX does not specify them, so using them is
-nonportable. If you combine @samp{&&} and @samp{||} in the same
+operators; consequently, @sc{posix} does not specify them, so using them
+is nonportable. If you combine @samp{&&} and @samp{||} in the same
statement, keep in mind that they have equal precedence.
-
@c FIXME: Hm, I'd say the `target' here should be `build'.
To enable @code{configure} scripts to support cross-compilation, they
shouldn't do anything that tests features of the host system instead of
the target system. But occasionally you may find it necessary to check
whether some arbitrary file exists. To do so, use @samp{test -f} or
-@samp{test -r}. Do not use @samp{test -x}, because 4.3BSD does not have
-it.
+@samp{test -r}. Do not use @samp{test -x}, because 4.3@sc{bsd} does not
+have it.
@node Shell Substitutions, Limitations of Usual Tools, Testing Values and Files, Portable Shell
@subsection Shell Substitutions
@noindent
The intent is to set @var{var} to @var{value} only if it is not already
set, but if @var{var} has any value, even the empty string, to leave it
-alone. Old BSD shells, including the Ultrix @code{sh}, don't accept the
-colon for any shell substitution, and complain and die. A portable
-equivalent is
+alone. Old @sc{bsd} shells, including the Ultrix @code{sh}, don't
+accept the colon for any shell substitution, and complain and die. A
+portable equivalent is
@example
: $@{@var{var}=@var{value}@}
@section Multiple Cases
Some operations are accomplished in several possible ways, depending on
-the UNIX variant. Checking for them essentially requires a ``case
+the @sc{unix} variant. Checking for them essentially requires a ``case
statement''. Autoconf does not directly provide one; however, it is
easy to simulate by using a shell variable to keep track of whether a
way to perform the operation has been found yet.
features by default. The following macros determine which language's
compiler is used in tests that follow in @file{configure.in}.
-@defmac AC_LANG_C
-@maindex LANG_C
+@defmac AC_LANG (@var{language})
+Do compilation tests using the compiler, preprocessor and file
+extensions for the @var{language}. Set the shell variable
+@code{cross_compiling} to @samp{yes} or @samp{no} if the compiler is
+known to be a cross compiler, empty otherwise.
+
+Support languages are:
+
+@table @samp
+@item C
Do compilation tests using @code{CC} and @code{CPP} and use extension
@file{.c} for test programs. Set the shell variable
@code{cross_compiling} to the value computed by @code{AC_PROG_CC} if it
has been run, empty otherwise.
-@end defmac
-@defmac AC_LANG_CPLUSPLUS
-@maindex LANG_CPLUSPLUS
+@item C++
Do compilation tests using @code{CXX} and @code{CXXCPP} and use
extension @file{.C} for test programs. Set the shell variable
@code{cross_compiling} to the value computed by @code{AC_PROG_CXX} if
it has been run, empty otherwise.
-@end defmac
-@defmac AC_LANG_FORTRAN77
-@maindex LANG_FORTRAN77
+@item Fortran 77
Do compilation tests using @code{F77} and use extension @file{.f} for
test programs. Set the shell variable @code{cross_compiling} to the
value computed by @code{AC_PROG_F77} if it has been run, empty
otherwise.
+@end table
@end defmac
@defmac AC_LANG_SAVE
@var{variable} or @var{value} is a shell variable. Examples:
@example
-AC_DEFINE_UNQUOTED(config_machfile, "$@{machfile@}")
+AC_DEFINE_UNQUOTED(config_machfile, "$machfile")
AC_DEFINE_UNQUOTED(GETGROUPS_T, $ac_cv_type_getgroups)
-AC_DEFINE_UNQUOTED($@{ac_tr_hdr@})
+AC_DEFINE_UNQUOTED($ac_tr_hdr)
@end example
@end defmac
could contain:
@example
-AC_SUBST_FILE(host_frag)dnl
+AC_SUBST_FILE(host_frag)
host_frag=$srcdir/conf/sun4.mh
@end example
by redefining the cache macros at the start of @file{configure.in}:
@example
-define([AC_CACHE_LOAD])dnl
-define([AC_CACHE_SAVE])dnl
+define([AC_CACHE_LOAD])
+define([AC_CACHE_SAVE])
AC_INIT(@r{whatever})
@r{ ... rest of configure.in ...}
@end example
@example
@r{ ... AC_INIT, etc. ...}
-dnl checks for programs
+# Checks for programs.
AC_PROG_CC
AC_PROG_GCC_TRADITIONAL
@r{ ... more program checks ...}
AC_CACHE_SAVE
-dnl checks for libraries
+# Checks for libraries.
AC_CHECK_LIB(nsl, gethostbyname)
AC_CHECK_LIB(socket, connect)
@r{ ... more lib checks ...}
AC_CACHE_SAVE
-dnl Might abort...
+# Might abort...
AM_PATH_GTK(1.0.2,, exit 1)
AM_PATH_GTKMM(0.9.5,, exit 1)
+@r{ ... AC_OUTPUT, etc. ...}
@end example
@node Printing Messages, , Caching Results, Results
@item FUNC
Functions in libraries.
@item GROUP
-UNIX group owners of files.
+@sc{unix} group owners of files.
@item HEADER
Header files.
@item LIB
@file{configure.in} file. The warning occurs when creating
@code{configure} from @file{configure.in}, not when running
@code{configure}.
+
For example, @code{AC_PROG_CPP} checks whether the C compiler
can run the C preprocessor when given the @samp{-E} option. It should
therefore be called after any macros that change which C compiler is
@node Specifying Names, Canonicalizing, Manual Configuration, Manual Configuration
@section Specifying the System Type
-Like other GNU @code{configure} scripts, Autoconf-generated
+Like other @sc{gnu} @code{configure} scripts, Autoconf-generated
@code{configure} scripts can make decisions based on a canonical name
for the system type, which has the form:
and in @file{configure.in}, use:
@example
-AC_CONFIG_LINKS(host.h:config/$@{machine@}.h
- object.h:config/$@{obj_format@}.h)
+AC_CONFIG_LINKS(host.h:config/$machine.h
+ object.h:config/$obj_format.h)
@end example
You can also use the host system type to find cross-compilation tools.
--without-@var{package}
@end example
-For example, @samp{--with-gnu-ld} means work with the GNU linker instead
-of some other linker. @samp{--with-x} means work with The X Window
-System.
+For example, @samp{--with-gnu-ld} means work with the @sc{gnu} linker
+instead of some other linker. @samp{--with-x} means work with The X
+Window System.
The user can give an argument by following the package name with
@samp{=} and the argument. Giving an argument of @samp{no} is for
with a native Sun 4 assembler.
You can force a program name to begin with @file{g}, if you don't want
-GNU programs installed on your system to shadow other programs with the
-same name. For example, if you configure GNU @code{diff} with
+@sc{gnu} programs installed on your system to shadow other programs with
+the same name. For example, if you configure @sc{gnu} @code{diff} with
@samp{--program-prefix=g}, then when you run @samp{make install} it is
installed as @file{/usr/local/bin/gdiff}.
@noindent
to prepend @samp{g} to most of the program names in a source tree,
excepting those like @code{gdb} that already have one and those like
-@code{less} and @code{lesskey} that aren't GNU programs. (That is
+@code{less} and @code{lesskey} that aren't @sc{gnu} programs. (That is
assuming that you have a source tree containing those programs that is
set up to use this feature.)
you want to keep Autoconf version 1 around for awhile, you can configure
Autoconf version 2 using @samp{--program-suffix=2} to install the
programs as @file{/usr/local/bin/autoconf2},
-@file{/usr/local/bin/autoheader2}, etc.
+@file{/usr/local/bin/autoheader2}, etc. Nevertheless, pay attention
+that only the binaries are renamed, therefore you'd have problems with
+the library files which might overlap.
@node Transformation Rules, , Transformation Examples, Transforming Names
@subsection Transformation Rules
@file{Makefile.in}:
@example
-transform=@@program_transform_name@@
+transform = @@program_transform_name@@
install: all
$(INSTALL_PROGRAM) myprog $(bindir)/`echo myprog|sed '$(transform)'`
If you have more than one program to install, you can do it in a loop:
@example
-PROGRAMS=cp ls rm
+PROGRAMS = cp ls rm
install:
for p in $(PROGRAMS); do \
$(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(transform)'`; \
# Change some defaults.
test "$prefix" = NONE && prefix=/usr/share/local/gnu
test "$exec_prefix" = NONE && exec_prefix=/usr/local/gnu
-test "$sharedstatedir" = '$@{prefix@}/com' && sharedstatedir=/var
-test "$localstatedir" = '$@{prefix@}/var' && localstatedir=/var
-#
+test "$sharedstatedir" = '$prefix/com' && sharedstatedir=/var
+test "$localstatedir" = '$prefix/var' && localstatedir=/var
+
# Give Autoconf 2.x generated configure scripts a shared default
# cache file for feature test results, architecture-specific.
if test "$cache_file" = /dev/null; then
@file{configure.in} specifies, so it can be used for a different
package.
+@c Can't we just get rid of the following paragraphs? It's outdated stuff.
+
@defvar CONFIG_COMMANDS
@evindex CONFIG_COMMANDS
The tags of the commands to execute. The default is the arguments given
echo > stamp-h
Makefile: Makefile.in config.status
- CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_HEADERS= \
+ CONFIG_COMMANDS= CONFIG_LINKS= CONFIG_HEADERS= \
CONFIG_FILES=Makefile ./config.status
@end group
@end example
There are no restrictions on how the configuration scripts that Autoconf
produces may be distributed or used. In Autoconf version 1, they were
-covered by the GNU General Public License. We still encourage software
-authors to distribute their work under terms like those of the GPL, but
-doing so is not required to use Autoconf.
+covered by the @sc{gnu} General Public License. We still encourage
+software authors to distribute their work under terms like those of the
+GPL, but doing so is not required to use Autoconf.
Of the other files that might be used with @code{configure},
@file{config.h.in} is under whatever copyright you use for your
@file{install-sh} is from the X Consortium and is not copyrighted.
@node Why GNU m4, Bootstrapping, Distributing, Questions
-@section Why Require GNU @code{m4}?
+@section Why Require @sc{gnu} @code{m4}?
@display
-Why does Autoconf require GNU @code{m4}?
+Why does Autoconf require @sc{gnu} @code{m4}?
@end display
Many @code{m4} implementations have hard-coded limitations on the size
__line__
@end example
-Autoconf requires version 1.4 or above of GNU @code{m4} because it
+Autoconf requires version 1.4 or above of @sc{gnu} @code{m4} because it
uses frozen state files.
-Since only software maintainers need to use Autoconf, and since GNU
+Since only software maintainers need to use Autoconf, and since @sc{gnu}
@code{m4} is simple to configure and install, it seems reasonable to
-require GNU @code{m4} to be installed also. Many maintainers of GNU and
-other free software already have most of the GNU utilities installed,
-since they prefer them.
+require @sc{gnu} @code{m4} to be installed also. Many maintainers of
+@sc{gnu} and other free software already have most of the @sc{gnu}
+utilities installed, since they prefer them.
@node Bootstrapping, Why Not Imake, Why GNU m4, Questions
@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!
+If Autoconf requires @sc{gnu} @code{m4} and @sc{gnu} @code{m4} has an
+Autoconf @code{configure} script, how do I bootstrap? It seems like a
+chicken and egg problem!
@end display
-This is a misunderstanding. Although GNU @code{m4} does come with a
-@code{configure} script produced by Autoconf, Autoconf is not required
-in order to run the script and install GNU @code{m4}. Autoconf is only
-required if you want to change the @code{m4} @code{configure} script,
-which few people have to do (mainly its maintainer).
+This is a misunderstanding. Although @sc{gnu} @code{m4} does come with
+a @code{configure} script produced by Autoconf, Autoconf is not required
+in order to run the script and install @sc{gnu} @code{m4}. Autoconf is
+only required if you want to change the @code{m4} @code{configure}
+script, which few people have to do (mainly its maintainer).
@node Why Not Imake, , Bootstrapping, Questions
@section Why Not Imake?
sense because the distribution is made as a collection of tools, by one
central authority who has control over the database.
-GNU tools are not released this way. Each GNU tool has a maintainer;
-these maintainers are scattered across the world. Using a common
-database would be a maintenance nightmare. Autoconf may appear to be
-this kind of database, but in fact it is not. Instead of listing host
-dependencies, it lists program requirements.
+@sc{gnu} tools are not released this way. Each @sc{gnu} tool has a
+maintainer; these maintainers are scattered across the world. Using a
+common database would be a maintenance nightmare. Autoconf may appear
+to be this kind of database, but in fact it is not. Instead of listing
+host dependencies, it lists program requirements.
-If you view the GNU suite as a collection of native tools, then the
-problems are similar. But the GNU development tools can be configured
-as cross tools in almost any host+target permutation. All of these
-configurations can be installed concurrently. They can even be
+If you view the @sc{gnu} suite as a collection of native tools, then the
+problems are similar. But the @sc{gnu} development tools can be
+configured as cross tools in almost any host+target permutation. All of
+these configurations can be installed concurrently. They can even be
configured to share host independent files across hosts. Imake doesn't
address these issues.
-Imake templates are a form of standardization. The GNU coding standards
-address the same issues without necessarily imposing the same
+Imake templates are a form of standardization. The @sc{gnu} coding
+standards address the same issues without necessarily imposing the same
restrictions.
Here is some further explanation, written by Per Bothner:
version 2; the changes are summarized in the file @file{NEWS} in the
Autoconf distribution.
-First, make sure you have GNU @code{m4} version 1.1 or higher installed,
-preferably 1.3 or higher. Versions before 1.1 have bugs that prevent
-them from working with Autoconf version 2. Versions 1.3 and later are
-much faster than earlier versions, because as of version 1.3, GNU
-@code{m4} has a more efficient implementation of diversions and can
-freeze its internal state in a file that it can read back quickly.
+First, make sure you have @sc{gnu} @code{m4} version 1.1 or higher
+installed, preferably 1.3 or higher. Versions before 1.1 have bugs that
+prevent them from working with Autoconf version 2. Versions 1.3 and
+later are much faster than earlier versions, because as of version 1.3,
+@sc{gnu} @code{m4} has a more efficient implementation of diversions and
+can freeze its internal state in a file that it can read back quickly.
@menu
* Changed File Names:: Files you might rename
@example
prefix = /usr/local
-exec_prefix = $@{prefix@}
+exec_prefix = $(prefix)
@end example
@noindent
@node Genesis, Exodus, History, 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.
+In June 1991 I was maintaining many of the @sc{gnu} utilities for the
+Free Software Foundation. As they were ported to more platforms and
+more programs were added, the number of @samp{-D} options that users had
+to select in the @file{Makefile} (around 20) became burdensome.
+Especially for me---I had to test each new release on a bunch of
+different systems. So I wrote a little shell script to guess some of
+the correct settings for the fileutils package, and released it as part
+of fileutils 2.0. That @code{configure} script worked well enough that
+the next month I adapted it (by hand) to create similar @code{configure}
+scripts for several other @sc{gnu} utilities packages. Brian Berliner
+also adapted one of my scripts for his CVS revision control system.
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
+were developing similar scripts to use in the @sc{gnu} compiler tools;
+so I adapted my @code{configure} scripts to support their evolving
+interface: using the file name @file{Makefile.in} as the templates;
+adding @samp{+srcdir}, the first option (of many); and creating
@file{config.status} files.
@node Exodus, Leviticus, Genesis, History
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
+the scripts. As I adapted more @sc{gnu} utilities packages to use
@code{configure} scripts, updating them all by hand became impractical.
-Rich Murphey, the maintainer of the GNU graphics utilities, sent me mail
-saying that the @code{configure} scripts were great, and asking if I had
-a tool for generating them that I could send him. No, I thought, but
-I should! So I started to work out how to generate them. And the
+Rich Murphey, the maintainer of the @sc{gnu} graphics utilities, sent me
+mail saying that the @code{configure} scripts were great, and asking if
+I had a tool for generating them that I could send him. No, I thought,
+but I should! So I started to work out how to generate them. And the
journey from the slavery of hand-written @code{configure} scripts to the
abundance and ease of Autoconf began.
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
+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
+the @sc{gnu} extensions to @code{m4}.) Also, some of my friends at the
University of Maryland had recently been putting @code{m4} front ends on
several programs, including @code{tvtwm}, and I was interested in trying
out a new language.
Since my @code{configure} scripts determine the system's capabilities
automatically, with no interactive user intervention, I decided to call
the program that generates them Autoconfig. But with a version number
-tacked on, that name would be too long for old UNIX file systems, so
-I shortened it to Autoconf.
+tacked on, that name would be too long for old @sc{unix} file systems,
+so I shortened it to Autoconf.
In the fall of 1991 I called together a group of fellow questers after
the Holy Grail of portability (er, that is, alpha testers) to give me
@section Numbers
In July 1992, after months of alpha testing, I released Autoconf 1.0,
-and converted many GNU packages to use it. I was surprised by how
+and converted many @sc{gnu} packages to use it. I was surprised by how
positive the reaction to it was. More people started using it than I
could keep track of, including people working on software that wasn't
-part of the GNU Project (such as TCL, FSP, and Kerberos V5).
+part of the @sc{gnu} Project (such as TCL, FSP, and Kerberos V5).
Autoconf continued to improve rapidly, as many people using the
@code{configure} scripts reported problems they encountered.
Autoconf turned out to be a good torture test for @code{m4}
-implementations. 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. 4.3BSD @code{m4}, in
-particular, has an impoverished set of builtin macros; the System V
-version is better, but still doesn't provide everything we need.
+implementations. @sc{unix} @code{m4} started to dump core because of
+the length of the macros that Autoconf defined, and several bugs showed
+up in @sc{gnu} @code{m4} as well. Eventually, we realized that we
+needed to use some features that only @sc{gnu} @code{m4} has.
+4.3@sc{bsd} @code{m4}, in particular, has an impoverished set of builtin
+macros; the System V version is better, but still doesn't provide
+everything we need.
More development occurred as people put Autoconf under more stresses
(and to uses I hadn't anticipated). Karl Berry added checks for X11.
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. (He also coined the term @dfn{autoconfiscate} to
-mean ``adapt a software package to use Autoconf''.) Roland and Noah
-improved the quoting protection in @code{AC_DEFINE} and fixed many bugs,
-especially when I got sick of dealing with portability problems from
-February through June, 1993.
+it into configuring @sc{gnu} Emacs, laying the groundwork for several
+later improvements. Roland McGrath got it to configure the @sc{gnu} C
+Library, wrote the @code{autoheader} script to automate the creation of
+C header file templates, and added a @samp{--verbose} option to
+@code{configure}. Noah Friedman added the @samp{--macrodir} option and
+@code{AC_MACRODIR} environment variable. (He also coined the term
+@dfn{autoconfiscate} to mean ``adapt a software package to use
+Autoconf''.) Roland and Noah improved the quoting protection in
+@code{AC_DEFINE} and fixed many bugs, especially when I got sick of
+dealing with portability problems from February through June, 1993.
@node Deuteronomy, , Numbers, History
@section Deuteronomy
@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.
+@sc{gnu} @code{as}, and Rob Savoye to convert DejaGNU, to using
+Autoconf.
I added more features in response to other peoples' requests. Many
people had asked for @code{configure} scripts to share the results of
Fran\c cois
@end tex
Pinard, I made the macros not interrupt each others' messages. (That
-feature revealed some performance bottlenecks in GNU @code{m4}, which he
-hastily corrected!) I reorganized the documentation around problems
-people want to solve. And I began a test suite, because experience had
-shown that Autoconf has a pronounced tendency to regress when we change
-it.
+feature revealed some performance bottlenecks in @sc{gnu} @code{m4},
+which he hastily corrected!) I reorganized the documentation around
+problems people want to solve. And I began a test suite, because
+experience had shown that Autoconf has a pronounced tendency to regress
+when we change it.
Again, several alpha testers gave invaluable feedback, especially
@ifinfo
@defmac AC_DYNIX_SEQ
@maindex DYNIX_SEQ
-If on Dynix/PTX (Sequent UNIX), add @samp{-lseq} to output variable
+If on Dynix/PTX (Sequent @sc{unix}), add @samp{-lseq} to output variable
@code{LIBS}. This macro is obsolete; instead, use
@code{AC_FUNC_GETMNTENT}.
@end defmac
@defmac AC_IRIX_SUN
@maindex IRIX_SUN
-If on IRIX (Silicon Graphics UNIX), add @samp{-lsun} to output variable
-@code{LIBS}. This macro is obsolete. If you were using it to get
-@code{getmntent}, use @code{AC_FUNC_GETMNTENT} instead. If you used it
-for the NIS versions of the password and group functions, use
+If on IRIX (Silicon Graphics @sc{unix}), add @samp{-lsun} to output
+variable @code{LIBS}. This macro is obsolete. If you were using it to
+get @code{getmntent}, use @code{AC_FUNC_GETMNTENT} instead. If you used
+it for the NIS versions of the password and group functions, use
@samp{AC_CHECK_LIB(sun, getpwnam)}.
@end defmac
+@defmac AC_LANG_C
+@maindex LANG_C
+Same as @samp{AC_LANG(C)}.
+@end defmac
+
+@defmac AC_LANG_CPLUSPLUS
+@maindex LANG_CPLUSPLUS
+Same as @samp{AC_LANG(C++)}.
+@end defmac
+
+@defmac AC_LANG_FORTRAN77
+@maindex LANG_FORTRAN77
+Same as @samp{AC_LANG(Fortran 77)}.
+@end defmac
+
@defmac AC_LINK_FILES (@var{source}@dots{}, @var{dest}@dots{})
@maindex LINK_FILES
This is an obsolete version of @code{AC_CONFIG_LINKS}. An updated
version of:
@example
-@c Note that there are some @ in the first line, hence the indentation
-@c of the second.
-AC_LINK_FILES(config/$@{machine@}.h config/$@{obj_format@}.h,
- host.h object.h)
+AC_LINK_FILES(config/$machine.h config/$obj_format.h,
+ host.h object.h)
@end example
@noindent
is:
@example
-AC_CONFIG_LINKS(host.h:config/$@{machine@}.h
- object.h:config/$@{obj_format@}.h)
+AC_CONFIG_LINKS(host.h:config/$machine.h
+ object.h:config/$obj_format.h)
@end example
@end defmac
@defmac AC_SCO_INTL
@maindex SCO_INTL
@ovindex LIBS
-If on SCO UNIX, add @samp{-lintl} to output variable @code{LIBS}. Use
-@code{AC_FUNC_STRFTIME} instead.
+If on SCO @sc{unix}, add @samp{-lintl} to output variable @code{LIBS}.
+Use @code{AC_FUNC_STRFTIME} instead.
@end defmac
@defmac AC_SETVBUF_REVERSED
projects / thirdparty / autoconf.git / commitdiff
