mirror of
git://git.sv.gnu.org/autoconf
synced 2024-11-21 01:01:48 +08:00
203 lines
8.1 KiB
Plaintext
203 lines
8.1 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, a file @file{config.cache} that saves the results
|
|
of its tests to speed up reconfiguring, and a file @file{config.log}
|
|
containing compiler output (useful mainly for debugging
|
|
@code{configure}).
|
|
|
|
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 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. You can give
|
|
@code{configure} initial values for variables by setting them in the
|
|
environment. Using a Bourne-compatible shell, you can do that on the
|
|
command line like this:
|
|
@example
|
|
CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
|
|
@end example
|
|
|
|
@noindent
|
|
Or on systems that have the @code{env} program, you can do it like this:
|
|
@example
|
|
env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
|
|
@end example
|
|
|
|
@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 supports 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.
|
|
|
|
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} can not 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 can not 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 Operation Controls
|
|
@section Operation Controls
|
|
|
|
@code{configure} recognizes the following options to control how it
|
|
operates.
|
|
|
|
@table @code
|
|
@item --cache-file=@var{file}
|
|
Use and save the results of the tests in @var{file} instead of
|
|
@file{./config.cache}. Set @var{file} to @file{/dev/null} to disable
|
|
caching, for debugging @code{configure}.
|
|
|
|
@item --help
|
|
Print a summary of the options to @code{configure}, and exit.
|
|
|
|
@item --quiet
|
|
@itemx --silent
|
|
@itemx -q
|
|
Do not print messages saying which checks are being made.
|
|
|
|
@item --srcdir=@var{dir}
|
|
Look for the package's source code in directory @var{dir}. Usually
|
|
@code{configure} can determine that directory automatically.
|
|
|
|
@item --version
|
|
Print the version of Autoconf used to generate the @code{configure}
|
|
script, and exit.
|
|
@end table
|
|
|
|
@noindent
|
|
@code{configure} also accepts some other, not widely useful, options.
|