mirror of
git://git.sv.gnu.org/autoconf
synced 2024-12-09 02:10:22 +08:00
5ae14bc8c0
newbies accidentally use a stale cache file. * acgeneral.m4 (_AC_INIT_PARSE_ARGS): Set cache_file to /dev/null to disable caching by default. (_AC_INIT_HELP): Adjust the --help message. (AC_CACHE_LOAD, AC_CACHE_SAVE): Don't print "loading/updating /dev/null" messages. * autoconf.texi: Note that caching is disabled, how to enable it, and that `./config.cache' is the traditional name of the cache file. * install.texi: Likewise.
251 lines
9.5 KiB
Plaintext
251 lines
9.5 KiB
Plaintext
@c This file is included by autoconf.texi and is used to produce
|
|
@c the INSTALL file.
|
|
|
|
@node Basic Installation
|
|
@section Basic Installation
|
|
|
|
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 @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
|
|
output (useful mainly for debugging @code{configure}).
|
|
|
|
It can also use an optional file (typically called @file{config.cache}
|
|
and enabled with @samp{--cache-file=./config.cache}) that saves the
|
|
results of its tests to speed up reconfiguring. (Caching is disabled by
|
|
default to prevent problems with accidental use of stale cache files.)
|
|
|
|
If you need to do unusual things to compile the package, please try to
|
|
figure out how @code{configure} could check whether to do them, and mail
|
|
diffs or instructions to the address given in the @file{README} so they
|
|
can be considered for the next release. If you are using the cache, and
|
|
at some point @file{config.cache} contains results you don't want to
|
|
keep, you may remove or edit it.
|
|
|
|
The file @file{configure.in} is used to create @file{configure} by a
|
|
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
|
|
The simplest way to compile this package is:
|
|
|
|
@enumerate
|
|
@item
|
|
@code{cd} to the directory containing the package's source code and type
|
|
@samp{./configure} to configure the package for your system. If you're
|
|
using @code{csh} on an old version of System V, you might need to type
|
|
@samp{sh ./configure} instead to prevent @code{csh} from trying to
|
|
execute @code{configure} itself.
|
|
|
|
Running @code{configure} takes awhile. While running, it prints some
|
|
messages telling which features it is checking for.
|
|
|
|
@item
|
|
Type @samp{make} to compile the package.
|
|
|
|
@item
|
|
Optionally, type @samp{make check} to run any self-tests that come with
|
|
the package.
|
|
|
|
@item
|
|
Type @samp{make install} to install the programs and any data files and
|
|
documentation.
|
|
|
|
@item
|
|
You can remove the program binaries and object files from the source code
|
|
directory by typing @samp{make clean}. To also remove the files that
|
|
@code{configure} created (so you can compile the package for a different
|
|
kind of computer), type @samp{make distclean}. There is also a
|
|
@samp{make maintainer-clean} target, but that is intended mainly for the
|
|
package's developers. If you use it, you may have to get all sorts of
|
|
other programs in order to regenerate files that came with the distribution.
|
|
@end enumerate
|
|
|
|
@node Compilers and Options
|
|
@section Compilers and Options
|
|
|
|
Some systems require unusual options for compilation or linking that the
|
|
@code{configure} script does not know about. Run @samp{./configure
|
|
--help} for details on some of the pertinent environment variables.
|
|
|
|
You can give @code{configure} initial values for variables by setting
|
|
them in the environment. You can do that on the command line like this:
|
|
@example
|
|
./configure CC=c89 CFLAGS=-O2 LIBS=-lposix
|
|
@end example
|
|
|
|
@xref{Environment Variables}, for more details.
|
|
|
|
|
|
@node Multiple Architectures
|
|
@section Compiling For Multiple Architectures
|
|
|
|
You can compile the package for more than one kind of computer at the
|
|
same time, by placing the object files for each architecture in their
|
|
own directory. 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{..}.
|
|
|
|
If you have to use a @code{make} that does not support the @code{VPATH}
|
|
variable, you have to compile the package for one architecture at a time
|
|
in the source code directory. After you have installed the package for
|
|
one architecture, use @samp{make distclean} before reconfiguring for
|
|
another architecture.
|
|
|
|
@node Installation Names
|
|
@section Installation Names
|
|
|
|
By default, @samp{make install} will install the package's files in
|
|
@file{/usr/local/bin}, @file{/usr/local/man}, etc. You can specify an
|
|
installation prefix other than @file{/usr/local} by giving
|
|
@code{configure} the option @samp{--prefix=@var{path}}.
|
|
|
|
You can specify separate installation prefixes for architecture-specific
|
|
files and architecture-independent files. If you give @code{configure}
|
|
the option @samp{--exec-prefix=@var{path}}, the package will use
|
|
@var{path} as the prefix for installing programs and libraries.
|
|
Documentation and other data files will still use the regular prefix.
|
|
|
|
In addition, if you use an unusual directory layout you can give options
|
|
like @samp{--bindir=@var{path}} to specify different values for
|
|
particular kinds of files. Run @samp{configure --help} for a list of
|
|
the directories you can set and what kinds of files go in them.
|
|
|
|
If the package supports it, you can cause programs to be installed with
|
|
an extra prefix or suffix on their names by giving @code{configure} the
|
|
option @samp{--program-prefix=@var{PREFIX}} or
|
|
@samp{--program-suffix=@var{SUFFIX}}.
|
|
|
|
@node Optional Features
|
|
@section Optional Features
|
|
|
|
Some packages pay attention to @samp{--enable-@var{feature}} options to
|
|
@code{configure}, where @var{feature} indicates an optional part of the
|
|
package. They may also pay attention to @samp{--with-@var{package}}
|
|
options, where @var{package} is something like @samp{gnu-as} or @samp{x}
|
|
(for the X Window System). The @file{README} should mention any
|
|
@samp{--enable-} and @samp{--with-} options that the package recognizes.
|
|
|
|
For packages that use the X Window System, @code{configure} can usually
|
|
find the X include and library files automatically, but if it doesn't,
|
|
you can use the @code{configure} options @samp{--x-includes=@var{dir}}
|
|
and @samp{--x-libraries=@var{dir}} to specify their locations.
|
|
|
|
@node System Type
|
|
@section Specifying the System Type
|
|
|
|
There may be some features @code{configure} cannot figure out
|
|
automatically, but needs to determine by the type of host the package
|
|
will run on. Usually @code{configure} can figure that out, but if it
|
|
prints a message saying it cannot guess the host type, give it the
|
|
@samp{--host=@var{type}} option. @var{type} can either be a short name
|
|
for the system type, such as @samp{sun4}, or a canonical name with three
|
|
fields:
|
|
@example
|
|
@var{cpu}-@var{company}-@var{system}
|
|
@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 they
|
|
will produce code for and the @samp{--build=@var{type}} option to select
|
|
the type of system on which you are compiling the package.
|
|
|
|
@node Sharing Defaults
|
|
@section Sharing Defaults
|
|
|
|
If you want to set default values for @code{configure} scripts to share,
|
|
you can create a site shell script called @file{config.site} that gives
|
|
default values for variables like @code{CC}, @code{cache_file}, and
|
|
@code{prefix}. @code{configure} looks for
|
|
@file{@var{prefix}/share/config.site} if it exists, then
|
|
@file{@var{prefix}/etc/config.site} if it exists. Or, you can set the
|
|
@code{CONFIG_SITE} environment variable to the location of the site
|
|
script. A warning: not all @code{configure} scripts look for a site
|
|
script.
|
|
|
|
@node Environment Variables
|
|
@section Environment Variables
|
|
|
|
Variables not defined in a site shell script can be set in the
|
|
environment passed to configure. However, some packages may run
|
|
configure again during the build, and the customized values of these
|
|
variables may be lost. In order to avoid this problem, you should set
|
|
them in the @code{configure} command line, using @samp{VAR=value}. For
|
|
example:
|
|
|
|
@example
|
|
./configure CC=/usr/local2/bin/gcc
|
|
@end example
|
|
|
|
@noindent
|
|
will cause the specified gcc to be used as the C compiler (unless it is
|
|
overridden in the site shell script).
|
|
|
|
Please, note that the former interface:
|
|
|
|
@example
|
|
CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
|
|
@end example
|
|
|
|
@noindent
|
|
or
|
|
|
|
@example
|
|
env CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
|
|
@end example
|
|
|
|
@noindent
|
|
should be avoided.
|
|
|
|
|
|
@node Operation Controls
|
|
@section Operation Controls
|
|
|
|
@code{configure} recognizes the following options to control how it
|
|
operates.
|
|
|
|
@table @code
|
|
@item --help
|
|
@itemx -h
|
|
Print a summary of the options to @code{configure}, and exit.
|
|
|
|
@item --version
|
|
@itemx -V
|
|
Print the version of Autoconf used to generate the @code{configure}
|
|
script, and exit.
|
|
|
|
@item --cache-file=@var{file}
|
|
@cindex Cache, enabling
|
|
Enable the cache: use and save the results of the tests in @var{file},
|
|
traditionally @file{./config.cache}. @var{file} defaults to
|
|
@file{/dev/null} to disable caching.
|
|
|
|
@item --quiet
|
|
@itemx --silent
|
|
@itemx -q
|
|
Do not print messages saying which checks are being made. To suppress
|
|
all normal output, redirect it to @file{/dev/null} (any error messages
|
|
will still be shown).
|
|
|
|
@item --srcdir=@var{dir}
|
|
Look for the package's source code in directory @var{dir}. Usually
|
|
@code{configure} can determine that directory automatically.
|
|
@end table
|
|
|
|
@noindent
|
|
@code{configure} also accepts some other, not widely useful, options.
|
|
Run @samp{configure --help} for more details.
|