-Autoconf -- generate automatic software configuration scripts from templates
+Autoconf
Autoconf is an extensible package of m4 macros that produce shell
scripts to automatically configure software source code packages.
operating system features that the package can use, in the form of m4
macro calls.
-Autoconf requires GNU m4. The configuration scripts produced by
-Autoconf are independent of Autoconf when they are run, so their users
-do not need to have Autoconf (or GNU m4).
+Producing configuration scripts using Autoconf requires GNU m4. The
+configuration scripts produced by Autoconf are self-contained, so
+their users do not need to have Autoconf (or GNU m4). Also, some
+optional utilities that come with Autoconf use Perl, Bash, TCL, and
+the TCL packages Expect and DejaGNU. However, none of those are
+required in order to use the main Autoconf program. If they are not
+present, the affected Autoconf utilities will not be installed.
The file INSTALL can be distributed with packages that use
Autoconf-generated configure scripts and Makefiles that conform to the
The file `acconfig.h' contains short descriptions of the C preprocessor
variables that Autoconf can define, suitable for copying into other
packages' configuration headers or Makefile.in files. You can use the
-program `autoheader' to automatically creates a configuration header
+program `autoheader' to automatically create a configuration header
from a `configure.in', based on the information in `acconfig.h'.
Mail suggestions and bug reports for Autoconf to
The @code{autoscan} program can help you create a @file{configure.in}
file for a software package. @code{autoscan} examines source files in
-the directory given as a command line argument, or the current directory
-if none is given. It searches the source files for common portability
-problems and creates a file @file{configure.scan} which is a preliminary
-@file{configure.in} for that package. You should manually examine
-@file{configure.scan} before 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).
+the directory tree rooted at a directory given as a command line
+argument, or the current directory if none is given. It searches the
+source files for common portability problems and creates a file
+@file{configure.scan} which is a preliminary @file{configure.in} for
+that package. You should manually examine @file{configure.scan} before
+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).
@code{autoscan} uses several data files, which are installed with the
distributed Autoconf macro files, to determine which macros to output
# Process any command line arguments.
sub parse_args
{
- local ($usage) = \
+ local ($usage) =
"Usage: $0 [--macrodir=dir] [--help] [--verbose] [--version] [srcdir]\n";
foreach $_ (@ARGV) {
# Process any command line arguments.
sub parse_args
{
- local ($usage) = \
+ local ($usage) =
"Usage: $0 [--macrodir=dir] [--help] [--verbose] [--version] [srcdir]\n";
foreach $_ (@ARGV) {
# Process any command line arguments.
sub parse_args
{
- local ($usage) = \
+ local ($usage) =
"Usage: $0 [--macrodir=dir] [--help] [--verbose] [--version] [srcdir]\n";
foreach $_ (@ARGV) {
The @code{autoscan} program can help you create a @file{configure.in}
file for a software package. @code{autoscan} examines source files in
-the directory given as a command line argument, or the current directory
-if none is given. It searches the source files for common portability
-problems and creates a file @file{configure.scan} which is a preliminary
-@file{configure.in} for that package. You should manually examine
-@file{configure.scan} before 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).
+the directory tree rooted at a directory given as a command line
+argument, or the current directory if none is given. It searches the
+source files for common portability problems and creates a file
+@file{configure.scan} which is a preliminary @file{configure.in} for
+that package. You should manually examine @file{configure.scan} before
+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).
@code{autoscan} uses several data files, which are installed with the
distributed Autoconf macro files, to determine which macros to output
@node Basic Installation
@section Basic Installation
-These are generic installation instructions. If this package does not
-come with, e.g., self-tests, installable documentation, or data files,
-please ignore the references to them below.
+These are generic installation instructions.
The @code{configure} shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a @file{Makefile} in each directory of the
-package. It may also create one or more C files containing
+package. It may also create one or more @file{.h} files containing
system-dependent definitions. Finally, it creates a shell script
@file{config.status} that you can run in the future to recreate the
current configuration, and a file @file{config.log} containing compiler
can be considered for the next release.
The file @file{configure.in} is used to create @file{configure} by a
-program called @code{autoconf}. You only need it if you want to change
-@file{configure.in}, or regenerate @file{configure} using a newer
+program called @code{autoconf}. You only need @file{configure.in} if
+you want to change it or regenerate @file{configure} using a newer
version of @code{autoconf}.
@noindent
@item
You can remove the program binaries and object files from the source
directory by typing @samp{make clean}. To also remove the files that
-@code{configure} created, type @samp{make distclean}.
+@code{configure} created (so you can compile the package for a different
+kind of computer), type @samp{make distclean}.
@end enumerate
@node Compilers and Options
@node Build Directory
@section Using a Different Build Directory
-To compile the package in a different directory from the one containing
-the source code, you must use a version of @code{make} that supports the
-@code{VPATH} variable, such as GNU @code{make}. @code{cd} to the
-directory where you want the object files and executables to go and run
-the @code{configure} script. @code{configure} automatically checks for
-the source code in the directory that @code{configure} is in and in
-@file{..}.
+You can compile the package in a different directory from the one
+containing the source code. Doing so allows you to compile it on more
+than one kind of computer at the same time. To do this, you must use a
+version of @code{make} that supports the @code{VPATH} variable, such as
+GNU @code{make}. @code{cd} to the directory where you want the object
+files and executables to go and run the @code{configure} script.
+@code{configure} automatically checks for the source code in the
+directory that @code{configure} is in and in @file{..}.
@node Installation Directories
@section Installation Directories
Documentation and other data files will still use the regular prefix.
If you use an unusual directory layout in which some of the installation
-directory names are not based on the prefix or exec prefix, you can set
-the individual variables @code{bindir}, @code{libdir}, etc. on the
+directory names are not based on a single prefix, you can set the
+individual variables @code{bindir}, @code{libdir}, etc. on the
@code{make} command line:
@example
make bindir=/bin libdir=/usr/lib
@end example
@noindent
See the file @file{config.sub} for the possible values of each field.
+If @file{config.sub} isn't included in this package, then this package
+doesn't need to know the host type.
If you are building compiler tools for cross-compiling, you can also use
the @samp{--target=@var{type}} option to select the type of system
@item --help
Print a summary of the options to @code{configure}, and exit.
-@itemx --quiet
-@item --silent
+@item --quiet
+@itemx --silent
+@itemx -q
Do not print messages saying which checks are being made.
@item --srcdir=@var{dir}
@code{configure} can determine that directory automatically.
@item --verbose
+@itemx -v
Print the results of the checks.
@item --version
@node Basic Installation
@section Basic Installation
-These are generic installation instructions. If this package does not
-come with, e.g., self-tests, installable documentation, or data files,
-please ignore the references to them below.
+These are generic installation instructions.
The @code{configure} shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a @file{Makefile} in each directory of the
-package. It may also create one or more C files containing
+package. It may also create one or more @file{.h} files containing
system-dependent definitions. Finally, it creates a shell script
@file{config.status} that you can run in the future to recreate the
current configuration, and a file @file{config.log} containing compiler
can be considered for the next release.
The file @file{configure.in} is used to create @file{configure} by a
-program called @code{autoconf}. You only need it if you want to change
-@file{configure.in}, or regenerate @file{configure} using a newer
+program called @code{autoconf}. You only need @file{configure.in} if
+you want to change it or regenerate @file{configure} using a newer
version of @code{autoconf}.
@noindent
@item
You can remove the program binaries and object files from the source
directory by typing @samp{make clean}. To also remove the files that
-@code{configure} created, type @samp{make distclean}.
+@code{configure} created (so you can compile the package for a different
+kind of computer), type @samp{make distclean}.
@end enumerate
@node Compilers and Options
@node Build Directory
@section Using a Different Build Directory
-To compile the package in a different directory from the one containing
-the source code, you must use a version of @code{make} that supports the
-@code{VPATH} variable, such as GNU @code{make}. @code{cd} to the
-directory where you want the object files and executables to go and run
-the @code{configure} script. @code{configure} automatically checks for
-the source code in the directory that @code{configure} is in and in
-@file{..}.
+You can compile the package in a different directory from the one
+containing the source code. Doing so allows you to compile it on more
+than one kind of computer at the same time. To do this, you must use a
+version of @code{make} that supports the @code{VPATH} variable, such as
+GNU @code{make}. @code{cd} to the directory where you want the object
+files and executables to go and run the @code{configure} script.
+@code{configure} automatically checks for the source code in the
+directory that @code{configure} is in and in @file{..}.
@node Installation Directories
@section Installation Directories
Documentation and other data files will still use the regular prefix.
If you use an unusual directory layout in which some of the installation
-directory names are not based on the prefix or exec prefix, you can set
-the individual variables @code{bindir}, @code{libdir}, etc. on the
+directory names are not based on a single prefix, you can set the
+individual variables @code{bindir}, @code{libdir}, etc. on the
@code{make} command line:
@example
make bindir=/bin libdir=/usr/lib
@end example
@noindent
See the file @file{config.sub} for the possible values of each field.
+If @file{config.sub} isn't included in this package, then this package
+doesn't need to know the host type.
If you are building compiler tools for cross-compiling, you can also use
the @samp{--target=@var{type}} option to select the type of system
@item --help
Print a summary of the options to @code{configure}, and exit.
-@itemx --quiet
-@item --silent
+@item --quiet
+@itemx --silent
+@itemx -q
Do not print messages saying which checks are being made.
@item --srcdir=@var{dir}
@code{configure} can determine that directory automatically.
@item --verbose
+@itemx -v
Print the results of the checks.
@item --version
dvi:
check: site.exp all
+ @echo This only works if you have the DejaGNU runtest program installed...
$(RUNTEST) $(RUNTESTFLAGS) --tool autoconf AUTOCONF=${AUTOCONF} \
AUTOCONFFLAGS="${AUTOCONFFLAGS}" --srcdir $(srcdir)
projects / thirdparty / autoconf.git / commitdiff
