mirror of
git://git.sv.gnu.org/autoconf
synced 2025-03-19 14:40:24 +08:00
minor fixes
This commit is contained in:
David MacKenzie
parent
8bf06aec5b
commit
e33c467f33
14
README
14
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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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) {
|
||||
|
||||
@ -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) {
|
||||
|
||||
@ -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) {
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
40
install.texi
40
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
|
||||
|
||||
@ -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)
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user