1175 lines
49 KiB
Plaintext
1175 lines
49 KiB
Plaintext
|
This is Info file configure.info, produced by Makeinfo-1.64 from the
|
|||
|
input file ./configure.texi.
|
|||
|
|
|||
|
START-INFO-DIR-ENTRY
|
|||
|
* configure: (configure). Cygnus configure.
|
|||
|
END-INFO-DIR-ENTRY
|
|||
|
|
|||
|
This document describes the Cygnus Support version of `configure'.
|
|||
|
|
|||
|
Copyright (C) 1991, 1992, 1993 Cygnus Support Permission is granted
|
|||
|
to make and distribute verbatim copies of this manual provided the
|
|||
|
copyright notice and this permission notice are preserved on all copies.
|
|||
|
|
|||
|
Permission is granted to copy and distribute modified versions of
|
|||
|
this manual under the conditions for verbatim copying, provided that
|
|||
|
the entire resulting derived work is distributed under the terms of a
|
|||
|
permission notice identical to this one.
|
|||
|
|
|||
|
Permission is granted to copy and distribute translations of this
|
|||
|
manual into another language, under the above conditions for modified
|
|||
|
versions, except that this permission notice may be stated in a
|
|||
|
translation approved by Cygnus Support.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Top, Next: What configure does, Up: (dir)
|
|||
|
|
|||
|
Cygnus configure
|
|||
|
****************
|
|||
|
|
|||
|
This file documents the configuration system used and distributed by
|
|||
|
Cygnus Support.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* What configure does:: What configure does
|
|||
|
* Invoking configure:: Invoking configure--basic usage
|
|||
|
* Using configure:: More than you ever wanted to know
|
|||
|
* Porting:: How to use configure with new programs
|
|||
|
* Variables Index::
|
|||
|
* Concept Index::
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: What configure does, Next: Invoking configure, Prev: Top, Up: Top
|
|||
|
|
|||
|
What `configure' does
|
|||
|
*********************
|
|||
|
|
|||
|
This manual documents Cygnus `configure', a program which helps to
|
|||
|
automate much of the setup activity associated with building large
|
|||
|
suites of programs, such the Cygnus Support Developer's Kit. This
|
|||
|
manual is therefore geared toward readers who are likely to face the
|
|||
|
problem of configuring software in source form before compiling and
|
|||
|
installing it. We assume you are an experienced programmer or system
|
|||
|
administrator. For further background on this topic, see *Note
|
|||
|
Apologia Configure: (cfg-paper)Some Basic Terms, by K. Richard Pixley.
|
|||
|
|
|||
|
When `configure' runs, it does the following things:
|
|||
|
|
|||
|
** creates build directories*
|
|||
|
When you run `configure' with the `--srcdir' option, it uses the
|
|||
|
current directory as the "build directory", creating under it a
|
|||
|
directory tree that parallels the directory structure of the
|
|||
|
source directory. If you don't specify a `srcdir', `configure'
|
|||
|
first assumes that the source code you wish to configure is in
|
|||
|
your current directory; if it finds no `configure.in' input file
|
|||
|
there, it searches in the directory `configure' itself lies in.
|
|||
|
(For details, see *Note Build directories: Build directories.)
|
|||
|
|
|||
|
** generates `Makefile'*
|
|||
|
A `Makefile' template from the source directory, usually called
|
|||
|
`Makefile.in', is copied to an output file in the build directory
|
|||
|
which is most often named `Makefile'. `configure' places
|
|||
|
definitions for a number of standard `Makefile' macros at the
|
|||
|
beginning of the output file. If `--prefix=DIR' or
|
|||
|
`--exec_prefix=DIR' are specified on the `configure' command line,
|
|||
|
corresponding `Makefile' variables are set accordingly. If host,
|
|||
|
target, or site-specific `Makefile' fragments exist, these are
|
|||
|
inserted into the output file. (For details, see *Note `Makefile'
|
|||
|
generation: Makefile generation.)
|
|||
|
|
|||
|
** generates `.gdbinit'*
|
|||
|
If the source directory contains a `.gdbinit' file and the build
|
|||
|
directory is not the same as the source directory, a `.gdbinit'
|
|||
|
file is created in the build directory. This `.gdbinit' file
|
|||
|
contains commands which allow the source directory to be read when
|
|||
|
debugging with the GNU debugger, `gdb'. (*Note Command Files:
|
|||
|
(gdb)Command Files.)
|
|||
|
|
|||
|
** makes symbolic links*
|
|||
|
Most build directories require that some symbolic links with
|
|||
|
generic names are built pointing to specific files in the source
|
|||
|
directory. If the system where `configure' runs cannot support
|
|||
|
symbolic links, hard links are used instead. (For details, see
|
|||
|
*Note The `configure.in' input file: configure.in.)
|
|||
|
|
|||
|
** generates `config.status'*
|
|||
|
`configure' creates a shell script named `config.status' in the
|
|||
|
build directory. This shell script, when run from the build
|
|||
|
directory (usually from within a `Makefile'), will reconfigure the
|
|||
|
build directory (but not its subdirectories). This is most often
|
|||
|
used to have a `Makefile' update itself automatically if a new
|
|||
|
source directory is available.
|
|||
|
|
|||
|
** calls itself recursively*
|
|||
|
If the source directory has subdirectories that should also be
|
|||
|
configured, `configure' is called for each.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Invoking configure, Next: Using configure, Prev: What configure does, Up: Top
|
|||
|
|
|||
|
Invoking `configure'
|
|||
|
********************
|
|||
|
|
|||
|
Cygnus `configure' is a shell script which resides in a source tree.
|
|||
|
The usual way to invoke `configure' is from the shell, as follows:
|
|||
|
|
|||
|
eg$ ./configure HOSTTYPE
|
|||
|
|
|||
|
This prepares the source in the current directory (`.') to be compiled
|
|||
|
for a HOSTTYPE environment. It assumes that you wish to build programs
|
|||
|
and files in the default "build directory" (also the current directory,
|
|||
|
`.'). If you do not specify a value for HOSTTYPE, Cygnus `configure'
|
|||
|
will attempt to discover this information by itself (*note Determining
|
|||
|
system information: config.guess.). For information on HOSTTYPE
|
|||
|
environments, *Note Host: Host.
|
|||
|
|
|||
|
All GNU software is packaged with one or more `configure' script(s)
|
|||
|
(*note How Configuration Should Work: (standards)Configuration.). By
|
|||
|
using `configure' you prepare the source for your specific environment
|
|||
|
by selecting and using `Makefile' fragments and fragments of shell
|
|||
|
scripts, which are prepared in advance and stored with the source.
|
|||
|
|
|||
|
`configure''s command-line options also allow you to specify other
|
|||
|
aspects of the source configuration:
|
|||
|
|
|||
|
configure HOSTTYPE [--target=TARGET] [--srcdir=DIR] [--rm]
|
|||
|
[--site=SITE] [--prefix=DIR] [--exec-prefix=DIR]
|
|||
|
[--program-prefix=STRING] [--tmpdir=DIR]
|
|||
|
[--with-PACKAGE[=YES/NO]] [--without-PACKAGE]
|
|||
|
[--enable-FEATURE[=YES/NO]] [--disable-FEATURE]
|
|||
|
[--norecursion] [--nfp] [-s] [-v] [-V | --version] [--help]
|
|||
|
|
|||
|
`--target=TARGET'
|
|||
|
Requests that the sources be configured to target the TARGET
|
|||
|
machine. If no target is specified explicitly, the target is
|
|||
|
assumed to be the same as the host (i.e., a "native"
|
|||
|
configuration). *Note Host: Host, and *Note Target: Target, for
|
|||
|
discussions of each.
|
|||
|
|
|||
|
`--srcdir=DIR'
|
|||
|
Direct each generated `Makefile' to use the sources located in
|
|||
|
directory DIR. Use this option whenever you wish the object code
|
|||
|
to reside in a different place from the source code. The "build
|
|||
|
directory" is always assumed to be the directory you call
|
|||
|
`configure' from. See *Note Build directories: Build directories,
|
|||
|
for an example. If the source directory is not specified,
|
|||
|
`configure' assumes that the source is in your current directory.
|
|||
|
If `configure' finds no `configure.in' there, it searches in the
|
|||
|
same directory that the `configure' script itself lies in.
|
|||
|
Pathnames specified (Values for DIR) can be either absolute
|
|||
|
relative to the *build* directory.
|
|||
|
|
|||
|
`--rm'
|
|||
|
*Remove* the configuration specified by HOSTTYPE and the other
|
|||
|
command-line options, rather than create it.
|
|||
|
|
|||
|
*Note:* We recommend that you use `make distclean' rather than
|
|||
|
use this option; see *Note Invoking `make': (make)Invoking
|
|||
|
make, for details on `make distclean'.
|
|||
|
|
|||
|
`--site=SITE'
|
|||
|
Generate the `Makefile' using site-specific `Makefile' fragments
|
|||
|
for SITE. *Note Adding information about local conventions:
|
|||
|
Makefile fragments.
|
|||
|
|
|||
|
`--prefix=DIR'
|
|||
|
Configure the source to install programs and files under directory
|
|||
|
DIR.
|
|||
|
|
|||
|
This option sets the variable `prefix'. Each generated `Makefile'
|
|||
|
will have its `prefix' variables set to this value. (*Note What
|
|||
|
`configure' really does: What configure really does.)
|
|||
|
|
|||
|
`--exec-prefix=DIR'
|
|||
|
Configure the source to install "host dependent" files in DIR.
|
|||
|
|
|||
|
This option sets the variable `exec_prefix'. Each generated
|
|||
|
`Makefile' will have its `exec_prefix' variables set to this value.
|
|||
|
(*Note What `configure' really does: What configure really does.)
|
|||
|
|
|||
|
`--program-prefix=STRING'
|
|||
|
Configure the source to install certain programs using STRING as a
|
|||
|
prefix. This applies to programs which might be used for
|
|||
|
cross-compilation, such as the compiler and the binary utilities,
|
|||
|
and also to programs which have the same names as common Unix
|
|||
|
programs, such as `make'.
|
|||
|
|
|||
|
This option sets the variable `program_prefix'. Each generated
|
|||
|
`Makefile' will have its `program_prefix' variables set to this
|
|||
|
value. (*Note What `configure' really does: What configure really
|
|||
|
does.)
|
|||
|
|
|||
|
`--tmpdir=TMPDIR'
|
|||
|
Use the directory TMPDIR for `configure''s temporary files. The
|
|||
|
default is the value of the environment variable `TMPDIR', or
|
|||
|
`/tmp' if the environment variable is not set.
|
|||
|
|
|||
|
`--with-PACKAGE[=YES/NO]'
|
|||
|
`--without-PACKAGE'
|
|||
|
Indicate that PACKAGE is present, or not present, depending on
|
|||
|
YES/NO. If YES/NO is nonexistent, its value is assumed to be
|
|||
|
`yes'. `--without-PACKAGE' is equivalent to `--with-PACKAGE=no'.
|
|||
|
|
|||
|
For example, if you wish to configure the program `gcc' for a Sun
|
|||
|
SPARCstation running SunOS 4.x, and you want `gcc' to use the GNU
|
|||
|
linker `ld', you can configure `gcc' using
|
|||
|
|
|||
|
eg$ configure --with-gnu-ld sun4
|
|||
|
|
|||
|
*Note What `configure' really does: What configure really does, for
|
|||
|
details. See the installation or release notes for your
|
|||
|
particular package for details on which other PACKAGE options are
|
|||
|
recognized.
|
|||
|
|
|||
|
`--enable-FEATURE[=YES/NO]'
|
|||
|
`--disable-FEATURE'
|
|||
|
Include FEATURE, or not, depending on YES/NO. If YES/NO is
|
|||
|
nonexistent, its value is assumed to be `yes'.
|
|||
|
`--disable-FEATURE' is equivalent to `--enable-FEATURE=no'.
|
|||
|
|
|||
|
*Note What `configure' really does: What configure really does, for
|
|||
|
details. See the installation or release notes for your
|
|||
|
particular package for details on which other FEATURE options are
|
|||
|
recognized.
|
|||
|
|
|||
|
`--norecursion'
|
|||
|
Configure only this directory; ignore any subdirectories. This is
|
|||
|
used by the executable shell script `config.status' to reconfigure
|
|||
|
only the current directory; it is most often used
|
|||
|
non-interactively, when `make' is invoked. (*Note
|
|||
|
`config.status': config.status.)
|
|||
|
|
|||
|
`--nfp'
|
|||
|
Assume that the intended HOSTTYPE has no floating point unit.
|
|||
|
|
|||
|
`-s'
|
|||
|
Suppress status output. This option is used internally by
|
|||
|
`configure' when calling itself recursively in subdirectories. You
|
|||
|
can override this option with the `--verbose' option.
|
|||
|
|
|||
|
`-v'
|
|||
|
`--verbose'
|
|||
|
Print status lines for each directory configured. Normally, only
|
|||
|
the status lines for the initial working directory are printed.
|
|||
|
|
|||
|
`--version'
|
|||
|
`-V'
|
|||
|
Print the `configure' version number.
|
|||
|
|
|||
|
`--help'
|
|||
|
Print a short summary of how to invoke `configure'.
|
|||
|
|
|||
|
*Note:* You may introduce options with a single dash, `-', rather
|
|||
|
than two dashes, `--'. However, you may not be able to truncate long
|
|||
|
option names when using a single dash. When using two dashes, options
|
|||
|
may be abbreviated as long as each option can be uniquely identified.
|
|||
|
For example,
|
|||
|
eg$ configure --s=/u/me/src HOSTTYPE
|
|||
|
|
|||
|
is ambiguous, as `--s' could refer to either `--site' or `--srcdir'.
|
|||
|
However,
|
|||
|
eg$ configure --src=/u/me/src HOSTTYPE
|
|||
|
|
|||
|
is a valid abbreviation.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Using configure, Next: Porting, Prev: Invoking configure, Up: Top
|
|||
|
|
|||
|
Using `configure'
|
|||
|
*****************
|
|||
|
|
|||
|
`configure' prepares source directories for building programs in
|
|||
|
them. "Configuring" is the process of preparing software to compile
|
|||
|
correctly on a given "host", for a given "target".
|
|||
|
|
|||
|
`configure' subsequently writes a configured `Makefile' from a
|
|||
|
pre-built template; `configure' uses variables that have been set in the
|
|||
|
configuring process to determine the values of some variables in the
|
|||
|
`Makefile'. Because of this we will refer to both `configure'
|
|||
|
variables and `Makefile' variables. This convention allows us to
|
|||
|
determine where the variable should be set initially, in either
|
|||
|
`configure.in' or `Makefile.in'.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* What configure really does:: What configure really does
|
|||
|
* configure.in:: The configure.in input file
|
|||
|
* Install locations:: Where to install things once they are built
|
|||
|
* Host:: Telling configure what will source will be built
|
|||
|
* Target:: Telling configure what the source will target
|
|||
|
* Makefile fragments:: Adding information about local conventions
|
|||
|
* Makefile extensions:: Extensions to the GNU coding standards
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: What configure really does, Next: configure.in, Up: Using configure
|
|||
|
|
|||
|
What `configure' really does
|
|||
|
============================
|
|||
|
|
|||
|
Cygnus `configure' is a shell script that sets up an environment in
|
|||
|
which your programs will compile correctly for your machine and
|
|||
|
operating system, and will install in proper places. `configure'
|
|||
|
accomplishes this task by doing the following:
|
|||
|
|
|||
|
* it generates a `Makefile' from a custom template called
|
|||
|
`Makefile.in' in each relevant source directory;
|
|||
|
|
|||
|
* it customizes the build process to your specifications; you set
|
|||
|
certain variables for `configure', either on the command line or
|
|||
|
in the file `configure.in', which subsequently sets variables in
|
|||
|
each generated `Makefile' to be used by `make' when actually
|
|||
|
building the software;
|
|||
|
|
|||
|
* it creates "build directories", places for your code to be compiled
|
|||
|
in before being installed;
|
|||
|
|
|||
|
* it generates a `.gdbinit' in the build directory, if needed, to
|
|||
|
communicate to `gdb' where to find the program's source code;
|
|||
|
|
|||
|
* it generates a shell script called `config.status' which is used
|
|||
|
most often by the `Makefile' to reconfigure itself;
|
|||
|
|
|||
|
* it recurses in subdirectories, setting up entire trees so that
|
|||
|
they build correctly; if `configure' finds another `configure'
|
|||
|
script further down in a given source tree, it knows to use this
|
|||
|
script and not recur.
|
|||
|
|
|||
|
For the sake of safety (i.e., in order to prevent broken
|
|||
|
installations), the GNU coding standards call for software to be
|
|||
|
"configured" in such a way that an end user trying to build a given
|
|||
|
package will be able to do so by affecting a finite number of
|
|||
|
variables. All GNU software comes with an executable `configure' shell
|
|||
|
script which sets up an environment within a build directory which will
|
|||
|
correctly compile your new package for your host (or, alternatively,
|
|||
|
whatever host you specify to `configure'). For further background on
|
|||
|
this topic, see *Note Apologia Configure: (cfg-paper)Some Basic Terms,
|
|||
|
by K. Richard Pixley.
|
|||
|
|
|||
|
Use `configure' to set for the build process:
|
|||
|
|
|||
|
* correct values for certain variables;
|
|||
|
|
|||
|
* which type of host you wish to configure a given package for
|
|||
|
(*note Host: Host.);
|
|||
|
|
|||
|
* where you want to install this package (by using `prefix',
|
|||
|
`exec-prefix' and `program-prefix'; *note Full descriptions of all
|
|||
|
installation directories: Install details.);
|
|||
|
|
|||
|
* optionally, which type of machine you wish to "target" this
|
|||
|
package's output to (*note Target: Target.);
|
|||
|
|
|||
|
* which other GNU packages are already installed and available to
|
|||
|
this particular build (by using the `--with-PACKAGE' option; *note
|
|||
|
Invoking `configure': Invoking configure.);
|
|||
|
|
|||
|
* where to place temporary files (by using the `--tmpdir=DIR'
|
|||
|
option; *note Invoking `configure': Invoking configure.);
|
|||
|
|
|||
|
* whether to recur in subdirectories (changeable through the
|
|||
|
`--norecursion' option; *note Invoking `configure': Invoking
|
|||
|
configure.).
|
|||
|
|
|||
|
`configure' uses a few other files to complete its tasks. These are
|
|||
|
discussed in detail where noted.
|
|||
|
|
|||
|
`configure.in'
|
|||
|
Input file for `configure'. Shell script fragments reside here.
|
|||
|
*Note The `configure.in' input file: configure.in.
|
|||
|
|
|||
|
`Makefile.in'
|
|||
|
Template which `configure' uses to build a file called `Makefile'
|
|||
|
in the "build directory". *Note `Makefile' generation: Makefile
|
|||
|
generation.
|
|||
|
|
|||
|
`config.sub'
|
|||
|
Shell script used by `configure' to expand referents to the
|
|||
|
HOSTTYPE argument into a single specification of the form
|
|||
|
CPU-VENDOR-OS. For instance, on the command line you can specify
|
|||
|
|
|||
|
eg$ ./configure sun4
|
|||
|
|
|||
|
to configure for a Sun SPARCstation running SunOS 4.x. `configure'
|
|||
|
consults `config.sub' to find that the three-part specification
|
|||
|
for this is
|
|||
|
|
|||
|
sparc-sun-sunos4.1.1
|
|||
|
|
|||
|
which notes the CPU as `sparc', the MANUFACTURER as `sun' (Sun
|
|||
|
Microsystems), and the OS (operating system) as `sunos4.1.1', the
|
|||
|
SunOS 4.1.1 release. *Note Variables available to `configure':
|
|||
|
configure variables.
|
|||
|
|
|||
|
`config.guess'
|
|||
|
If you do not put the HOSTTYPE argument on the command line,
|
|||
|
`configure' uses the `config.guess' shell script to make an
|
|||
|
analysis of your machine (it assumes that you wish to configure
|
|||
|
your software for the type of machine on which you are running).
|
|||
|
The output of `config.guess' is a three-part identifier as
|
|||
|
described above.
|
|||
|
|
|||
|
`config.status'
|
|||
|
The final step in configuring a directory is to create a shell
|
|||
|
script, `config.status'. The main purpose of this file is to
|
|||
|
allow the `Makefile' for the current directory to rebuild itself,
|
|||
|
if necessary. *Note `config.status': config.status.
|
|||
|
|
|||
|
`config/*'
|
|||
|
`configure' uses three types of `Makefile' "fragments", which
|
|||
|
reside in the directory `SRCDIR/config/'. *Note Adding
|
|||
|
information about local conventions: Makefile fragments.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* Build variables:: Variable-spaghetti made simple
|
|||
|
* Build directories:: Build directories described well
|
|||
|
* Makefile generation:: To build a Makefile
|
|||
|
* config.guess:: Be vewwy quiet, I'm hunting system information
|
|||
|
* config.status:: To rebuild a Makefile
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Build variables, Next: Build directories, Up: What configure really does
|
|||
|
|
|||
|
Build variables
|
|||
|
---------------
|
|||
|
|
|||
|
There are several variables in the build process which you can
|
|||
|
control through build programs such as `make'. These include machine
|
|||
|
definitions, local conventions, installation locations, locations for
|
|||
|
temporary files, etc. This data is accessible through certain
|
|||
|
variables which are configurable in the build process; we refer to them
|
|||
|
as "build variables".
|
|||
|
|
|||
|
For lists of build variables which you can affect by using
|
|||
|
`configure', see *Note Variables available to `configure.in': configure
|
|||
|
variables, and *Note Full descriptions of all installation directories:
|
|||
|
Install details.
|
|||
|
|
|||
|
Generally, build variables, which are used by the `Makefile' to
|
|||
|
determine various aspects of the build and installation processes, are
|
|||
|
changeable with command-line options to `configure'. In most large
|
|||
|
suites of programs, like the Cygnus Support Developer's Kit, the
|
|||
|
individual programs reside in several subdirectories of a single source
|
|||
|
code "tree". All of these subdirectories need to be configured with
|
|||
|
information relative to the "build directory", which is not known until
|
|||
|
`configure' is run. Unless specified otherwise, `configure'
|
|||
|
recursively configures every subdirectory in the source tree.
|
|||
|
|
|||
|
Build variables are passed from `configure' directly into the
|
|||
|
`Makefile', and use the same names (except that dashes are transformed
|
|||
|
into underbars; for example, when you specify the option
|
|||
|
`--exec-prefix' on the command line, the `Makefile' variable
|
|||
|
`exec_prefix' is set). In other words, if you specify
|
|||
|
|
|||
|
eg$ ./configure --prefix=/usr/gnu/local ... HOSTTYPE
|
|||
|
|
|||
|
on the command line, `configure' sets an variable called `prefix' to
|
|||
|
`/usr/gnu/local', and passes this into the `Makefile' in the same
|
|||
|
manner. After this command, each `Makefile' generated by `configure'
|
|||
|
will contain a line that reads:
|
|||
|
|
|||
|
prefix = /usr/gnu/local
|
|||
|
|
|||
|
For a list of the `Makefile' variables `configure' can change, and
|
|||
|
instructions on how to change them, see *Note Variables available to
|
|||
|
`configure.in': configure variables, and *Note Invoking `configure':
|
|||
|
Invoking configure.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Build directories, Next: Makefile generation, Prev: Build variables, Up: What configure really does
|
|||
|
|
|||
|
Build directories
|
|||
|
-----------------
|
|||
|
|
|||
|
By default, `configure' builds a `Makefile' and symbolic links in the
|
|||
|
same directory as the source files. This default works for many cases,
|
|||
|
but it has limitations. For instance, using this approach, you can
|
|||
|
only build object code for one host at a time.
|
|||
|
|
|||
|
We refer to each directory where `configure' builds a `Makefile' as
|
|||
|
a "build directory".
|
|||
|
|
|||
|
The build directory for any given build is always the directory from
|
|||
|
which you call `configure', or `.' relative to your prompt. The default
|
|||
|
"source directory", the place `configure' looks to find source code, is
|
|||
|
also `.'. For instance, if we have a directory `/gnu-stuff/src/' that
|
|||
|
is the top branch of a tree of GNU source code we wish to configure,
|
|||
|
then the program we will use to configure this code is
|
|||
|
`/gnu-stuff/src/configure', as follows. (Assume for the sake of
|
|||
|
argument that our machine is a sun4.)
|
|||
|
|
|||
|
eg$ cd /gnu-stuff/src
|
|||
|
eg$ ./configure sun4
|
|||
|
Created "Makefile" in /gnu-stuff/src
|
|||
|
eg$
|
|||
|
|
|||
|
We just configured the code in `/gnu-stuff/src' to run on a Sun
|
|||
|
SPARCstation using SunOS 4.x by creating a `Makefile' in
|
|||
|
`/gnu-stuff/src'. By default, we also specified that when this code is
|
|||
|
built, the object code should reside in the same directory,
|
|||
|
`/gnu-stuff/src'.
|
|||
|
|
|||
|
However, if we wanted to build this code for more than one host, we
|
|||
|
would be in trouble, because the new configuration would write over the
|
|||
|
old one, destroying it in the process. What we can do is to make a new
|
|||
|
"build directory" and configure from there. Running `configure' from
|
|||
|
the new directory will place a correct `Makefile' and a `config.status'
|
|||
|
in this new file. That is all `configure' does; we must run `make' to
|
|||
|
generate any object code.
|
|||
|
|
|||
|
The new `Makefile' in `/gnu-stuff/sun4-obj', created from the
|
|||
|
template file `/gnu-stuff/src/Makefile.in', contains all the information
|
|||
|
needed to build the program.
|
|||
|
|
|||
|
eg$ mkdir /gnu-stuff/sun4-obj
|
|||
|
eg$ cd /gnu-stuff/sun4-obj
|
|||
|
eg$ ../src/configure --srcdir=../src sun4
|
|||
|
Created "Makefile" in /gnu-stuff/sun4-obj
|
|||
|
eg$ ls
|
|||
|
Makefile config.status
|
|||
|
eg$ make all info install install-info clean
|
|||
|
COMPILATION MESSAGES...
|
|||
|
eg$ mkdir /gnu-stuff/solaris2
|
|||
|
eg$ cd /gnu-stuff/solaris2
|
|||
|
eg$ ../src/configure --srcdir=../src sol2
|
|||
|
Created "Makefile" in /gnu-stuff/solaris2
|
|||
|
eg$ ls
|
|||
|
Makefile config.status
|
|||
|
eg$ make all info install install-info clean
|
|||
|
COMPILATION MESSAGES...
|
|||
|
|
|||
|
We can repeat this for other configurations of the same software
|
|||
|
simply by making a new build directory and reconfiguring from inside
|
|||
|
it. If you do not specify the HOSTTYPE argument, `configure' will
|
|||
|
attempt to figure out what kind of machine and operating system you
|
|||
|
happen to be using. *Note Determining system information:
|
|||
|
config.guess. Of course, this may not always be the configuration you
|
|||
|
wish to build.
|
|||
|
|
|||
|
*Caution:* If you build more than one configuration for a single
|
|||
|
program, remember that you must also specify a different `--prefix' for
|
|||
|
each configuration at configure-time. Otherwise, both configurations
|
|||
|
will be installed in the same default location (`/usr/local'); the
|
|||
|
configuration to be installed last would overwrite previously installed
|
|||
|
configurations.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Makefile generation, Next: config.guess, Prev: Build directories, Up: What configure really does
|
|||
|
|
|||
|
`Makefile' generation
|
|||
|
---------------------
|
|||
|
|
|||
|
Cygnus `configure' creates a file called `Makefile' in the build
|
|||
|
directory which can be used with `make' to automatically build a given
|
|||
|
program or package. `configure' also builds a `Makefile' for each
|
|||
|
relevant subdirectory for a given program or package (irrelevant
|
|||
|
subdirectories would be those which contain no code which needs
|
|||
|
configuring, and which therefore have no `configure' input file
|
|||
|
`configure.in' and no `Makefile' template `Makefile.in'). *Note `make'
|
|||
|
Invocation: (make)Running, for details on using `make' to compile your
|
|||
|
source code.
|
|||
|
|
|||
|
Each `Makefile' contains variables which have been configured for a
|
|||
|
specific build. These build variables are determined when `configure'
|
|||
|
is run. All build variables have defaults. By default, `configure'
|
|||
|
generates a `Makefile' which specifies:
|
|||
|
|
|||
|
* a "native" build, which is to occur
|
|||
|
|
|||
|
* in the current directory, and which will be installed
|
|||
|
|
|||
|
* in the default installation directory (`/usr/local') when the code
|
|||
|
is compiled with `make'.
|
|||
|
|
|||
|
Variables are changeable through command-line options to `configure'
|
|||
|
(*note Invoking `configure': Invoking configure.).
|
|||
|
|
|||
|
If you are porting a new program and intend to use `configure', see
|
|||
|
*Note Porting with `configure': Porting, as well as *Note Writing
|
|||
|
Makefiles: (make)Makefiles, and *Note Makefile Conventions:
|
|||
|
(standards)Makefiles.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: config.guess, Next: config.status, Prev: Makefile generation, Up: What configure really does
|
|||
|
|
|||
|
Determining system information
|
|||
|
------------------------------
|
|||
|
|
|||
|
The shell script `config.guess' is called when you do not specify a
|
|||
|
HOSTTYPE on the command line to `configure'. `config.guess' acquires
|
|||
|
available system information from your local machine through the shell
|
|||
|
command `uname'. It compares this information to a database and
|
|||
|
attempts to determine a usable three-part system identifier (known as a
|
|||
|
"triple") to use as your HOSTTYPE. *Note What `configure' really does:
|
|||
|
What configure really does, to see how this information is used.
|
|||
|
|
|||
|
*Note:* If you do not specify a HOSTTYPE on the command line,
|
|||
|
`configure' will attempt to configure your software to run on the
|
|||
|
machine you happen to be using. This may not be the configuration you
|
|||
|
desire.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: config.status, Prev: config.guess, Up: What configure really does
|
|||
|
|
|||
|
`config.status'
|
|||
|
---------------
|
|||
|
|
|||
|
The final step in configuring a directory is to create an executable
|
|||
|
shell script, `config.status'. The main purpose of this file is to
|
|||
|
allow the `Makefile' for the current directory to rebuild itself, if
|
|||
|
necessary. It is usually run from within the `Makefile'. *Note
|
|||
|
Extensions to the GNU coding standards: Makefile extensions.
|
|||
|
|
|||
|
`config.status' also contains a record of the `configure' session
|
|||
|
which created it.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: configure.in, Next: Install locations, Prev: What configure really does, Up: Using configure
|
|||
|
|
|||
|
The `configure.in' input file
|
|||
|
=============================
|
|||
|
|
|||
|
A `configure.in' file for Cygnus `configure' consists of a
|
|||
|
"per-invocation" section, followed by a "per-host" section, followed by
|
|||
|
a "per-target" section, optionally followed by a "post-target" section.
|
|||
|
Each section is a shell script fragment, which is executed by the
|
|||
|
`configure' shell script at an appropriate time. Values are passed
|
|||
|
among `configure' and the shell fragments through a set of shell
|
|||
|
variables. When each section is being interpreted by the shell, the
|
|||
|
shell's current directory is the build directory, and any files created
|
|||
|
by the section (or referred to by the section) will be relative to the
|
|||
|
build directory. To reference files in other places (such as the
|
|||
|
source directory), prepend a shell variable such as `$(srcdir)/' to the
|
|||
|
desired file name.
|
|||
|
|
|||
|
The beginning of the `configure.in' file begins the "per-invocation"
|
|||
|
section.
|
|||
|
|
|||
|
A line beginning with `# per-host:' begins the "per-host" section.
|
|||
|
|
|||
|
A line beginning with `# per-target:' begins the "per-target"
|
|||
|
section.
|
|||
|
|
|||
|
If it exists, the "post-target" section begins with `# post-target:'.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* configure variables:: Variables available to configure.in
|
|||
|
* Minimal:: A minimal configure.in
|
|||
|
* Declarations:: For each invocation
|
|||
|
* per-host:: Host-specific instructions
|
|||
|
* per-target:: Target-specific instructions
|
|||
|
* post-target:: Instructions to be executed after target info
|
|||
|
* Example:: An example configure.in
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: configure variables, Next: Minimal, Up: configure.in
|
|||
|
|
|||
|
Variables available to `configure.in'
|
|||
|
-------------------------------------
|
|||
|
|
|||
|
The following variables pass information between the standard parts
|
|||
|
of `configure' and the shell-script fragments in `configure.in':
|
|||
|
|
|||
|
`srctrigger'
|
|||
|
Contains the name of a source file that is expected to live in the
|
|||
|
source directory. You must usually set this in the
|
|||
|
"per-invocation" section of `configure.in'. `configure' tests to
|
|||
|
see that this file exists. If the file does not exist,
|
|||
|
`configure' prints an error message. This is used as a sanity
|
|||
|
check that `configure.in' matches the source directory.
|
|||
|
|
|||
|
`srcname'
|
|||
|
Contains the name of the source collection contained in the source
|
|||
|
directory. You must usually set this in the "per-invocation"
|
|||
|
section of `configure.in'. If the file named in `srctrigger' does
|
|||
|
not exist, `configure' uses the value of `srcname' when it prints
|
|||
|
the error message.
|
|||
|
|
|||
|
`configdirs'
|
|||
|
Contains the names of any subdirectories in which `configure'
|
|||
|
should recurse. You must usually set this in the "per-invocation"
|
|||
|
section of `configure.in'. If `Makefile.in' contains a line
|
|||
|
starting with `SUBDIRS =', then it will be replaced with an
|
|||
|
assignment to `SUBDIRS' using the value of `configdirs' (if
|
|||
|
`subdirs' is empty). This can be used to determine which
|
|||
|
directories to configure and build depending on the host and
|
|||
|
target configurations. Use `configdirs' (instead of the `subdirs'
|
|||
|
variable described below) if you want to be able to partition the
|
|||
|
subdirectories, or use independent `Makefile' fragments. Each
|
|||
|
subdirectory can be independent, and independently reconfigured.
|
|||
|
|
|||
|
`subdirs'
|
|||
|
Contains the names of any subdirectories where `configure' should
|
|||
|
create a `Makefile' (in addition to the current directory),
|
|||
|
*without* recursively running `configure'. Use `subdirs' (instead
|
|||
|
of the `configdirs' variable described above) if you want to
|
|||
|
configure all of the directories as a unit. Since there is a
|
|||
|
single invocation of `configure' that configures many directories,
|
|||
|
all the directories can use the same `Makefile' fragments, and the
|
|||
|
same `configure.in'.
|
|||
|
|
|||
|
`host'
|
|||
|
Contains the full configuration name for the host (generated by
|
|||
|
the script `config.sub' from the name that you entered). This is
|
|||
|
a three-part name (commonly referred to as a "triple") of the form
|
|||
|
CPU-VENDOR-OS.
|
|||
|
|
|||
|
There are separate variables `host_cpu', `host_vendor', and
|
|||
|
`host_os' that you can use to test each of the three parts; this
|
|||
|
variable is useful, however, for error messages, and for testing
|
|||
|
combinations of the three components.
|
|||
|
|
|||
|
`host_cpu'
|
|||
|
Contains the first element of the canonical triple representing
|
|||
|
the host as returned by `config.sub'. This is occasionally used to
|
|||
|
distinguish between minor variations of a particular vendor's
|
|||
|
operating system and sometimes to determine variations in binary
|
|||
|
format between the host and the target.
|
|||
|
|
|||
|
`host_vendor'
|
|||
|
Contains the second element of the canonical triple representing
|
|||
|
the host as returned by `config.sub'. This is usually used to
|
|||
|
distinguish among the numerous variations of *common* operating
|
|||
|
systems.
|
|||
|
|
|||
|
`host_os'
|
|||
|
Contains the the third element of the canonical triple
|
|||
|
representing the host as returned by `config.sub'.
|
|||
|
|
|||
|
`target'
|
|||
|
Contains the full configuration name (generated by the script
|
|||
|
`config.sub' from the name that you entered) for the target. Like
|
|||
|
the host, this is a three-part name of the form CPU-VENDOR-OS.
|
|||
|
|
|||
|
There are separate variables `target_cpu', `target_vendor', and
|
|||
|
`target_os' that you can use to test each of the three parts; this
|
|||
|
variable is useful, however, for error messages, and for testing
|
|||
|
combinations of the three components.
|
|||
|
|
|||
|
`target_cpu'
|
|||
|
Contains the first element of the canonical triple representing
|
|||
|
the target as returned by `config.sub'. This variable is used
|
|||
|
heavily by programs which are involved in building other programs,
|
|||
|
like the compiler, assembler, linker, etc. Most programs will not
|
|||
|
need the `target' variables at all, but this one could conceivably
|
|||
|
be used to build a program, for instance, that operated on binary
|
|||
|
data files whose byte order or alignment differ from the system
|
|||
|
where the program is running.
|
|||
|
|
|||
|
`target_vendor'
|
|||
|
Contains the second element of the canonical triple representing
|
|||
|
the target as returned by `config.sub'. This is usually used to
|
|||
|
distinguish among the numerous variations of *common* operating
|
|||
|
systems or object file formats. It is sometimes used to switch
|
|||
|
between different flavors of user interfaces.
|
|||
|
|
|||
|
`target_os'
|
|||
|
Contains the the third element of the canonical triple
|
|||
|
representing the target as returned by `config.sub'. This
|
|||
|
variable is used by development tools to distinguish between
|
|||
|
subtle variations in object file formats that some vendors use
|
|||
|
across operating system releases. It might also be use to decide
|
|||
|
which libraries to build or what user interface the tool should
|
|||
|
provide.
|
|||
|
|
|||
|
`floating_point'
|
|||
|
Set to `no' if you invoked `configure' with the `--nfp'
|
|||
|
command-line option, otherwise it is empty. This is a request to
|
|||
|
target machines with "no floating point" unit, even if the targets
|
|||
|
ordinarily have floating point units available.
|
|||
|
|
|||
|
`gas'
|
|||
|
Set to `true' if you invoked `configure' with the `--with-gnu-as'
|
|||
|
command line option, otherwise it is empty. This is a request to
|
|||
|
assume that the specified HOSTTYPE machine has GNU `as' available
|
|||
|
even if it ordinarily does not.
|
|||
|
|
|||
|
`srcdir'
|
|||
|
Set to the name of the directory containing the source for this
|
|||
|
program. This will be different from `.' if you have specified the
|
|||
|
`--srcdir=DIR' option. `srcdir' can indicate either an absolute
|
|||
|
path or a path relative to the build directory.
|
|||
|
|
|||
|
`package_makefile_frag'
|
|||
|
If set in `configure.in', this variable should be the name a file
|
|||
|
relative to `srcdir' to be included in the resulting `Makefile'.
|
|||
|
If the named file does not exist, `configure' will print a warning
|
|||
|
message. This variable is not set by `configure'.
|
|||
|
|
|||
|
`host_makefile_frag'
|
|||
|
If set in `configure.in', this variable should be the name a file
|
|||
|
relative to `srcdir' to be included in the resulting `Makefile'.
|
|||
|
If the named file does not exist, `configure' will print a warning
|
|||
|
message. This variable is not set by `configure'.
|
|||
|
|
|||
|
`target_makefile_frag'
|
|||
|
If set in `configure.in', this variable should be the name of a
|
|||
|
file, relative to `srcdir', to be included in the resulting
|
|||
|
`Makefile'. If the named file does not exist, `configure' will
|
|||
|
print a warning message. This variable is not set by `configure'.
|
|||
|
|
|||
|
`site_makefile_frag'
|
|||
|
Set to a file name representing to the default `Makefile' fragment
|
|||
|
for this host. It may be set in `configure.in' to override this
|
|||
|
default. Normally `site_makefile_frag' is empty, but will have a
|
|||
|
value if you specify `--site=SITE' on the command line.
|
|||
|
|
|||
|
`Makefile'
|
|||
|
Set to the name of the generated `Makefile'. Normally this value
|
|||
|
is precisely `Makefile', but some programs may want something else.
|
|||
|
|
|||
|
`removing'
|
|||
|
Normally empty but will be set to some non-null value if you
|
|||
|
specified `--rm' on the command line. That is, if `removing' is
|
|||
|
not empty, then `configure' is *removing* a configuration rather
|
|||
|
than creating one.
|
|||
|
|
|||
|
`files'
|
|||
|
If this variable is not empty following the "per-target" section,
|
|||
|
then each word in its value will be the target of a symbolic link
|
|||
|
named in the corresponding word from the `links' variable.
|
|||
|
|
|||
|
`links'
|
|||
|
If the `files' variable is not empty following the "per-target"
|
|||
|
section, then `configure' creates symbolic links with the first
|
|||
|
word of `links' pointing to the first word of `files', the second
|
|||
|
word of `links' pointing to the second word of `files', and so on.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Minimal, Next: Declarations, Prev: configure variables, Up: configure.in
|
|||
|
|
|||
|
A minimal `configure.in'
|
|||
|
------------------------
|
|||
|
|
|||
|
A minimal `configure.in' consists of four lines.
|
|||
|
|
|||
|
srctrigger=foo.c
|
|||
|
srcname="source for the foo program"
|
|||
|
# per-host:
|
|||
|
# per-target:
|
|||
|
|
|||
|
The `# per-host:' and `# per-target:' lines divide the file into the
|
|||
|
three required sections. The `srctrigger' line names a file.
|
|||
|
`configure' checks to see that this file exists in the source directory
|
|||
|
before configuring. If the `srctrigger' file does not exist,
|
|||
|
`configure' uses the value of `srcname' to print an error message about
|
|||
|
not finding the source.
|
|||
|
|
|||
|
This particular example uses no links, and only the default host,
|
|||
|
target, and site-specific `Makefile' fragments if they exist.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Declarations, Next: per-host, Prev: Minimal, Up: configure.in
|
|||
|
|
|||
|
For each invocation
|
|||
|
-------------------
|
|||
|
|
|||
|
`configure' invokes the entire shell script fragment from the start
|
|||
|
of `configure.in' up to a line beginning with `# per-host:' immediately
|
|||
|
after parsing command line arguments. The variables `srctrigger' and
|
|||
|
`srcname' *must* be set here.
|
|||
|
|
|||
|
You might also want to set the variables `configdirs' and
|
|||
|
`package_makefile_frag' here.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: per-host, Next: per-target, Prev: Declarations, Up: configure.in
|
|||
|
|
|||
|
Host-specific instructions
|
|||
|
--------------------------
|
|||
|
|
|||
|
The "per-host" section of `configure.in' starts with the line that
|
|||
|
begins with `# per-host:' and ends before a line beginning with
|
|||
|
`# per-target:'. `configure' invokes the commands in the "per-host"
|
|||
|
section when determining host-specific information.
|
|||
|
|
|||
|
This section usually contains a big `case' statement using the
|
|||
|
variable `host' to determine appropriate values for
|
|||
|
`host_makefile_frag' and `files', although `files' is not usually set
|
|||
|
here. Usually, it is set at the end of the "per-target" section after
|
|||
|
determining the names of the target specific configuration files.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: per-target, Next: post-target, Prev: per-host, Up: configure.in
|
|||
|
|
|||
|
Target-specific instructions
|
|||
|
----------------------------
|
|||
|
|
|||
|
The "per-target" section of `configure.in' starts with the line that
|
|||
|
begins with `# per-target:' and ends before the line that begins with
|
|||
|
`# post-target:', if there is such a line. Otherwise the "per-target"
|
|||
|
section extends to the end of the file. `configure' invokes the
|
|||
|
commands in the "per-target" section when determining target-specific
|
|||
|
information, and before building any files, directories, or links.
|
|||
|
|
|||
|
This section usually contains a big `case' statement using the
|
|||
|
variable `target' to determine appropriate values for
|
|||
|
`target_makefile_frag' and `files'. The last lines in the "per-target"
|
|||
|
section normally set the variables `files' and `links'.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: post-target, Next: Example, Prev: per-target, Up: configure.in
|
|||
|
|
|||
|
Instructions to be executed after target info
|
|||
|
---------------------------------------------
|
|||
|
|
|||
|
The "post-target" section is optional. If it exists, the
|
|||
|
`post-target' section starts with a line beginning with
|
|||
|
`# Post-target:' and extends to the end of the file. If it exists,
|
|||
|
`configure' invokes this section once for each target after building
|
|||
|
all files, directories, or links.
|
|||
|
|
|||
|
This section is seldom needed, but you can use it to edit the
|
|||
|
`Makefile' generated by `configure'.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Example, Prev: post-target, Up: configure.in
|
|||
|
|
|||
|
An example `configure.in'
|
|||
|
-------------------------
|
|||
|
|
|||
|
Here is a small example of a `configure.in' file.
|
|||
|
|
|||
|
# This file is a collection of shell script fragments
|
|||
|
# used to tailor a template configure script as
|
|||
|
# appropriate for this directory. For more information,
|
|||
|
# see configure.texi.
|
|||
|
|
|||
|
configdirs=
|
|||
|
srctrigger=warshall.c
|
|||
|
srcname="bison"
|
|||
|
|
|||
|
# per-host:
|
|||
|
case "${host}" in
|
|||
|
m88k-motorola-*)
|
|||
|
host_makefile_frag=config/mh-delta88
|
|||
|
;;
|
|||
|
esac
|
|||
|
|
|||
|
# per-target:
|
|||
|
files="bison_in.hairy"
|
|||
|
links="bison.hairy"
|
|||
|
|
|||
|
# post-target:
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Install locations, Next: Host, Prev: configure.in, Up: Using configure
|
|||
|
|
|||
|
Install locations
|
|||
|
=================
|
|||
|
|
|||
|
Using the default configuration, `make install' creates a single
|
|||
|
tree of files, some of which are programs. The location of this tree
|
|||
|
is determined by the value of the variable `prefix'. The default value
|
|||
|
of `prefix' is `/usr/local'. This is often correct for native tools
|
|||
|
installed on only one host.
|
|||
|
|
|||
|
* Menu:
|
|||
|
|
|||
|
* prefix:: Changing the default install directory
|
|||
|
* exec_prefix:: How to separate host independent files
|
|||
|
from host dependent files when
|
|||
|
installing for multiple hosts
|
|||
|
* Install details:: Full descriptions of all installation subdirectories
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: prefix, Next: exec_prefix, Up: Install locations
|
|||
|
|
|||
|
Changing the default install directory
|
|||
|
--------------------------------------
|
|||
|
|
|||
|
In the default configuration, all files are installed in
|
|||
|
subdirectories of `/usr/local'. The location is determined by the
|
|||
|
value of the `configure' variable `prefix'; in turn, this determines the
|
|||
|
value of the `Makefile' variable of the same name (`prefix').
|
|||
|
|
|||
|
You can also set the value of the `Makefile' variable `prefix'
|
|||
|
explicitly each time you invoke `make' if you are so inclined. However,
|
|||
|
because many programs have this location compiled in, you must specify
|
|||
|
the `prefix' value consistently on each invocation of `make', or you
|
|||
|
will end up with a broken installation.
|
|||
|
|
|||
|
To make this easier, the value of the `configure' variable `prefix'
|
|||
|
can be set on the command line to `configure' using the option
|
|||
|
`--prefix='.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: exec_prefix, Next: Install details, Prev: prefix, Up: Install locations
|
|||
|
|
|||
|
Installing for multiple hosts
|
|||
|
-----------------------------
|
|||
|
|
|||
|
By default, host dependent files are installed in subdirectories of
|
|||
|
`$(exec_prefix)'. The location is determined by the value of the
|
|||
|
`configure' variable `exec_prefix', which determines the value of the
|
|||
|
`Makefile' variable `exec_prefix'. This makes it easier to install for
|
|||
|
a single host, and simplifies changing the default location for the
|
|||
|
install tree. The default doesn't allow for multiple hosts to
|
|||
|
effectively share host independent files, however.
|
|||
|
|
|||
|
To configure so that multiple hosts can share common files, use
|
|||
|
something like:
|
|||
|
|
|||
|
configure HOST1 -prefix=/usr/gnu -exec_prefix=/usr/gnu/H-host1
|
|||
|
make all info install install-info clean
|
|||
|
|
|||
|
configure HOST2 -prefix=/usr/gnu -exec_prefix=/usr/gnu/H-host2
|
|||
|
make all info install install-info
|
|||
|
|
|||
|
The first line configures the source for HOST1 to place host-specific
|
|||
|
programs in subdirectories of `/usr/gnu/H-HOST1'.
|
|||
|
|
|||
|
The second line builds and installs all programs for HOST1,
|
|||
|
including both host-independent and host-specific files, as well as
|
|||
|
removing the host-specific object files from of the build directory.
|
|||
|
|
|||
|
The third line reconfigures the source for HOST2 to place host
|
|||
|
specific programs in subdirectories of `/usr/gnu/H-HOST2'.
|
|||
|
|
|||
|
The fourth line builds and installs all programs for HOST2. Host
|
|||
|
specific files are installed in new directories, but the host
|
|||
|
independent files are installed *on top of* the host independent files
|
|||
|
installed for HOST1. This results in a single copy of the host
|
|||
|
independent files, suitable for use by both hosts.
|
|||
|
|
|||
|
*Note Extensions to the GNU coding standards: Makefile extensions,
|
|||
|
for more information.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Install details, Prev: exec_prefix, Up: Install locations
|
|||
|
|
|||
|
Full descriptions of all installation subdirectories
|
|||
|
----------------------------------------------------
|
|||
|
|
|||
|
During any install, a number of standard directories are created.
|
|||
|
Their names are determined by `Makefile' variables. Some of the
|
|||
|
defaults for `Makefile' variables can be changed at configuration time
|
|||
|
using command line options to `configure'. For more information on the
|
|||
|
standard directories or the `Makefile' variables, please refer to *Note
|
|||
|
Makefile Conventions: (standards)Makefiles. See also *Note Extensions
|
|||
|
to the GNU coding standards: Makefile extensions.
|
|||
|
|
|||
|
Note that `configure' does not create the directory indicated by the
|
|||
|
variable `srcdir' at any time. `$(srcdir)' is not an installation
|
|||
|
directory.
|
|||
|
|
|||
|
You can override all `Makefile' variables on the command line to
|
|||
|
`make'. (*Note Overriding Variables: (make)Overriding.) If you do so,
|
|||
|
you will need to specify the value precisely the same way for each
|
|||
|
invocation of `make', or you risk ending up with a broken installation.
|
|||
|
This is because many programs have the locations of other programs or
|
|||
|
files compiled into them. If you find yourself overriding any of the
|
|||
|
variables frequently, you should consider site dependent `Makefile'
|
|||
|
fragments. See also *Note Adding site info: Sites.
|
|||
|
|
|||
|
During `make install', a number of standard directories are created
|
|||
|
and populated. The following `Makefile' variables define them. Those
|
|||
|
whose defaults are set by corresponding `configure' variables are marked
|
|||
|
"`Makefile' and `configure'".
|
|||
|
|
|||
|
`prefix (`Makefile' and `configure')'
|
|||
|
The root of the installation tree. You can set its `Makefile'
|
|||
|
default with the `--prefix=' command line option to `configure'
|
|||
|
(*note Invoking `configure': Invoking configure.). The default
|
|||
|
value for `prefix' is `/usr/local'.
|
|||
|
|
|||
|
`bindir'
|
|||
|
A directory for binary programs that users can run. The default
|
|||
|
value for `bindir' depends on `prefix'; `bindir' is normally
|
|||
|
changed only indirectly through `prefix'. The default value for
|
|||
|
`bindir' is `$(prefix)/bin'.
|
|||
|
|
|||
|
`exec_prefix (`Makefile' and `configure')'
|
|||
|
A directory for host dependent files. You can specify the
|
|||
|
`Makefile' default value by using the `--exec_prefix=' option to
|
|||
|
`configure'. (*Note Invoking `configure': Invoking configure.)
|
|||
|
The default value for `exec_prefix' is `$(prefix)'.
|
|||
|
|
|||
|
`libdir'
|
|||
|
A directory for libraries and support programs. The default value
|
|||
|
for `libdir' depends on `prefix'; `libdir' is normally changed only
|
|||
|
indirectly through `prefix'. The default value for `libdir' is
|
|||
|
`$(prefix)/lib'.
|
|||
|
|
|||
|
`mandir'
|
|||
|
A directory for `man' format documentation ("man pages"). The
|
|||
|
default value for `mandir' depends on `prefix'; `mandir' is
|
|||
|
normally changed only indirectly through `prefix'. The default
|
|||
|
value for `mandir' is `$(prefix)/man'.
|
|||
|
|
|||
|
`manNdir'
|
|||
|
These are eight variables named `man1dir', `man2dir', etc. They
|
|||
|
name the specific directories for each man page section. For
|
|||
|
example, `man1dir' by default holds the filename `$(mandir)/man1';
|
|||
|
this directory contains `emacs.1' (the man page for GNU Emacs).
|
|||
|
Similarly, `man5dir' contains the value `$(mandir)/man5',
|
|||
|
indicating the directory which holds `rcsfile.5' (the man page
|
|||
|
describing the `rcs' data file format). The default value for any
|
|||
|
of the `manNdir' variables depends indirectly on `prefix', and is
|
|||
|
normally changed only through `prefix'. The default value for
|
|||
|
`manNdir' is `$(mandir)/manN'.
|
|||
|
|
|||
|
`manNext'
|
|||
|
*Not supported by Cygnus `configure'*. The `GNU Coding Standards'
|
|||
|
do not call for `man1ext', `man2ext', so the intended use for
|
|||
|
`manext' is apparently not parallel to `mandir'. Its use is not
|
|||
|
clear. (See also *Note Extensions to the GNU coding standards:
|
|||
|
Makefile extensions.)
|
|||
|
|
|||
|
`infodir'
|
|||
|
A directory for `info' format documentation. The default value for
|
|||
|
`infodir' depends indirectly on `prefix'; `infodir' is normally
|
|||
|
changed only through `prefix'. The default value for `infodir' is
|
|||
|
`$(prefix)/info'.
|
|||
|
|
|||
|
`docdir'
|
|||
|
A directory for any documentation that is in a format other than
|
|||
|
those used by `info' or `man'. The default value for `docdir'
|
|||
|
depends indirectly on `prefix'; `docdir' is normally changed only
|
|||
|
through `prefix'. The default value for `docdir' is
|
|||
|
`$(datadir)/doc'. *This variable is an extension to the GNU
|
|||
|
coding standards*. (See also *Note Extensions to the GNU coding
|
|||
|
standards: Makefile extensions.)
|
|||
|
|
|||
|
`includedir'
|
|||
|
A directory for the header files accompanying the libraries
|
|||
|
installed in `libdir'. The default value for `includedir' depends
|
|||
|
on `prefix'; `includedir' is normally changed only indirectly
|
|||
|
through `prefix'. The default value for `includedir' is
|
|||
|
`$(prefix)/include'.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Host, Next: Target, Prev: Install locations, Up: Using configure
|
|||
|
|
|||
|
Host
|
|||
|
====
|
|||
|
|
|||
|
The arguments to `configure' are "hosttypes". By "hosttype" we mean
|
|||
|
the "environment" in which the source will be compiled. This need not
|
|||
|
necessarily be the same as the physical machine involved, although it
|
|||
|
usually is.
|
|||
|
|
|||
|
For example, if some obscure machine had the GNU `POSIX' emulation
|
|||
|
libraries available, it would be possible to configure most GNU source
|
|||
|
for a `POSIX' system and build it on the obscure host.
|
|||
|
|
|||
|
For more on this topic, see *Note On Configuring Development Tools:
|
|||
|
(cfg-paper)Host Environments.
|
|||
|
|
|||
|
|
|||
|
File: configure.info, Node: Target, Next: Makefile fragments, Prev: Host, Up: Using configure
|
|||
|
|
|||
|
Target
|
|||
|
======
|
|||
|
|
|||
|
For building native development tools, or most of the other GNU
|
|||
|
tools, you need not worry about the target. The "target" of a
|
|||
|
configuration defaults to the same as the "host".
|
|||
|
|
|||
|
For building cross development tools, please see *Note On
|
|||
|
Configuring Development Tools: (cfg-paper)Building Development
|
|||
|
Environments.
|
|||
|
|