diff --git a/README b/README index 2cc58e29..ffbea3ee 100644 --- a/README +++ b/README @@ -1,4 +1,4 @@ -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. @@ -8,9 +8,13 @@ configuration script for a package from a template file that lists the 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 @@ -22,7 +26,7 @@ to maintain many similar sets of installation instructions. 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 diff --git a/autoconf.texi b/autoconf.texi index aacd79c5..2f47a998 100644 --- a/autoconf.texi +++ b/autoconf.texi @@ -509,17 +509,17 @@ summary of the command-line options and exits. 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 diff --git a/autoscan.in b/autoscan.in index 6fe9b380..b037f64b 100644 --- a/autoscan.in +++ b/autoscan.in @@ -39,7 +39,7 @@ exit 0; # Process any command line arguments. sub parse_args { - local ($usage) = \ + local ($usage) = "Usage: $0 [--macrodir=dir] [--help] [--verbose] [--version] [srcdir]\n"; foreach $_ (@ARGV) { diff --git a/autoscan.pl b/autoscan.pl index 6fe9b380..b037f64b 100644 --- a/autoscan.pl +++ b/autoscan.pl @@ -39,7 +39,7 @@ exit 0; # Process any command line arguments. sub parse_args { - local ($usage) = \ + local ($usage) = "Usage: $0 [--macrodir=dir] [--help] [--verbose] [--version] [srcdir]\n"; foreach $_ (@ARGV) { diff --git a/bin/autoscan.in b/bin/autoscan.in index 6fe9b380..b037f64b 100644 --- a/bin/autoscan.in +++ b/bin/autoscan.in @@ -39,7 +39,7 @@ exit 0; # Process any command line arguments. sub parse_args { - local ($usage) = \ + local ($usage) = "Usage: $0 [--macrodir=dir] [--help] [--verbose] [--version] [srcdir]\n"; foreach $_ (@ARGV) { diff --git a/doc/autoconf.texi b/doc/autoconf.texi index aacd79c5..2f47a998 100644 --- a/doc/autoconf.texi +++ b/doc/autoconf.texi @@ -509,17 +509,17 @@ summary of the command-line options and exits. 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 diff --git a/doc/install.texi b/doc/install.texi index 212bb8e4..612c84a6 100644 --- a/doc/install.texi +++ b/doc/install.texi @@ -4,14 +4,12 @@ @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 @@ -23,8 +21,8 @@ diffs or instructions to the address given in the @file{README} so they 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 @@ -55,7 +53,8 @@ documentation. @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 @@ -86,13 +85,14 @@ make CFLAGS=-O2 LDFLAGS=-s @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 @@ -116,8 +116,8 @@ variable @samp{exec_prefix} to @var{path}, the package will use 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 @@ -140,6 +140,8 @@ fields: @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 @@ -163,8 +165,9 @@ optional part of the package. The README should mention any @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} @@ -172,6 +175,7 @@ Look for the package's source code in directory @var{dir}. Usually @code{configure} can determine that directory automatically. @item --verbose +@itemx -v Print the results of the checks. @item --version diff --git a/install.texi b/install.texi index 212bb8e4..612c84a6 100644 --- a/install.texi +++ b/install.texi @@ -4,14 +4,12 @@ @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 @@ -23,8 +21,8 @@ diffs or instructions to the address given in the @file{README} so they 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 @@ -55,7 +53,8 @@ documentation. @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 @@ -86,13 +85,14 @@ make CFLAGS=-O2 LDFLAGS=-s @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 @@ -116,8 +116,8 @@ variable @samp{exec_prefix} to @var{path}, the package will use 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 @@ -140,6 +140,8 @@ fields: @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 @@ -163,8 +165,9 @@ optional part of the package. The README should mention any @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} @@ -172,6 +175,7 @@ Look for the package's source code in directory @var{dir}. Usually @code{configure} can determine that directory automatically. @item --verbose +@itemx -v Print the results of the checks. @item --version diff --git a/testsuite/Makefile.in b/testsuite/Makefile.in index 2cf1e11d..b9dd86cf 100644 --- a/testsuite/Makefile.in +++ b/testsuite/Makefile.in @@ -44,6 +44,7 @@ info: 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)