EOF
# Transform confdefs.h into a sed script conftest.vals that substitutes
-# the proper values into config.h.in to produce config.h.
+# the proper values into config.h.in to produce config.h. And first:
+# Protect against being on the right side of a sed subst in config.status.
+# Protect against being in an unquoted here document in config.status.
rm -f conftest.vals
dnl Using a here document instead of a string reduces the quoting nightmare.
+dnl Putting comments in sed scripts is not portable.
cat > conftest.hdr <<\EOF
changequote(<<, >>)dnl
-# Protect against being on the right side of a sed subst in config.status.
s/[\\&%]/\\&/g
-# Protect against being in an unquoted here document in config.status.
s%[\\$`]%\\&%g
s%<<#define>> \([A-Za-z_][A-Za-z0-9_]*\) \(.*\)%${ac_dA}\1${ac_dB}\1${ac_dC}\2${ac_dD}%gp
s%ac_d%ac_u%gp
#endif
#ifdef __cplusplus
-extern "C" { char *valloc(int), *malloc(int); }
+extern "C" { void *valloc(unsigned), *malloc(unsigned); }
#else
char *valloc(), *malloc();
#endif
int i2 = getpagesize()*2;
int fd;
- buf1 = valloc(i2);
- buf2 = valloc(i);
- buf3 = malloc(i2);
+ buf1 = (char *)valloc(i2);
+ buf2 = (char *)valloc(i);
+ buf3 = (char *)malloc(i2);
for (j = 0; j < i2; ++j)
*(buf1 + j) = rand();
fd = open("conftestmmap", O_CREAT | O_RDWR, 0666);
[X_EXTRA_LIBS="$X_EXTRA_LIBS -ldnet_stub"])
fi
- # msh@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT.
+ # msh@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT,
+ # to get the SysV transport functions.
# Not sure which flavor of 386 Unix this is, but it seems harmless to
# check for it.
- AC_CHECK_LIB(nsl, main, [X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl"])
+ AC_CHECK_LIB(nsl, t_accept, [X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl"])
# lieder@skyler.mavd.honeywell.com says without -lsocket,
# socket/setsockopt and other routines are undefined under SCO ODT 2.0.
automatically to take advantage of the updated code.
Larry Wall's Metaconfig package is similar in purpose to Autoconf, but
-is more general. The scripts it produces require manual user
-intervention, which is quite inconvenient when configuring large source
-trees.
-
-Unlike Metaconfig scripts, Autoconf scripts can support cross-compiling,
-if some care is taken in writing them. They should avoid executing test
-programs, since test programs compiled with a cross-compiler can not be
-executed on the host system. Also, they shouldn't do anything that
-tests features of the host system instead of the target system.
+the scripts it produces require manual user intervention, which is quite
+inconvenient when configuring large source trees. Unlike Metaconfig
+scripts, Autoconf scripts can support cross-compiling, if some care is
+taken in writing them.
Autoconf imposes some restrictions on the names of macros used with
@code{#ifdef} in C programs (@pxref{Preprocessor Symbol Index}).
@end itemize
To create a @code{configure} script with Autoconf, you need to write an
-Autoconf input file (@file{configure.in}) and run Autoconf on it to
-produce the script. If you write your own feature tests to supplement
-those that come with Autoconf, you might also write a file called
-@file{aclocal.m4}. If you use a C header file to contain @code{#define}
+Autoconf input file @file{configure.in} and run @code{autoconf} on it.
+If you write your own feature tests to supplement those that come with
+Autoconf, you might also write files called @file{aclocal.m4} and
+@file{acsite.m4}. If you use a C header file to contain @code{#define}
directives, you might also write @file{acconfig.h}, @file{config.h.top},
and @file{config.h.bot}, and you will distribute the Autoconf-generated
file @file{config.h.in} with the package.
Files used in configuring a software package:
@example
@group
-configure* ------------.
+configure* ------------+-------------> config.cache
+ |
+ +-------------> config.log
|
[config.h.in] -. v .-> [config.h] -.
+--> config.status* -+ +--> make*
summary of the command-line options and exits.
@node Invoking autoscan, Invoking ifnames, Invoking autoheader, Making configure Scripts
-@section Invoking autoscan
+@section Invoking @code{autoscan}
The @code{autoscan} program can help you create a @file{configure.in}
file for a software package. @code{autoscan} examines source files in
renaming it to @file{configure.in}; it will probably need some
adjustments. If you want the package to use a configuration header
file, you will have to add a call to @code{AC_CONFIG_HEADER}. You might
-have to change or add some @code{#if} directives in order to make the
-package work with Autoconf (@pxref{Invoking ifnames}, for information
-about a program that might help with that job).
+have to change or add some @code{#if} directives to your program in
+order to make it work with Autoconf (@pxref{Invoking ifnames}, for
+information about a program that might help with that job).
@code{autoscan} uses several data files, which are installed with the
distributed Autoconf macro files, to determine which macros to output
@end table
@node Invoking ifnames, Invoking autoreconf, Invoking autoscan, Making configure Scripts
-@section Invoking ifnames
+@section Invoking @code{ifnames}
@code{ifnames} can help when writing a @file{configure.in} for a
software package. It prints the identifiers used in C preprocessor
conditionals. If a package has already been set up to have some
portability, this program can help you figure out what its
-@code{configure} needs to check for. It may fill in some gaps in a
+@code{configure} needs to check for. It may help fill in some gaps in a
@file{configure.in} generated by @code{autoscan} (@pxref{Invoking autoscan}).
@code{ifnames} scans all of the C source files named on the command line
@end table
@node Invoking autoreconf, Invoking autoupdate, Invoking ifnames, Making configure Scripts
-@section Invoking autoreconf
+@section Invoking @code{autoreconf}
If you have a lot of Autoconf-generated @code{configure} scripts and you
get a new version of Autoconf, the @code{autoreconf} program can be
@end table
@node Invoking autoupdate, , Invoking autoreconf, Making configure Scripts
-@section Invoking autoupdate
+@section Invoking @code{autoupdate}
The @code{autoupdate} program updates a @file{configure.in} file that
calls Autoconf macros by their old names to use the current macro names.
Purpose Macros}).
All of these macros that set @code{make} variables call @code{AC_SUBST}
-on those variables (@pxref{Setting Variables}, for details about
+on those variables to insert them into the output @file{Makefile} files
+(@pxref{Setting Variables}, for details about
@code{AC_SUBST}). The phrase ``define @var{name}'' is used below as a
shorthand to mean either add @samp{-D@var{name}=1} to the @code{make}
variable @code{DEFS}, or put @samp{#define @var{name} 1} in the
@section Alternative Programs
The following macros check for the presence or behavior of particular
-programs:
+programs. @xref{File Existence}, for how to check for programs not
+listed here.
@defmac AC_DECL_YYTEXT
@maindex DECL_YYTEXT
@defmac AC_PROG_CXX
@maindex PROG_CXX
Determine a C++ compiler to use. Check if the environment variable
-@var{CXX} or @var{CCC} (in that order) is set; if so, set @code{make}
+@code{CXX} or @code{CCC} (in that order) is set; if so, set @code{make}
variable @code{CXX} to its value. Otherwise search for a C++ compiler
under likely names (@code{c++}, @code{g++}, @code{gcc}, @code{CC}, and
@code{cxx}). If none of those checks succeed, as a last resort set
@maindex PROG_GCC_TRADITIONAL
Add @samp{-traditional} to @code{make} variable @code{CC} if using the
GNU C compiler and @code{ioctl} does not work properly without
-@samp{-traditional}. This macro calls @code{AC_PROG_CC} and
-@code{AC_PROG_CPP} if they haven't been called already.
+@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. This macro calls
+@code{AC_PROG_CC} and @code{AC_PROG_CPP} if they haven't been called
+already.
@end defmac
@defmac AC_PROG_INSTALL
@maindex PROG_INSTALL
-Set @code{make} variable @code{INSTALL} to @samp{install -c} if
-@code{install} is found and is compatible with the BSD and GNU versions.
+Set @code{make} variable @code{INSTALL} to the path of a 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}, where
it checks the directories specified to @code{AC_CONFIG_AUX_DIR} (or its
default directories) to determine @var{dir} (@pxref{Setup}).
-This macro screens out the false matches @file{/etc/install},
-@file{/usr/sbin/install}, and other instances of @code{install} known
-not to work. It also sets the variable @code{INSTALL_PROGRAM} to
+This macro screens out various instances of @code{install} known to not
+work. It also sets the variable @code{INSTALL_PROGRAM} to
@samp{$@{INSTALL@}} and @code{INSTALL_DATA} to @samp{$@{INSTALL@} -m
644}.
@node Header Files, Typedefs, Alternative Programs, Specific Tests
@section Header Files
-The following macros check for the presence of certain C header files:
+The following macros check for the presence of certain C header files.
+@xref{C Features}, for how to check for header files not listed here.
@defmac AC_DECL_SYS_SIGLIST
@maindex DECL_SYS_SIGLIST
functions) because many systems that have GCC do not have ANSI C header
files.
-To check whether to use the System V/ANSI C string functions and header
-file, you can put the following in @file{configure.in}:
+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
+@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}:
@example
AC_HEADER_STDC
-AC_CHECK_HEADERS(string.h memory.h)
+AC_CHECK_FUNCS(strchr memcpy)
@end example
@noindent
-Then, in the code, use a test like this:
+then, in your code, you can put declarations like this:
@example
@group
-/* memory.h might conflict with an ANSI string.h, or strings.h. */
-#if STDC_HEADERS || HAVE_STRING_H
+#if STDC_HEADERS
# include <string.h>
-# if !STDC_HEADERS && HAVE_MEMORY_H
-# include <memory.h>
-# endif
#else
-# include <strings.h>
-# ifndef strchr
+# ifndef HAVE_STRCHR
# define strchr index
-# endif
-# ifndef strrchr
# define strrchr rindex
# endif
-# ifndef memcpy
+char *strchr (), *strrchr ();
+# ifndef HAVE_MEMCPY
# define memcpy(d, s, n) bcopy ((s), (d), (n))
-# endif
-# ifndef memcmp
+# define memmove(d, s, n) bcopy ((s), (d), (n))
# define memcmp(s1, s2, n) bcmp ((s1), (s2), (n))
# endif
#endif
@end example
@noindent
-This example asssumes that your code uses the ANSI C/System V style
-functions. If you use the BSD style functions, replace the macro
-definitions with ones that go in the other direction. (Or, better,
-modernize your code.)
+If you use a function like @code{memchr}, @code{memset}, @code{strtok},
+or @code{strspn}, which have no 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}
+for example, put it in @file{memchr.c} and use
+@samp{AC_REPLACE_FUNCS(memchr)}.
This macro calls @code{AC_PROG_CPP} or @code{AC_PROG_CXXCPP} (depending
on which language is current, @pxref{Language Choice}), if it hasn't
@node Typedefs, Library Functions, Header Files, Specific Tests
@section Typedefs
-The following macros check for predefined C types:
+The following macros check for predefined C types.
+@xref{C Features}, for how to check for types not listed here.
@defmac AC_TYPE_GETGROUPS
@maindex TYPE_GETGROUPS
@node Library Functions, Structures, Typedefs, Specific Tests
@section Library Functions
-The following macros check for particular C library functions:
+The following macros check for particular C library functions.
+@xref{C Features}, for how to check for functions not listed here.
@defmac AC_FUNC_ALLOCA
@maindex FUNC_ALLOCA
@node Structures, Compiler Characteristics, Library Functions, Specific Tests
@section Structures
-The following macros check for certain structures or structure members:
+The following macros check for certain structures or structure members.
+You can use @code{AC_TRY_LINK} (@pxref{C System Output}) to check
+structures not listed here.
@defmac AC_HEADER_STAT
@maindex HEADER_STAT
@section Compiler Characteristics
The following macros check for C compiler or machine architecture
-features:
+features. You can use @code{AC_TRY_LINK} or @code{AC_TRY_RUN} (@pxref{C
+System Output}) to check for characteristics not listed here.
@defmac AC_C_BIGENDIAN
@maindex C_BIGENDIAN
@node System Services, UNIX Variants, Compiler Characteristics, Specific Tests
@section System Services
-The following macros check for operating system services:
+The following macros check for operating system services or capabilities.
@defmac AC_SYS_INTERPRETER
@maindex SYS_INTERPRETER
unless they are in directories the compiler searches by default.
If both methods fail, or the user gave the command line option
-@samp{--without-x}, set the shell variable @code{no_x} to @samp{true};
+@samp{--without-x}, set the shell variable @code{no_x} to @samp{yes};
otherwise set it to the empty string.
The command line options @samp{--x-includes=@var{dir}} and
@defmac AC_COMPILE_CHECK (@var{echo-text}, @var{includes}, @var{function-body}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]})
@maindex COMPILE_CHECK
This is an obsolete alias for @code{AC_TRY_LINK}, with the addition that it
-prints @samp{checking for @var{echo-text}} to the standard output first.
+prints @samp{checking for @var{echo-text}} to the standard output first,
+if @var{echo-text} is non-empty.
@end defmac
@defmac AC_EGREP_CPP (@var{pattern}, @var{program}, @var{action-if-found} @r{[}, @var{action-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-editing support fancy command line editing
@end example
@noindent
@var{help-string} may be more than one line long, if more detail is
@var{value} should not contain literal newlines, and if you are not
using @code{AC_CONFIG_HEADER} it should not contain any @samp{#}
characters, as @code{make} tends to eat them. To use a shell variable
-or a value containing the @code{m4} quote characters @samp{[} or
-@samp{]}, use @code{AC_DEFINE_UNQUOTED} instead.
+(which you need to do in order to define a value containing the
+@code{m4} quote characters @samp{[} or @samp{]}), use
+@code{AC_DEFINE_UNQUOTED} instead.
@code{AC_OUTPUT} substitutes the values defined by this macro as the
variable @code{DEFS} in the file(s) that it generates (typically
Like @code{AC_DEFINE}, but three shell expansions are performed once on
@var{value}: variable expansion (@samp{$}), command substitution
(@samp{`}), and backslash escaping (@samp{\}). Use this macro instead
-of @code{AC_DEFINE} when @var{value} contains a shell variable. For
+of @code{AC_DEFINE} when @var{value} is a shell variable. For
example:
@example
@defmac AC_VERBOSE (@var{result-description})
@maindex VERBOSE
-This macro is similar to @code{AC_MSG_RESULT}, except that it is meant to
-follow a call to @code{AC_CHECKING} instead of @code{AC_MSG_CHECKING}.
-It is considered obsolete.
+This macro is similar to @code{AC_MSG_RESULT}, except that it is meant
+to follow a call to @code{AC_CHECKING} instead of
+@code{AC_MSG_CHECKING}; it starts the message it prints with a tab. It
+is considered obsolete.
@end defmac
@node Language Choice, Macro Ordering, Printing Messages, General Purpose Macros
@end menu
@node Specifying Names, Canonicalizing, , Manual Configuration
-@section Specifying The System Type
+@section Specifying the System Type
Like other GNU @code{configure} scripts, Autoconf-generated
@code{configure} scripts can make decisions based on a canonical name
@table @code
@item --build=@var{build-type}
the type of system on which the package is being configured and
-compiled;
+compiled (rarely needed);
@item --host=@var{host-type}
the type of system on which the package will run;
@code{config.sub} to canonicalize system type aliases.
@node Canonicalizing, System Name Variables, Specifying Names, Manual Configuration
-@section Getting The Canonical System Type
+@section Getting the Canonical System Type
The following macros make the name of the system type available in
@code{configure} scripts.
@node System Name Variables, Using System Type, Canonicalizing, Manual Configuration
@section System Name Variables
-The shell and @code{make} variables that contain the system type
+After calling @code{AC_CANONICAL_SYSTEM} or @code{AC_CANONICAL_HOST},
+the the shell and @code{make} variables that contain the system type
information are:
@table @code
@end table
@node Using System Type, , System Name Variables, Manual Configuration
-@section Using The System Type
+@section Using the System Type
How do you use a canonical system type? Usually, you use it in one or
more @code{case} statements in @file{configure.in} to select
few places the macros need to use brackets (usually in C program text or
regular expressions). In those places, they use the @code{m4} builtin
command @code{changequote} to temporarily change the quote characters to
-@samp{<<} and @samp{>>}. Sometimes, if they don't need to quote
-anything, they disable quoting entirely instead. Here is an example:
+@samp{<<} and @samp{>>}. (Sometimes, if they don't need to quote
+anything, they disable quoting entirely instead by setting the quote
+characters to empty strings.) Here is an example:
@example
AC_TRY_LINK(
it's really best that you test for a run-time behavior, try to provide a
default ``worst case'' value to use when cross-compiling makes run-time
tests impossible. You do this by passing the optional last argument to
-@code{AC_TRY_RUN}.
+@code{AC_TRY_RUN}. To configure for cross-compiling you can also set up
+a test results cache file with the correct values for the target system
+(@pxref{Caching Values}). But that is a last resort. Alternatively,
+choose a value for those parameters based on the canonical system name
+(@pxref{Manual Configuration}).
+
+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.
@menu
* Guidelines:: General rules for writing test programs.
@example
#ifdef __cplusplus
-extern "C" char *malloc(int);
+extern "C" void *malloc(size_t);
#else
char *malloc();
#endif
Ensure that the results of the check identified by @var{cache-id} are
available. If the results of the check were in the cache file that was
read, and @code{configure} was not given the @samp{--quiet} or
-@samp{--silent} option, print a message saying so; otherwise, run the
-shell commands @var{commands-to-set-it}. Those commands should have no
-side effects except for setting the variable @var{cache-id}. In
-particular, they should not call @code{AC_DEFINE}; the code that follows
-the call to @code{AC_CACHE_VAL} should do that, based on the cached
-value. Also, they should not print any messages, for example with
-@code{AC_MSG_CHECKING}; do that before calling @code{AC_CACHE_VAL}, so
-the messages are printed regardless of whether the results of the check
-are retrieved from the cache or determined by running the shell
-commands. If the shell commands are run to determine the value, the
-value will be saved in the cache file just before @code{configure}
-creates its output files.
+@samp{--silent} option, print a message saying that the result was
+cached; otherwise, run the shell commands @var{commands-to-set-it}.
+Those commands should have no side effects except for setting the
+variable @var{cache-id}. In particular, they should not call
+@code{AC_DEFINE}; the code that follows the call to @code{AC_CACHE_VAL}
+should do that, based on the cached value. Also, they should not print
+any messages, for example with @code{AC_MSG_CHECKING}; do that before
+calling @code{AC_CACHE_VAL}, so the messages are printed regardless of
+whether the results of the check are retrieved from the cache or
+determined by running the shell commands. If the shell commands are run
+to determine the value, the value will be saved in the cache file just
+before @code{configure} creates its output files. @xref{Cache
+Variables}, for how to choose the name of the @var{cache-id} variable.
@end defmac
@menu
@node Cache Files, Cache Variables, , Caching Values
@section Cache Files
-The cache file is a shell script that caches the results of configure
+A cache file is a shell script that caches the results of configure
tests run on one system so they can be shared between configure scripts
and configure runs. It is not useful on other systems. If its contents
are invalid for some reason, the user may delete or edit it.
nonexistent. Running @code{configure} merges the new cache results with
the existing cache file. The site initialization script can specify a
site-wide cache file to use instead of the default, to make it work
-transparently (@pxref{Site Default Values}).
+transparently, as long as the same C compiler is used every time
+(@pxref{Site Default Values}).
@node Cache Variables, , Cache Files, Caching Values
@section Cache Variables
@defvar CFLAGS
Debugging and optimization options for the C compiler. If it is not set
in the environment when @code{configure} runs, the default value is set
-by @code{AC_PROG_CC} (empty if you don't). @code{configure} uses this
-variable when compiling programs to test for C features.
+when you call @code{AC_PROG_CC} (or empty if you don't). @code{configure}
+uses this variable when compiling programs to test for C features.
@end defvar
@defvar CPPFLAGS
@defvar CXXFLAGS
Debugging and optimization options for the C++ compiler. If it is not
set in the environment when @code{configure} runs, the default value is
-set by @code{AC_PROG_CXX} (empty if you don't). @code{configure} uses
-this variable when compiling programs to test for C++ features.
+set when you call @code{AC_PROG_CXX} (or empty if you don't).
+@code{configure} uses this variable when compiling programs to test for
+C++ features.
@end defvar
@defvar DEFS
itself. This option is useful if you change @code{configure}, so that
the results of some tests might be different from the previous run. The
@samp{--recheck} option re-runs @code{configure} with the same arguments
-you used before, plus the @samp{--no-create} option, which prevents
+you used before, plus the @samp{--no-create} option, which prevent
@code{configure} from running @file{config.status} and creating
-@file{Makefile} and other files. (This is so other @file{Makefile}
-rules can run @file{config.status} when it changes; @pxref{Automatic
-Remaking}, for an example).
+@file{Makefile} and other files, and the @samp{--norecursion} option,
+which prevents @code{configure} from running other @code{configure}
+scripts in subdirectories. (This is so other @file{Makefile} rules can
+run @file{config.status} when it changes; @pxref{Automatic Remaking},
+for an example).
@file{config.status} also accepts the options @samp{--help}, which
prints a summary of the options to @file{config.status}, and
If the environment variable @code{CONFIG_SITE} is set and contains the
name of a readable file, @code{configure} reads that file as a shell
script. Otherwise, it reads the shell script
-@file{@var{exec_prefix}/lib/config.site} if it exists, then
-@file{@var{prefix}/lib/config.site} if it exists. Thus, settings in
+@file{@var{prefix}/lib/config.site} if it exists, then
+@file{@var{exec_prefix}/lib/config.site} if it exists. Thus, settings in
system dependent files override those in system independent ones in case
of conflict. @code{configure} reads any cache file after it has read
any site files. This way, the site file can define a default cache
scripts run on that system.
Site files can be arbitrary shell scripts, but only certain kinds of
-code are really appropriate to be in them. Besides a cache file, they
-are good places to set default values for other shell variables like
-@code{CC}, if you need to give them unusual values: anything you would
-normally do, repetitively, on the command line. If you use non-default
-values for @var{prefix} or @var{exec_prefix} (wherever you locate the
-site file), you can set them in the site file if you specify it with the
-@code{CONFIG_SITE} environment variable.
+code are really appropriate to be in them. Besides selecting a cache
+file, they are good places to set default values for other shell
+variables like @code{CC}, if you need to give them unusual values:
+anything you would normally do, repetitively, on the command line. If
+you use non-default values for @var{prefix} or @var{exec_prefix}
+(wherever you locate the site file), you can set them in the site file
+if you specify it with the @code{CONFIG_SITE} environment variable.
It is possible to set some cache values in the site file.
If you are cross-compiling, it is impossible to check features that
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
+support some of the ugly things in version 1. So, depending on how
sophisticated your @file{configure.in} files are, you might have to do
some manual work in order to upgrade to version 2. This chapter points
out some problems to watch for when upgrading. Also, perhaps your
@code{configure} scripts could benefit from some of the new features in
-version 2; see the @file{NEWS} file in the distribution for a summary.
+version 2.
@menu
* Changed File Names:: Files you might rename.
@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}.
+backslashes before quotes, 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
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.
+then let there be light@dots{}
@menu
* Genesis:: Prehistory and naming of @code{configure}.
to distribute all of the feature tests with every package, so I settled
on having a different @code{configure} made from each
@file{configure.in} by a preprocessor. That approach also offered more
-control and flexibility
+control and flexibility.
I looked briefly into using Larry Wall's Metaconfig program, but I
decided not to for several reasons. The @code{Configure} scripts it
@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
+and converted many GNU packages to use it. I was surprised by how
positive the reaction to it was. More people started using it than I
could keep track of, including people working on software that wasn't
part of the GNU Project (such as TCL, FSP, @TeX{}, and Kerberos v5).
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
+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.
automatically to take advantage of the updated code.
Larry Wall's Metaconfig package is similar in purpose to Autoconf, but
-is more general. The scripts it produces require manual user
-intervention, which is quite inconvenient when configuring large source
-trees.
-
-Unlike Metaconfig scripts, Autoconf scripts can support cross-compiling,
-if some care is taken in writing them. They should avoid executing test
-programs, since test programs compiled with a cross-compiler can not be
-executed on the host system. Also, they shouldn't do anything that
-tests features of the host system instead of the target system.
+the scripts it produces require manual user intervention, which is quite
+inconvenient when configuring large source trees. Unlike Metaconfig
+scripts, Autoconf scripts can support cross-compiling, if some care is
+taken in writing them.
Autoconf imposes some restrictions on the names of macros used with
@code{#ifdef} in C programs (@pxref{Preprocessor Symbol Index}).
@end itemize
To create a @code{configure} script with Autoconf, you need to write an
-Autoconf input file (@file{configure.in}) and run Autoconf on it to
-produce the script. If you write your own feature tests to supplement
-those that come with Autoconf, you might also write a file called
-@file{aclocal.m4}. If you use a C header file to contain @code{#define}
+Autoconf input file @file{configure.in} and run @code{autoconf} on it.
+If you write your own feature tests to supplement those that come with
+Autoconf, you might also write files called @file{aclocal.m4} and
+@file{acsite.m4}. If you use a C header file to contain @code{#define}
directives, you might also write @file{acconfig.h}, @file{config.h.top},
and @file{config.h.bot}, and you will distribute the Autoconf-generated
file @file{config.h.in} with the package.
Files used in configuring a software package:
@example
@group
-configure* ------------.
+configure* ------------+-------------> config.cache
+ |
+ +-------------> config.log
|
[config.h.in] -. v .-> [config.h] -.
+--> config.status* -+ +--> make*
summary of the command-line options and exits.
@node Invoking autoscan, Invoking ifnames, Invoking autoheader, Making configure Scripts
-@section Invoking autoscan
+@section Invoking @code{autoscan}
The @code{autoscan} program can help you create a @file{configure.in}
file for a software package. @code{autoscan} examines source files in
renaming it to @file{configure.in}; it will probably need some
adjustments. If you want the package to use a configuration header
file, you will have to add a call to @code{AC_CONFIG_HEADER}. You might
-have to change or add some @code{#if} directives in order to make the
-package work with Autoconf (@pxref{Invoking ifnames}, for information
-about a program that might help with that job).
+have to change or add some @code{#if} directives to your program in
+order to make it work with Autoconf (@pxref{Invoking ifnames}, for
+information about a program that might help with that job).
@code{autoscan} uses several data files, which are installed with the
distributed Autoconf macro files, to determine which macros to output
@end table
@node Invoking ifnames, Invoking autoreconf, Invoking autoscan, Making configure Scripts
-@section Invoking ifnames
+@section Invoking @code{ifnames}
@code{ifnames} can help when writing a @file{configure.in} for a
software package. It prints the identifiers used in C preprocessor
conditionals. If a package has already been set up to have some
portability, this program can help you figure out what its
-@code{configure} needs to check for. It may fill in some gaps in a
+@code{configure} needs to check for. It may help fill in some gaps in a
@file{configure.in} generated by @code{autoscan} (@pxref{Invoking autoscan}).
@code{ifnames} scans all of the C source files named on the command line
@end table
@node Invoking autoreconf, Invoking autoupdate, Invoking ifnames, Making configure Scripts
-@section Invoking autoreconf
+@section Invoking @code{autoreconf}
If you have a lot of Autoconf-generated @code{configure} scripts and you
get a new version of Autoconf, the @code{autoreconf} program can be
@end table
@node Invoking autoupdate, , Invoking autoreconf, Making configure Scripts
-@section Invoking autoupdate
+@section Invoking @code{autoupdate}
The @code{autoupdate} program updates a @file{configure.in} file that
calls Autoconf macros by their old names to use the current macro names.
Purpose Macros}).
All of these macros that set @code{make} variables call @code{AC_SUBST}
-on those variables (@pxref{Setting Variables}, for details about
+on those variables to insert them into the output @file{Makefile} files
+(@pxref{Setting Variables}, for details about
@code{AC_SUBST}). The phrase ``define @var{name}'' is used below as a
shorthand to mean either add @samp{-D@var{name}=1} to the @code{make}
variable @code{DEFS}, or put @samp{#define @var{name} 1} in the
@section Alternative Programs
The following macros check for the presence or behavior of particular
-programs:
+programs. @xref{File Existence}, for how to check for programs not
+listed here.
@defmac AC_DECL_YYTEXT
@maindex DECL_YYTEXT
@defmac AC_PROG_CXX
@maindex PROG_CXX
Determine a C++ compiler to use. Check if the environment variable
-@var{CXX} or @var{CCC} (in that order) is set; if so, set @code{make}
+@code{CXX} or @code{CCC} (in that order) is set; if so, set @code{make}
variable @code{CXX} to its value. Otherwise search for a C++ compiler
under likely names (@code{c++}, @code{g++}, @code{gcc}, @code{CC}, and
@code{cxx}). If none of those checks succeed, as a last resort set
@maindex PROG_GCC_TRADITIONAL
Add @samp{-traditional} to @code{make} variable @code{CC} if using the
GNU C compiler and @code{ioctl} does not work properly without
-@samp{-traditional}. This macro calls @code{AC_PROG_CC} and
-@code{AC_PROG_CPP} if they haven't been called already.
+@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. This macro calls
+@code{AC_PROG_CC} and @code{AC_PROG_CPP} if they haven't been called
+already.
@end defmac
@defmac AC_PROG_INSTALL
@maindex PROG_INSTALL
-Set @code{make} variable @code{INSTALL} to @samp{install -c} if
-@code{install} is found and is compatible with the BSD and GNU versions.
+Set @code{make} variable @code{INSTALL} to the path of a 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}, where
it checks the directories specified to @code{AC_CONFIG_AUX_DIR} (or its
default directories) to determine @var{dir} (@pxref{Setup}).
-This macro screens out the false matches @file{/etc/install},
-@file{/usr/sbin/install}, and other instances of @code{install} known
-not to work. It also sets the variable @code{INSTALL_PROGRAM} to
+This macro screens out various instances of @code{install} known to not
+work. It also sets the variable @code{INSTALL_PROGRAM} to
@samp{$@{INSTALL@}} and @code{INSTALL_DATA} to @samp{$@{INSTALL@} -m
644}.
@node Header Files, Typedefs, Alternative Programs, Specific Tests
@section Header Files
-The following macros check for the presence of certain C header files:
+The following macros check for the presence of certain C header files.
+@xref{C Features}, for how to check for header files not listed here.
@defmac AC_DECL_SYS_SIGLIST
@maindex DECL_SYS_SIGLIST
functions) because many systems that have GCC do not have ANSI C header
files.
-To check whether to use the System V/ANSI C string functions and header
-file, you can put the following in @file{configure.in}:
+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
+@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}:
@example
AC_HEADER_STDC
-AC_CHECK_HEADERS(string.h memory.h)
+AC_CHECK_FUNCS(strchr memcpy)
@end example
@noindent
-Then, in the code, use a test like this:
+then, in your code, you can put declarations like this:
@example
@group
-/* memory.h might conflict with an ANSI string.h, or strings.h. */
-#if STDC_HEADERS || HAVE_STRING_H
+#if STDC_HEADERS
# include <string.h>
-# if !STDC_HEADERS && HAVE_MEMORY_H
-# include <memory.h>
-# endif
#else
-# include <strings.h>
-# ifndef strchr
+# ifndef HAVE_STRCHR
# define strchr index
-# endif
-# ifndef strrchr
# define strrchr rindex
# endif
-# ifndef memcpy
+char *strchr (), *strrchr ();
+# ifndef HAVE_MEMCPY
# define memcpy(d, s, n) bcopy ((s), (d), (n))
-# endif
-# ifndef memcmp
+# define memmove(d, s, n) bcopy ((s), (d), (n))
# define memcmp(s1, s2, n) bcmp ((s1), (s2), (n))
# endif
#endif
@end example
@noindent
-This example asssumes that your code uses the ANSI C/System V style
-functions. If you use the BSD style functions, replace the macro
-definitions with ones that go in the other direction. (Or, better,
-modernize your code.)
+If you use a function like @code{memchr}, @code{memset}, @code{strtok},
+or @code{strspn}, which have no 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}
+for example, put it in @file{memchr.c} and use
+@samp{AC_REPLACE_FUNCS(memchr)}.
This macro calls @code{AC_PROG_CPP} or @code{AC_PROG_CXXCPP} (depending
on which language is current, @pxref{Language Choice}), if it hasn't
@node Typedefs, Library Functions, Header Files, Specific Tests
@section Typedefs
-The following macros check for predefined C types:
+The following macros check for predefined C types.
+@xref{C Features}, for how to check for types not listed here.
@defmac AC_TYPE_GETGROUPS
@maindex TYPE_GETGROUPS
@node Library Functions, Structures, Typedefs, Specific Tests
@section Library Functions
-The following macros check for particular C library functions:
+The following macros check for particular C library functions.
+@xref{C Features}, for how to check for functions not listed here.
@defmac AC_FUNC_ALLOCA
@maindex FUNC_ALLOCA
@node Structures, Compiler Characteristics, Library Functions, Specific Tests
@section Structures
-The following macros check for certain structures or structure members:
+The following macros check for certain structures or structure members.
+You can use @code{AC_TRY_LINK} (@pxref{C System Output}) to check
+structures not listed here.
@defmac AC_HEADER_STAT
@maindex HEADER_STAT
@section Compiler Characteristics
The following macros check for C compiler or machine architecture
-features:
+features. You can use @code{AC_TRY_LINK} or @code{AC_TRY_RUN} (@pxref{C
+System Output}) to check for characteristics not listed here.
@defmac AC_C_BIGENDIAN
@maindex C_BIGENDIAN
@node System Services, UNIX Variants, Compiler Characteristics, Specific Tests
@section System Services
-The following macros check for operating system services:
+The following macros check for operating system services or capabilities.
@defmac AC_SYS_INTERPRETER
@maindex SYS_INTERPRETER
unless they are in directories the compiler searches by default.
If both methods fail, or the user gave the command line option
-@samp{--without-x}, set the shell variable @code{no_x} to @samp{true};
+@samp{--without-x}, set the shell variable @code{no_x} to @samp{yes};
otherwise set it to the empty string.
The command line options @samp{--x-includes=@var{dir}} and
@defmac AC_COMPILE_CHECK (@var{echo-text}, @var{includes}, @var{function-body}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]})
@maindex COMPILE_CHECK
This is an obsolete alias for @code{AC_TRY_LINK}, with the addition that it
-prints @samp{checking for @var{echo-text}} to the standard output first.
+prints @samp{checking for @var{echo-text}} to the standard output first,
+if @var{echo-text} is non-empty.
@end defmac
@defmac AC_EGREP_CPP (@var{pattern}, @var{program}, @var{action-if-found} @r{[}, @var{action-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-editing support fancy command line editing
@end example
@noindent
@var{help-string} may be more than one line long, if more detail is
@var{value} should not contain literal newlines, and if you are not
using @code{AC_CONFIG_HEADER} it should not contain any @samp{#}
characters, as @code{make} tends to eat them. To use a shell variable
-or a value containing the @code{m4} quote characters @samp{[} or
-@samp{]}, use @code{AC_DEFINE_UNQUOTED} instead.
+(which you need to do in order to define a value containing the
+@code{m4} quote characters @samp{[} or @samp{]}), use
+@code{AC_DEFINE_UNQUOTED} instead.
@code{AC_OUTPUT} substitutes the values defined by this macro as the
variable @code{DEFS} in the file(s) that it generates (typically
Like @code{AC_DEFINE}, but three shell expansions are performed once on
@var{value}: variable expansion (@samp{$}), command substitution
(@samp{`}), and backslash escaping (@samp{\}). Use this macro instead
-of @code{AC_DEFINE} when @var{value} contains a shell variable. For
+of @code{AC_DEFINE} when @var{value} is a shell variable. For
example:
@example
@defmac AC_VERBOSE (@var{result-description})
@maindex VERBOSE
-This macro is similar to @code{AC_MSG_RESULT}, except that it is meant to
-follow a call to @code{AC_CHECKING} instead of @code{AC_MSG_CHECKING}.
-It is considered obsolete.
+This macro is similar to @code{AC_MSG_RESULT}, except that it is meant
+to follow a call to @code{AC_CHECKING} instead of
+@code{AC_MSG_CHECKING}; it starts the message it prints with a tab. It
+is considered obsolete.
@end defmac
@node Language Choice, Macro Ordering, Printing Messages, General Purpose Macros
@end menu
@node Specifying Names, Canonicalizing, , Manual Configuration
-@section Specifying The System Type
+@section Specifying the System Type
Like other GNU @code{configure} scripts, Autoconf-generated
@code{configure} scripts can make decisions based on a canonical name
@table @code
@item --build=@var{build-type}
the type of system on which the package is being configured and
-compiled;
+compiled (rarely needed);
@item --host=@var{host-type}
the type of system on which the package will run;
@code{config.sub} to canonicalize system type aliases.
@node Canonicalizing, System Name Variables, Specifying Names, Manual Configuration
-@section Getting The Canonical System Type
+@section Getting the Canonical System Type
The following macros make the name of the system type available in
@code{configure} scripts.
@node System Name Variables, Using System Type, Canonicalizing, Manual Configuration
@section System Name Variables
-The shell and @code{make} variables that contain the system type
+After calling @code{AC_CANONICAL_SYSTEM} or @code{AC_CANONICAL_HOST},
+the the shell and @code{make} variables that contain the system type
information are:
@table @code
@end table
@node Using System Type, , System Name Variables, Manual Configuration
-@section Using The System Type
+@section Using the System Type
How do you use a canonical system type? Usually, you use it in one or
more @code{case} statements in @file{configure.in} to select
few places the macros need to use brackets (usually in C program text or
regular expressions). In those places, they use the @code{m4} builtin
command @code{changequote} to temporarily change the quote characters to
-@samp{<<} and @samp{>>}. Sometimes, if they don't need to quote
-anything, they disable quoting entirely instead. Here is an example:
+@samp{<<} and @samp{>>}. (Sometimes, if they don't need to quote
+anything, they disable quoting entirely instead by setting the quote
+characters to empty strings.) Here is an example:
@example
AC_TRY_LINK(
it's really best that you test for a run-time behavior, try to provide a
default ``worst case'' value to use when cross-compiling makes run-time
tests impossible. You do this by passing the optional last argument to
-@code{AC_TRY_RUN}.
+@code{AC_TRY_RUN}. To configure for cross-compiling you can also set up
+a test results cache file with the correct values for the target system
+(@pxref{Caching Values}). But that is a last resort. Alternatively,
+choose a value for those parameters based on the canonical system name
+(@pxref{Manual Configuration}).
+
+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.
@menu
* Guidelines:: General rules for writing test programs.
@example
#ifdef __cplusplus
-extern "C" char *malloc(int);
+extern "C" void *malloc(size_t);
#else
char *malloc();
#endif
Ensure that the results of the check identified by @var{cache-id} are
available. If the results of the check were in the cache file that was
read, and @code{configure} was not given the @samp{--quiet} or
-@samp{--silent} option, print a message saying so; otherwise, run the
-shell commands @var{commands-to-set-it}. Those commands should have no
-side effects except for setting the variable @var{cache-id}. In
-particular, they should not call @code{AC_DEFINE}; the code that follows
-the call to @code{AC_CACHE_VAL} should do that, based on the cached
-value. Also, they should not print any messages, for example with
-@code{AC_MSG_CHECKING}; do that before calling @code{AC_CACHE_VAL}, so
-the messages are printed regardless of whether the results of the check
-are retrieved from the cache or determined by running the shell
-commands. If the shell commands are run to determine the value, the
-value will be saved in the cache file just before @code{configure}
-creates its output files.
+@samp{--silent} option, print a message saying that the result was
+cached; otherwise, run the shell commands @var{commands-to-set-it}.
+Those commands should have no side effects except for setting the
+variable @var{cache-id}. In particular, they should not call
+@code{AC_DEFINE}; the code that follows the call to @code{AC_CACHE_VAL}
+should do that, based on the cached value. Also, they should not print
+any messages, for example with @code{AC_MSG_CHECKING}; do that before
+calling @code{AC_CACHE_VAL}, so the messages are printed regardless of
+whether the results of the check are retrieved from the cache or
+determined by running the shell commands. If the shell commands are run
+to determine the value, the value will be saved in the cache file just
+before @code{configure} creates its output files. @xref{Cache
+Variables}, for how to choose the name of the @var{cache-id} variable.
@end defmac
@menu
@node Cache Files, Cache Variables, , Caching Values
@section Cache Files
-The cache file is a shell script that caches the results of configure
+A cache file is a shell script that caches the results of configure
tests run on one system so they can be shared between configure scripts
and configure runs. It is not useful on other systems. If its contents
are invalid for some reason, the user may delete or edit it.
nonexistent. Running @code{configure} merges the new cache results with
the existing cache file. The site initialization script can specify a
site-wide cache file to use instead of the default, to make it work
-transparently (@pxref{Site Default Values}).
+transparently, as long as the same C compiler is used every time
+(@pxref{Site Default Values}).
@node Cache Variables, , Cache Files, Caching Values
@section Cache Variables
@defvar CFLAGS
Debugging and optimization options for the C compiler. If it is not set
in the environment when @code{configure} runs, the default value is set
-by @code{AC_PROG_CC} (empty if you don't). @code{configure} uses this
-variable when compiling programs to test for C features.
+when you call @code{AC_PROG_CC} (or empty if you don't). @code{configure}
+uses this variable when compiling programs to test for C features.
@end defvar
@defvar CPPFLAGS
@defvar CXXFLAGS
Debugging and optimization options for the C++ compiler. If it is not
set in the environment when @code{configure} runs, the default value is
-set by @code{AC_PROG_CXX} (empty if you don't). @code{configure} uses
-this variable when compiling programs to test for C++ features.
+set when you call @code{AC_PROG_CXX} (or empty if you don't).
+@code{configure} uses this variable when compiling programs to test for
+C++ features.
@end defvar
@defvar DEFS
itself. This option is useful if you change @code{configure}, so that
the results of some tests might be different from the previous run. The
@samp{--recheck} option re-runs @code{configure} with the same arguments
-you used before, plus the @samp{--no-create} option, which prevents
+you used before, plus the @samp{--no-create} option, which prevent
@code{configure} from running @file{config.status} and creating
-@file{Makefile} and other files. (This is so other @file{Makefile}
-rules can run @file{config.status} when it changes; @pxref{Automatic
-Remaking}, for an example).
+@file{Makefile} and other files, and the @samp{--norecursion} option,
+which prevents @code{configure} from running other @code{configure}
+scripts in subdirectories. (This is so other @file{Makefile} rules can
+run @file{config.status} when it changes; @pxref{Automatic Remaking},
+for an example).
@file{config.status} also accepts the options @samp{--help}, which
prints a summary of the options to @file{config.status}, and
If the environment variable @code{CONFIG_SITE} is set and contains the
name of a readable file, @code{configure} reads that file as a shell
script. Otherwise, it reads the shell script
-@file{@var{exec_prefix}/lib/config.site} if it exists, then
-@file{@var{prefix}/lib/config.site} if it exists. Thus, settings in
+@file{@var{prefix}/lib/config.site} if it exists, then
+@file{@var{exec_prefix}/lib/config.site} if it exists. Thus, settings in
system dependent files override those in system independent ones in case
of conflict. @code{configure} reads any cache file after it has read
any site files. This way, the site file can define a default cache
scripts run on that system.
Site files can be arbitrary shell scripts, but only certain kinds of
-code are really appropriate to be in them. Besides a cache file, they
-are good places to set default values for other shell variables like
-@code{CC}, if you need to give them unusual values: anything you would
-normally do, repetitively, on the command line. If you use non-default
-values for @var{prefix} or @var{exec_prefix} (wherever you locate the
-site file), you can set them in the site file if you specify it with the
-@code{CONFIG_SITE} environment variable.
+code are really appropriate to be in them. Besides selecting a cache
+file, they are good places to set default values for other shell
+variables like @code{CC}, if you need to give them unusual values:
+anything you would normally do, repetitively, on the command line. If
+you use non-default values for @var{prefix} or @var{exec_prefix}
+(wherever you locate the site file), you can set them in the site file
+if you specify it with the @code{CONFIG_SITE} environment variable.
It is possible to set some cache values in the site file.
If you are cross-compiling, it is impossible to check features that
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
+support some of the ugly things in version 1. So, depending on how
sophisticated your @file{configure.in} files are, you might have to do
some manual work in order to upgrade to version 2. This chapter points
out some problems to watch for when upgrading. Also, perhaps your
@code{configure} scripts could benefit from some of the new features in
-version 2; see the @file{NEWS} file in the distribution for a summary.
+version 2.
@menu
* Changed File Names:: Files you might rename.
@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}.
+backslashes before quotes, 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
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.
+then let there be light@dots{}
@menu
* Genesis:: Prehistory and naming of @code{configure}.
to distribute all of the feature tests with every package, so I settled
on having a different @code{configure} made from each
@file{configure.in} by a preprocessor. That approach also offered more
-control and flexibility
+control and flexibility.
I looked briefly into using Larry Wall's Metaconfig program, but I
decided not to for several reasons. The @code{Configure} scripts it
@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
+and converted many GNU packages to use it. I was surprised by how
positive the reaction to it was. More people started using it than I
could keep track of, including people working on software that wasn't
part of the GNU Project (such as TCL, FSP, @TeX{}, and Kerberos v5).
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
+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.
@code{configure}, where @var{package} is something like @samp{gnu-as} or
@samp{x} (for the X Window System). They may also pay attention to
@samp{--enable-@var{feature}} options, where @var{feature} indicates an
-optional part of the package. The README should mention any
+optional part of the package. The @file{README} should mention any
@samp{--with-} and @samp{--enable-} options that the package recognizes.
@noindent
@code{configure}, where @var{package} is something like @samp{gnu-as} or
@samp{x} (for the X Window System). They may also pay attention to
@samp{--enable-@var{feature}} options, where @var{feature} indicates an
-optional part of the package. The README should mention any
+optional part of the package. The @file{README} should mention any
@samp{--with-} and @samp{--enable-} options that the package recognizes.
@noindent
EOF
# Transform confdefs.h into a sed script conftest.vals that substitutes
-# the proper values into config.h.in to produce config.h.
+# the proper values into config.h.in to produce config.h. And first:
+# Protect against being on the right side of a sed subst in config.status.
+# Protect against being in an unquoted here document in config.status.
rm -f conftest.vals
dnl Using a here document instead of a string reduces the quoting nightmare.
+dnl Putting comments in sed scripts is not portable.
cat > conftest.hdr <<\EOF
changequote(<<, >>)dnl
-# Protect against being on the right side of a sed subst in config.status.
s/[\\&%]/\\&/g
-# Protect against being in an unquoted here document in config.status.
s%[\\$`]%\\&%g
s%<<#define>> \([A-Za-z_][A-Za-z0-9_]*\) \(.*\)%${ac_dA}\1${ac_dB}\1${ac_dC}\2${ac_dD}%gp
s%ac_d%ac_u%gp
#endif
#ifdef __cplusplus
-extern "C" { char *valloc(int), *malloc(int); }
+extern "C" { void *valloc(unsigned), *malloc(unsigned); }
#else
char *valloc(), *malloc();
#endif
int i2 = getpagesize()*2;
int fd;
- buf1 = valloc(i2);
- buf2 = valloc(i);
- buf3 = malloc(i2);
+ buf1 = (char *)valloc(i2);
+ buf2 = (char *)valloc(i);
+ buf3 = (char *)malloc(i2);
for (j = 0; j < i2; ++j)
*(buf1 + j) = rand();
fd = open("conftestmmap", O_CREAT | O_RDWR, 0666);
[X_EXTRA_LIBS="$X_EXTRA_LIBS -ldnet_stub"])
fi
- # msh@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT.
+ # msh@cis.ufl.edu says -lnsl (and -lsocket) are needed for his 386/AT,
+ # to get the SysV transport functions.
# Not sure which flavor of 386 Unix this is, but it seems harmless to
# check for it.
- AC_CHECK_LIB(nsl, main, [X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl"])
+ AC_CHECK_LIB(nsl, t_accept, [X_EXTRA_LIBS="$X_EXTRA_LIBS -lnsl"])
# lieder@skyler.mavd.honeywell.com says without -lsocket,
# socket/setsockopt and other routines are undefined under SCO ODT 2.0.
projects / thirdparty / autoconf.git / commitdiff
