1411 lines
50 KiB
Text
1411 lines
50 KiB
Text
\input texinfo @c -*-para-*-
|
|
@c %**start of header
|
|
@setfilename configure.info
|
|
@settitle Cygnus Configure
|
|
@c %**end of header
|
|
@setchapternewpage off
|
|
|
|
@ifinfo
|
|
This document attempts to describe the Cygnus Support version of
|
|
@code{configure}.
|
|
|
|
Copyright (C) 1991 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.
|
|
|
|
@ignore
|
|
Permission is granted to process this file through TeX and print the
|
|
results, provided the printed document carries copying permission
|
|
notice identical to this one except for the removal of this paragraph
|
|
(this paragraph not being relevant to the printed manual).
|
|
|
|
@end ignore
|
|
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.
|
|
@end ifinfo
|
|
|
|
@titlepage
|
|
@sp 10
|
|
@title{Cygnus Configure}
|
|
@subtitle Edition ``$Revision$'' for Cygnus Configure version 1.84
|
|
@author{K. Richard Pixley, @code{rich@@cygnus.com}}
|
|
@author{Cygnus Support}
|
|
@page
|
|
|
|
@vskip 0pt plus 1filll
|
|
Copyright @copyright{} 1991 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.
|
|
@end titlepage
|
|
|
|
@ifinfo
|
|
@format
|
|
START-INFO-DIR-ENTRY
|
|
* configure: (configure.info). Cygnus configure.
|
|
END-INFO-DIR-ENTRY
|
|
@end format
|
|
|
|
@node top, Invoking, (dir), (dir)
|
|
@top top
|
|
|
|
This file documents the configuration system used and distributed by
|
|
Cygnus Support.
|
|
|
|
NOTE: support for a Cygnus experimental option, @code{-subdirs} is at
|
|
least temporarily suspended. Most of the code is still in configure but
|
|
the option is disabled. This document describes that feature, but those
|
|
parts are prominently marked with NOTE's like this one. FIXME-soon
|
|
|
|
@menu
|
|
* Invoking:: Invoking
|
|
* Using Configure:: Using Configure
|
|
* What Configure Does:: What Configure Does
|
|
* Porting:: Porting with Configure
|
|
* Reference:: Gory details described
|
|
* Known Bugs:: Known Bugs
|
|
* Variables Index:: Variable Index
|
|
* Concept Index:: Concept Index
|
|
|
|
@end menu
|
|
|
|
@end ifinfo
|
|
|
|
@iftex
|
|
@unnumbered Preface
|
|
NOTE: support for a Cygnus experimental option, @code{-subdirs} is at
|
|
least temporarily suspended. Most of the code is still in configure but
|
|
the option is disabled. This document describes that feature, but those
|
|
parts are prominently marked with NOTE's like this one. FIXME-soon
|
|
@end iftex
|
|
|
|
@node Invoking, Using Configure, top, top
|
|
@chapter Invoking
|
|
|
|
The usual way to invoke @code{configure} is as follows:
|
|
@example
|
|
configure @var{host}
|
|
@end example
|
|
This asks @code{configure} to prepare the source to be compiled in a
|
|
@var{host} environment with programs and files to be installed in
|
|
@file{/usr/local}.
|
|
|
|
NOTE: support for multiple hosts is at least temporarily suspended.
|
|
FIXME-soon
|
|
|
|
If more than one host is specified on the command line, then
|
|
configurations are created for each and @code{-subdirs} is assumed.
|
|
|
|
@table @code
|
|
|
|
@item -datadir=@var{dir}
|
|
This option requests that the source be configured so that host
|
|
independent files will be installed in @var{dir}.
|
|
|
|
This option sets the @code{configure} variable @code{datadir}. If
|
|
@code{datadir} is not empty, generated Makefiles will have their
|
|
@code{datadir} variables set to this value. (See @xref{Install Details}.)
|
|
|
|
@item -gas
|
|
Notifies @code{configure} that the @sc{GNU} assembler is available on
|
|
all specified hosts.
|
|
|
|
@item -help
|
|
Displays a quick summary of how to invoke @code{configure}.
|
|
|
|
@item -host=@var{host}
|
|
FIXME-soon: I don't think this option should be documented.
|
|
|
|
NOTE: support for this @code{-namesubdir=} is at least temporary
|
|
suspended. FIXME-soon
|
|
|
|
@item -namesubdir=@var{name}
|
|
Asks that any subdirectories created by the @code{-subdirs} option be
|
|
named @var{name}. Note that using multiple hosts with
|
|
@code{-namesubdir=} isn't terribly useful.
|
|
|
|
@item -nfp
|
|
Notifies @code{configure} that all of the specified targets have
|
|
@emph{no floating point} units.
|
|
|
|
@item -norecursion
|
|
Asks @code{configure} to configure only this directory. Any
|
|
subdirectories are ignored. This is used by the executable shell script
|
|
@file{config.status} to reconfigure the current directory.
|
|
(see @xref{config.status}).
|
|
|
|
@item -objdir=@var{dir}
|
|
This option is no longer supported. Use @code{-srcdir=} instead.
|
|
|
|
@item -prefix=@var{dir}
|
|
This option requests that the source be configured so that programs and
|
|
files will be installed in @var{dir}.
|
|
|
|
This option sets the @code{configure} variable @code{prefix}. If
|
|
@code{prefix} is not empty, generated Makefiles will have their
|
|
@code{prefix} variables set to this value. (See @xref{Install Details}.)
|
|
|
|
@item -recurring
|
|
This option is used internally by @code{configure} when recurring on
|
|
subdirectories. It's sole purpose is to supress status output. It can
|
|
be overriden with the @code{-verbose} option.
|
|
|
|
@item -rm
|
|
Asks @code{configure} to @emph{remove} a configuration rather than
|
|
create one.
|
|
|
|
@item -site=@var{site}
|
|
Asks that Makefiles be generated using site specific Makefiles for
|
|
@var{site}. See also @xref{Sites}.
|
|
|
|
@item -srcdir=@var{_dir}
|
|
Tells @code{configure} that the sources are located in @var{dir}. The
|
|
build directory is assumed to be @file{.}.
|
|
|
|
NOTE: support for this @code{-subdirs} is at least temporary suspended.
|
|
FIXME-soon
|
|
|
|
@item -subdirs
|
|
Asks that configurations be placed in subdirectories named
|
|
@file{H-@var{host}} of each build directory, for each host specified.
|
|
If this configuration is not native, (@var{host} is not @var{target}),
|
|
then he subdir will be named @file{X-@var{host}-@var{target}} instead.
|
|
|
|
NOTE: support for multiple targets is at least temporarily suspended.
|
|
FIXME-soon
|
|
|
|
@item -target=@var{target}
|
|
Requests that the sources be configured to target the @var{target}
|
|
machine. If no targets are specified explicitly, the target is assumed
|
|
to be the same as the host. If multiple targets are specified,
|
|
configurations for each are created and @code{-subdirs} is assumed.
|
|
|
|
@item -tmpdir=@var{tmpdir}
|
|
Sets the directory in which @code{configure} creates temporary files to
|
|
@var{tmpdir}.
|
|
|
|
@item -verbose
|
|
@item -v
|
|
Asks that @code{configure} print status lines for each directory
|
|
configured. Normally, only the status lines for the current directory
|
|
are printed.
|
|
|
|
@item -x
|
|
Tells @code{configure} that @sc{MIT} style @sc{X11} header files and
|
|
libraries are available on the host, even if they are not normally
|
|
available.
|
|
|
|
@end table
|
|
|
|
@node Using Configure, What Configure Does, Invoking, top
|
|
@chapter Using Configure
|
|
|
|
Configure prepares source directories in anticipation of building.
|
|
Source cannot be built until it has been configured. The choices
|
|
and options available at configuration time generally have valid
|
|
defaults, but the defaults do not cover all cases. The choices
|
|
available include install locations, build directories, host, target,
|
|
and local conventions.
|
|
|
|
@menu
|
|
* Install Locations:: Where to install things once they are built
|
|
* Build Directories:: Where to build object files
|
|
* Host:: Telling @code{configure} what will source will
|
|
be built
|
|
* Target:: Telling @code{configure} what the source will
|
|
target
|
|
* Local Conventions:: Adding information about local conventions
|
|
@end menu
|
|
|
|
@node Install Locations, Build Directories, Using Configure, Using Configure
|
|
@section Install Locations
|
|
|
|
@cindex Where to install
|
|
|
|
Using the default configuration, @code{make install} will create a
|
|
single tree of files, some of which are programs. The location of this
|
|
tree is determined by the value of the variable @code{prefix}. The
|
|
default value of @code{prefix} is @file{/usr/local}. This is
|
|
probably correct for native tools installed on only one host.
|
|
|
|
@menu
|
|
* prefix:: Changing the default install directory
|
|
* datadir:: How to separate host independent files
|
|
from host dependent files when
|
|
installing for multiple hosts
|
|
* Install Details:: Full descriptions of all installation
|
|
subdirectories
|
|
@end menu
|
|
|
|
@node prefix, datadir, Install Locations, Install Locations
|
|
@subsection Changing the default install directory
|
|
|
|
@cindex Changing the default install directory
|
|
@cindex Prefix directory
|
|
|
|
In the default configuration, all files are installed in subdirectories
|
|
of @file{/usr/local}. The actual location is determined by the value of
|
|
the @code{configure} variable @code{prefix} which determines the
|
|
value of the Makefile variable @code{prefix}.
|
|
|
|
You can also set the value of the Makefile variable @code{prefix}
|
|
explicitly each time you invoke @code{make} if you are so inclined, but
|
|
because many programs have this location compiled in, you must specify
|
|
the @code{prefix} value precisely on each invocation of @code{make}
|
|
or you will end up with a broken installation.
|
|
|
|
To make this easier, the value of the @code{configure} variable
|
|
@code{prefix} can be set on the command line to @code{configure}
|
|
using the option @code{-prefix=}. (See @xref{prefix}).
|
|
|
|
|
|
@node datadir, Install Details, prefix, Install Locations
|
|
@subsection Installing for multiple hosts
|
|
|
|
@cindex Configuring for multiple hosts
|
|
@cindex Sharing host independent files
|
|
@cindex The datadir directory
|
|
@cindex Installing host independent files
|
|
|
|
Host independent files are installed in subdirectories of
|
|
@file{/usr/local/lib}. The actual location is determined by the value
|
|
of the @code{configure} variable @code{datadir} which determines
|
|
the value of the Makefile variable @code{datadir}. By default, the
|
|
value of @code{datadir} is @file{@var{prefix}/lib}. This makes
|
|
single host installs simple, and simplifies changing the default
|
|
location for the install tree, but doesn't allow for multiple hosts to
|
|
effectively share host independent files.
|
|
|
|
To configure so that multiple hosts can share common files, use
|
|
something like:
|
|
|
|
@example
|
|
configure @var{host1} -prefix=/usr/gnu/H-@var{host1} -datadir=/usr/gnu/H-independent
|
|
make all info install install-info clean
|
|
configure @var{host2} -prefix=/usr/gnu/H-@var{host2} -datadir=/usr/gnu/H-independent
|
|
make all info install install-info
|
|
@end example
|
|
|
|
The first line configures the source for @var{host1} in such a way that
|
|
host specific programs will be placed in subdirectories of
|
|
@file{/usr/gnu/H-@var{host1}} and host independent files will be placed
|
|
in @file{/usr/gnu/H-independent}. (See @xref{datadir}.)
|
|
|
|
The second line builds and installs all programs for @var{host1},
|
|
including both host independent and host dependent files.
|
|
|
|
The third line reconfigures the source for @var{host2} in such a way
|
|
that host specific programs will be placed in subdirectories of
|
|
@file{/usr/gnu/H-@var{host2}} and host independent files will again be
|
|
placed in @file{/usr/gnu/H-independent}.
|
|
|
|
The fourth line builds and installs all programs for @var{host2}. Host
|
|
dependent files will be installed in new directories but the host
|
|
independent files will be installed @emph{on top of} the host
|
|
independent files installed for @var{host1}. This results in a single
|
|
copy of the host independent files suitable for use by both hosts.
|
|
|
|
NOTE: support for @code{-subdirs} and multiple hosts is at least
|
|
temporarily suspended. FIXME-soon
|
|
|
|
Previously this was:
|
|
|
|
@example
|
|
configure @var{host1} @var{host2} -prefix=/usr/gnu
|
|
@end example
|
|
|
|
@node Install Details, , datadir, Install Locations
|
|
@subsection Full descriptions of all installation subdirectories
|
|
|
|
In any install, a number of standard directories are created. Their
|
|
actual names are determined by Makefile variables. Some of the
|
|
defaults for Makefile variables can be changed at configure time using
|
|
command line options to @code{configure}. For more information on the
|
|
standard directories or the Makefile variables, please refer to
|
|
@cite{standards.text}.
|
|
|
|
Note that @code{configure} does not create @code{srcdir} at any time.
|
|
The directory @code{srcdir} is not an installation directory.
|
|
|
|
All makefile variables can be overridden on the command line to
|
|
@code{make}. (See @xref{Overriding, Overriding Variables, Overriding
|
|
Variables, make, Make}.) If you do so, you will need to specify the
|
|
value precisely the same way for each invocation of @code{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
|
|
@xref{Sites}.
|
|
|
|
During @code{make install}, the following standard directories will be
|
|
created and populated:
|
|
|
|
@vindex prefix
|
|
@defvr {Makefile and configure} prefix
|
|
By default, the value of this variable determines the root of the
|
|
installation tree. It may be overridden with the @code{-srcdir=}
|
|
command line option to @code{configure}. (@xref{Invoking}.) The
|
|
default value for @code{prefix} is @file{/usr/local}.
|
|
@end defvr
|
|
|
|
@vindex bindir
|
|
@defvr Makefile bindir
|
|
The value of this variable names a directory intended to contain binary
|
|
programs that users can run. The default value for @code{bindir}
|
|
depends on @code{prefix} so @code{bindir} is normally changed
|
|
only indirectly through @code{prefix}. The default value for
|
|
@code{bindir} is @file{@var{prefix}/bin}.
|
|
@end defvr
|
|
|
|
@vindex datadir
|
|
@defvr {Makefile and configure} datadir
|
|
The value of this variable names a directory intended to contain host
|
|
independent files. The @code{configure} variable, which is used to set
|
|
the default value of the Makefile variable, can be set at configure time
|
|
using the @code{-datadir=} option to @code{configure}. (See also
|
|
@xref{Invoking}.) The default value for @code{datadir} is
|
|
@file{@var{prefix}/lib}.
|
|
@end defvr
|
|
|
|
@vindex libdir
|
|
@defvr Makefile libdir
|
|
The value of this variable names a directory intended to hold libraries
|
|
and support programs. The default value for @code{libdir}
|
|
depends on @code{prefix} so @code{libdir} is normally changed
|
|
only indirectly through @code{prefix}. The default value for
|
|
@code{libdir} is @file{@var{prefix}/lib}.
|
|
@end defvr
|
|
|
|
@vindex mandir
|
|
@defvr Makefile mandir
|
|
The value of this variable names a directory intended to hold @emph{man}
|
|
format man pages. The default value for @code{mandir}
|
|
depends on @code{prefix} so @code{mandir} is normally changed
|
|
only indirectly through @code{prefix}. The default value for
|
|
@code{mandir} is @file{@var{datadir}/man}.
|
|
@end defvr
|
|
|
|
@vindex man@var{N}dir
|
|
@defvr Makefile man@var{N}dir
|
|
There are eight of these variables named @code{man1dir}, @code{man2dir},
|
|
etc. They are intended to name the specific directories which hold the
|
|
man pages of their respective sections. That is, @code{man1dir} holds
|
|
@file{emacs.1}, the man page for the emacs program while @code{man5dir}
|
|
holds the man page describing the @code{rcs} data file format, called
|
|
@file{rcsfile.5}. The default value for @code{man@var{N}dir}
|
|
depends on @code{prefix} so @code{man@var{N}dir} is normally changed
|
|
only indirectly through @code{prefix}. The default value for
|
|
@code{man@var{N}dir} is @file{@var{mandir}/man@var{N}}.
|
|
@end defvr
|
|
|
|
@vindex manext
|
|
@defvr Makefile manext
|
|
The makefile variable manext is not supported by the @code{configure}.
|
|
The @sc{gnu} coding standards do not call for @code{man1ext},
|
|
@code{man2ext}, so the intended use for @code{manext} is not clear.
|
|
(See also @xref{Makefile Extensions}.)
|
|
@end defvr
|
|
|
|
@vindex infodir
|
|
@defvr Makefile infodir
|
|
The value of this variable names a directory intended to hold
|
|
@emph{info} format documentation. The default value for @code{infodir}
|
|
depends on @code{prefix} so @code{infodir} is normally changed
|
|
only indirectly through @code{prefix}. The default value for
|
|
@code{infodir} is @file{@var{datadir}/info}.
|
|
@end defvr
|
|
|
|
@vindex docdir
|
|
@defvr Makefile docdir
|
|
The value of this variable names a directory intended to hold any
|
|
documentation that is in a format other than @emph{info} or @emph{man}.
|
|
The default value for @code{docdir} depends on @code{prefix} so
|
|
@code{docdir} is normally changed only indirectly through @code{prefix}.
|
|
The default value for @code{docdir} is @file{@var{datadir}/doc}. Note
|
|
that this variable is an extension to the @sc{gnu} coding standards.
|
|
(See also @xref{Makefile Extensions}.)
|
|
@end defvr
|
|
|
|
@vindex includedir
|
|
@defvr Makefile includedir
|
|
The value of this variable names a directory intended to hold the
|
|
headers files that accompany the libraries installed in @code{libdir}.
|
|
The default value for @code{includedir} depends on @code{prefix} so
|
|
@code{includedir} is normally changed only indirectly through @code{prefix}. The default value for
|
|
@code{includedir} is @file{@var{prefix}/include}.
|
|
@end defvr
|
|
|
|
|
|
@node Build Directories, Host, Install Locations, Using Configure
|
|
@section Build Directories
|
|
|
|
@cindex Build directories
|
|
@cindex objdir
|
|
@cindex Object directories
|
|
@cindex subdirs
|
|
@cindex Building for multiple hosts
|
|
@cindex Building for multiple targets
|
|
|
|
Normally, @code{configure} builds a @file{Makefile} and symbolic links
|
|
in the same directory as the source files. This is the typical
|
|
@sc{un*x} way to build programs but it has limitations. For instance,
|
|
using this approach, you can only build for one host at a time.
|
|
|
|
We refer to the directories in which @code{configure} builds a
|
|
@file{Makefile} as the @emph{build directories} or sometimes as
|
|
@emph{objdir} because these are the directories in which @code{make}
|
|
will build object files, among other things.
|
|
|
|
The default build directory is the same as the source directory.
|
|
|
|
You can change the build directory with a sequence like the following:
|
|
|
|
@example
|
|
mkdir @var{builddir}
|
|
cd @var{builddir}
|
|
configure @var{host} -srcdir=@var{sourcedirectory}
|
|
@end example
|
|
|
|
where @var{builddir} is the directory in which you wish to build,
|
|
@var{host} is the host for which you want to build, and
|
|
@var{sourcedirectory} is the directory containing the source files.
|
|
|
|
If you were to do this twice with different values for @var{builddir}
|
|
and @var{host}, then you could @code{make} for both at the same time.
|
|
|
|
NOTE: The rest of this section describes the @code{-subdirs} feature for
|
|
which support is at least temporarily suspended. FIXME-soon.
|
|
|
|
Another way to specify the build directory is with the @code{-subdirs}
|
|
option. For example:
|
|
|
|
@example
|
|
configure @var{host} -subdirs
|
|
@end example
|
|
|
|
Using this option, @code{configure} will create a subdirectory named
|
|
@file{H-@var{host}} to act as the build directory for each source
|
|
directory.
|
|
|
|
Since building for multiple hosts is so common, @code{configure}
|
|
recognizes this situation as special. For example:
|
|
|
|
@example
|
|
configure @var{host1} @var{host2}
|
|
@end example
|
|
|
|
is precisely the same as:
|
|
|
|
@example
|
|
configure @var{host1} -subdirs
|
|
configure @var{host2} -subdirs
|
|
@end example
|
|
|
|
That is, when configuring for multiple hosts or multiple targets,
|
|
@code{-subdir} is assumed.
|
|
|
|
When configuring for cross tools, that is, the host is not the target,
|
|
as in:
|
|
|
|
@example
|
|
configure @var{host} +target=@var{targ} -subdirs
|
|
@end example
|
|
|
|
the subdirectories are named @file{X-@var{host}-@var{targ}}. This is
|
|
especially useful when configuring for multiple targets.
|
|
|
|
If both @code{-subdirs} and @code{-srcdir=} are given, a tree that
|
|
parallels the source directory structure is created in the current
|
|
directory, except that the current directory represents the source
|
|
directory itself, and the subdirectories are created in this directory
|
|
tree rather than in the source directories.
|
|
|
|
NOTE: previously, -subdirs built two level subdirectories as
|
|
./H-host/T-target, created ./H-host/Makefile for building across all
|
|
targets, ./Makefile for building across all hosts, and ./config.status
|
|
and ./H-host/config.status for rebuilding these Makefiles.
|
|
|
|
@node Host, Target, Build Directories, Using Configure
|
|
@section Host
|
|
|
|
NOTE: support for multiple hosts is at least temporarily suspended.
|
|
FIXME-soon.
|
|
|
|
The arguments to @code{configure} are @emph{hosts}. By @emph{host} we
|
|
mean the environment in which the source will be compiled. This need
|
|
not necessarily be the same as the actual physical machine involved,
|
|
although it usually is.
|
|
|
|
For example, if some obscure machine running an operating system other
|
|
than @sc{un*x} actually had the @sc{gnu} @sc{posix} emulation libraries
|
|
available, it would be possible to configure most @sc{gnu} source for a
|
|
@sc{posix} system and build it on the obscure host.
|
|
|
|
For more on this topic, see @xref{Host Environments, , cfg-paper, On
|
|
Configuring Development Tools}.
|
|
|
|
@node Target, Local Conventions, Host, Using Configure
|
|
@section Target
|
|
|
|
For building native development tools, or most of the other tools in the
|
|
@sc{gnu} collection, you need not worry about the target. The
|
|
@emph{target} of a configuration defaults to the same as the
|
|
@emph{host}.
|
|
|
|
For building cross development tools, please see @xref{Building
|
|
Development Environments, , cfg-paper, On Configuring Development
|
|
Tools}.
|
|
|
|
@node Local Conventions, , Target, Using Configure
|
|
@section Local Conventions
|
|
|
|
If you find that a tool does not get configured to your liking or that
|
|
@code{configure}'s conventions are not your local conventions, you
|
|
should probably consider site specific Makefile fragments. See also
|
|
@xref{Sites}.
|
|
|
|
|
|
These are probably not the right choice for options that can be set from
|
|
the @code{configure} command line or for differences that are host or
|
|
target dependent.
|
|
|
|
|
|
@node What Configure Does, Porting, Using Configure, top
|
|
@chapter What Configure Does
|
|
|
|
When configure runs, it does the following things for each source
|
|
directory for each host and target combination.
|
|
|
|
NOTE: support for multiple hosts and targets is at least temporarily
|
|
suspended.
|
|
|
|
@itemize @bullet
|
|
|
|
@item Create Build Directories
|
|
(see @xref{Build Directories}) When @code{configure} is run with the
|
|
@code{-srcdir=} option, a directory tree is created that parallels the
|
|
directory structure of the source directory except that the current
|
|
directory is treated as the build directory for the source directory
|
|
proper. (see @xref{Invoking}).
|
|
|
|
NOTE: support for @code{-subdirs} is at least temporarily suspended.
|
|
|
|
When @code{configure} is run with the @code{-subdirs} option, a build
|
|
directory is created in each source directory.
|
|
|
|
If both @code{-subdirs} and @code{-srcdir=} are given, a tree that
|
|
parallels the source directory structure is created in the current
|
|
directory, except that the current directory represents the source
|
|
directory itself, and the subdirectories are created in this directory
|
|
tree rather than in the source directories.
|
|
|
|
@item Generate Makefiles
|
|
A makefile template, usually called @file{Makefile.in} from the source
|
|
directory is copied to an output file in the build directory. The
|
|
output file is usually named @file{Makefile}. A number of makefile
|
|
macros are prepended to the output file. If @code{-prefix=} or
|
|
@code{-datadir=} were specified on the @code{configure} command line,
|
|
then the makefile variables are set accordingly. If host, target, or
|
|
site, specific makefile fragments exist, they are inserted into the
|
|
output file. (see @xref{Makefiles, , , make, Makefiles}.)
|
|
|
|
@item Generate .gdbinit
|
|
If the source directory contains a .gdbinit file and the build directory
|
|
is different from the source directory, a .gdbinit file is created in
|
|
the build directory. (see @xref{Command Files, , , gdb, Command Files}.)
|
|
|
|
@item Make Symbolic Links
|
|
Most directories have some symbolic links with generic names built
|
|
pointing to specific files in the source directory. If the system on
|
|
which @code{configure} is run cannot support symbolic links, then hard
|
|
links are used instead.
|
|
|
|
@item Miscellaneous
|
|
If the source directory has special needs, they are handled. Usually
|
|
there are none, but sometimes they involve changes to the output
|
|
makefile.
|
|
|
|
@item Generate config.status
|
|
A shell script named @file{config.status} is created in the build
|
|
directory. This shell script, when run from the build directory, will
|
|
reconfigure the build directory except that subdirectories are not
|
|
reconfigured. This is most often used by @code{make} to rebuild the
|
|
output makefile. (see @xref{Top, , , bash}.)
|
|
|
|
@item Recursion
|
|
If the source directory has subdirectories that should also be
|
|
configured, then @code{configure} is called for each.
|
|
|
|
@end itemize
|
|
|
|
@node Porting, Reference, What Configure Does, top
|
|
@chapter Porting with Configure
|
|
|
|
@cindex Porting
|
|
This section explains briefly how to add programs, host and target
|
|
configuration names, and sites to Cygnus configure.
|
|
|
|
@menu
|
|
* Programs:: Adding configure to new programs
|
|
* Hosts and Targets:: Adding hosts and targets
|
|
* Sites:: Adding site info
|
|
@end menu
|
|
|
|
|
|
@node Programs, Hosts and Targets, Porting, Porting
|
|
@section Adding Configure To New Programs
|
|
|
|
If you are writing a new program, you probably shouldn't worry about
|
|
porting issues or configure until it is running reasonably on some host.
|
|
Then refer back to this section.
|
|
|
|
If the program in question currently has a configure script that meets
|
|
the criterion set out by @cite{standards.text}, please do not add Cygnus
|
|
configure. It should be possible to add this program without change to
|
|
a Cygnus configure style source tree.
|
|
|
|
If the program is not target dependent, please consider using
|
|
@code{autoconf} instead of Cygnus configure. Autoconf will soon be
|
|
available from the @sc{fsf}.
|
|
|
|
To add Cygnus configure to an existing program, do the following.
|
|
|
|
@table @asis
|
|
|
|
@item Bring the Makefile up to the standard
|
|
The coding standard for @sc{gnu} Makefiles is described in
|
|
@cite{standards.text}.
|
|
|
|
@item Add Cygnus extensions to the Makefile
|
|
There are described in @xref{Makefile Extensions}.
|
|
|
|
@item Move host support from Makefile to fragments
|
|
This usually involves finding sections of the Makefile that say things
|
|
like ``uncomment these lines for host foo'' and moving them to a new
|
|
file call @file{./config/mh-foo}. For more on this, see @xref{Hosts and
|
|
Targets}.
|
|
|
|
@item Choose defaults
|
|
If the program has compile time options that determine the way the
|
|
program should behave, chose reasonable defaults and make these Makefile
|
|
variables. Be sure the variables are assigned their default values
|
|
before the @code{####} line so that they can be overridden with site
|
|
specific Makefile fragments.
|
|
|
|
@item Locate configuration files
|
|
If there is configuration information in header files or source files,
|
|
separate it in such a way that the files have a generic name. Then move
|
|
the specific instances of those files into the @file{./config}
|
|
directory.
|
|
|
|
@item Separate host and target information
|
|
Some programs already have this information separated. If not, you will
|
|
need to do so. Host specific information is the information needed to
|
|
compile the program. Target specific information it information on the
|
|
format of data files that the program will read or write. This
|
|
information should live in separate files in the @file{./config}
|
|
directory with names that reflect the configuration for which they are
|
|
intended.
|
|
|
|
At this point you might skip this step and simply move on. If you do,
|
|
you should end up with a program that can be configured only to build
|
|
native tools, that is, tools for which the host system is also the
|
|
target system. Later, you could attempt to build a cross tool and
|
|
separate out the target specific information by figuring out what went
|
|
wrong. This is often simpler than combing through all of the source
|
|
code.
|
|
|
|
@item Write configure.in
|
|
Usually this involves writing shell script fragments to map from
|
|
canonical configuration names into the names of the configuration files.
|
|
These files will then be linked at configure time from the specific
|
|
instances of those files in @file{./config} to file in the build
|
|
directory with more generic names. (see also @xref{Build Directories}).
|
|
The format of configure.in is described in @xref{configure.in}.
|
|
|
|
@item Rename the Makefile to Makefile.in
|
|
|
|
@end table
|
|
|
|
At this point you should have a program that can be configured by Cygnus
|
|
configure.
|
|
|
|
@node Hosts and Targets, Sites, Programs, Porting
|
|
@section Adding hosts and targets
|
|
|
|
To add a host or target to a program that currently uses Cygnus
|
|
configure, do the following.
|
|
|
|
@itemize @bullet
|
|
|
|
@item
|
|
Make sure the new configuration name is represented in
|
|
@file{config.sub}. If not, add it. For more details, see the comments
|
|
in the shell script @file{config.sub}.
|
|
|
|
@item
|
|
If you are adding a host configuration, look in @file{configure.in}, in
|
|
the per-host section. Make sure that your configuration name is
|
|
represented in the mapping from host configuration names to
|
|
configuration files. If not, add it. Also see @xref{configure.in}.
|
|
|
|
@item
|
|
If you are adding a target configuration, look in @file{configure.in},
|
|
in the per-target section. Make sure that your configuration name is
|
|
represented in the mapping from target configuration names to
|
|
configuration files. If not, add it. Also see @xref{configure.in}.
|
|
|
|
@item
|
|
Look in @file{configure.in} for the assignments to the variables
|
|
@code{files}, @code{links}, @code{host_makefile_frag}, and
|
|
@code{target_makefile_frag}. These are the names of the configuration
|
|
files that the program uses. Make sure that copies of the files exist
|
|
for your host. If not, create them. See also @xref{Configure
|
|
Variables}.
|
|
|
|
@end itemize
|
|
|
|
This should be enough to configure for a new host or target
|
|
configuration name. Getting the program to compile and run properly now
|
|
is the hard work of the port.
|
|
|
|
|
|
@node Sites, , Hosts and Targets, Porting
|
|
@section Adding site info
|
|
|
|
If some of the Makefile defaults are not right for your site, you can
|
|
build site specific Makefile fragments. To do this, do the following.
|
|
|
|
@itemize @bullet
|
|
|
|
@item
|
|
Choose a name for your site. It must be less than eleven characters for
|
|
now.
|
|
|
|
@item
|
|
If the program does not have a @file{./config} directory, create it.
|
|
|
|
@item
|
|
Create a file called @file{./config/ms-@var{site}} where @var{site} is
|
|
the name of your site. In it, set the Makefile variables of your
|
|
choice.
|
|
|
|
@item
|
|
Configure the program with:
|
|
|
|
@example
|
|
configure @dots{} +site=@var{site}
|
|
@end example
|
|
|
|
@end itemize
|
|
@node Reference, Known Bugs, Porting, top
|
|
@chapter Gory details described
|
|
|
|
@cindex Backends
|
|
Here we describe the backend support.
|
|
|
|
@menu
|
|
* Makefile Extensions:: Extensions to the @sc{gnu} coding standards
|
|
* configure.in:: The format of the configure.in file
|
|
* config.status:: config.status
|
|
* Makefile Fragments:: Makefile Fragments
|
|
@end menu
|
|
|
|
@node Makefile Extensions, configure.in, Reference, Reference
|
|
@section Extensions to the @sc{gnu} coding standards
|
|
|
|
@cindex Makefile extensions
|
|
@cindex Cygnus extensions
|
|
|
|
The following additions to the @sc{gnu} coding standards are required
|
|
for Cygnus configure to work properly.
|
|
|
|
@itemize @bullet
|
|
|
|
@item
|
|
The Makefile must contain exactly one line starting with @code{####}.
|
|
This line should follow any default macro definitions but precede any
|
|
rules. Host, target, and site specific Makefile fragments will be
|
|
inserted immediately after this line. If the line is missing, the
|
|
fragments will not be inserted.
|
|
|
|
@end itemize
|
|
|
|
Cygnus adds the following targets to our Makefiles. Their existence is
|
|
not required for Cygnus configure but are documented here for
|
|
completeness.
|
|
|
|
@table @code
|
|
|
|
@cindex info
|
|
@item info
|
|
Build all info files from texinfo source.
|
|
|
|
@cindex install-info
|
|
@item install-info
|
|
Install all info files.
|
|
|
|
@cindex clean-info
|
|
@item clean-info
|
|
Remove all info files and any intermediate files that can be generated
|
|
from texinfo source.
|
|
|
|
@cindex stage1
|
|
@item stage1
|
|
@cindex stage2
|
|
@item stage2
|
|
@cindex stage3
|
|
@item stage3
|
|
@cindex stage4
|
|
@item stage4
|
|
@cindex de-stage1
|
|
@item de-stage1
|
|
@cindex de-stage2
|
|
@item de-stage2
|
|
@cindex de-stage3
|
|
@item de-stage3
|
|
@cindex de-stage4
|
|
@item de-stage4
|
|
@cindex bootstrap
|
|
@item bootstrap
|
|
@cindex comparison
|
|
@item comparison
|
|
@cindex Makefile
|
|
@item Makefile
|
|
These targets are in transition and may be removed shortly.
|
|
|
|
@end table
|
|
|
|
In addition, the following Makefile targets have revised semantics:
|
|
|
|
@table @code
|
|
|
|
@cindex install
|
|
@item install
|
|
Should @emph{not} depend on the target @code{all}. If the program is
|
|
not already built, @code{make install} should fail. This allows
|
|
programs to be installed even when @code{make} would otherwise determine
|
|
them to be out of date. This can happen when the result of a @code{make
|
|
all} is transported via tape to another machine for installation as
|
|
well as in a number of other cases.
|
|
|
|
@cindex clean
|
|
@item clean
|
|
Should remove any file that can be regenerated by the Makefile,
|
|
excepting only the Makefile itself, and any links created by configure.
|
|
That is, @code{make all clean} should return all directories to their
|
|
original condition. If this is not done, then:
|
|
|
|
@example
|
|
configure @var{host1} ; make all clean ; configure @var{host2} ; make all
|
|
@end example
|
|
|
|
@noindent
|
|
will fail because of intermediate files intended for @var{host1}.
|
|
|
|
@end table
|
|
|
|
Cygnus adds the following macros to all Makefile.in's. Their presence
|
|
is not required for Cygnus configure.
|
|
|
|
@table @code
|
|
|
|
@cindex docdir
|
|
@item docdir
|
|
The directory in which to install any documentation that is not either a
|
|
man page or an info file. For man pages, see mandir, for info, see
|
|
infodir.
|
|
|
|
@cindex includedir
|
|
@item includedir
|
|
The directory in which to install any headers files that should be made
|
|
available to users. This is distinct from the @code{gcc} include
|
|
directory which is intended for @code{gcc} only. Files in
|
|
@code{includedir} may be used by @code{cc} as well.
|
|
|
|
@end table
|
|
|
|
In addition, the following macros have revised semantics.
|
|
|
|
@table @code
|
|
|
|
@cindex manext
|
|
@item manext
|
|
is not used. The intended usage is not clear. For example, if I have a
|
|
@file{foo.man} and a @file{bar.man}, and @file{foo.man} is destined for
|
|
@file{/usr/local/lib/man/man1/foo.1} while @file{bar.man} is destined
|
|
for @file{/usr/local/lib/man/man5/bar.5}, then to what should the value
|
|
of @code{manext} be set? See also @xref{Install Details}.
|
|
|
|
@cindex datadir
|
|
@item datadir
|
|
is used for @emph{all} host independent files. This makes it possible
|
|
to share host independent files across multiple hosts without ersorting
|
|
to symlinks or multiple mount points. This also makes it possible
|
|
build an install tree that contains multiple host binaries, write
|
|
the binaries to tape, and extract any of the hosts without extracting
|
|
the others.
|
|
|
|
@cindex mandir
|
|
@item mandir
|
|
man pages are host independent so the default path for @code{mandir}
|
|
depends on @code{datadir}.
|
|
|
|
@cindex infodir
|
|
@item infodir
|
|
info files are host independent so the default path for @code{infodir}
|
|
depends on @code{datadir}.
|
|
|
|
@cindex BISON
|
|
@item BISON
|
|
is assumed to have a yacc calling convention. To actually use
|
|
@code{bison}, use @code{BISON=bison -y}.
|
|
|
|
@end table
|
|
|
|
Cygnus also adds the following restrictions on our Makefiles.
|
|
|
|
@itemize @bullet
|
|
|
|
@item
|
|
When libraries are installed, the line containing the call to
|
|
@code{INSTALL_DATA} should always be followed by a line containing a
|
|
call to @code{RANLIB} on the installed library. This is to accomodate
|
|
systems that use @code{ranlib}. Systems that do not use ranlib can set
|
|
@code{RANLIB} to @code{echo} in a host specific Makefile fragment.
|
|
|
|
@end itemize
|
|
|
|
@node configure.in, config.status, Makefile Extensions, Reference
|
|
@section The format of the configure.in file
|
|
|
|
@cindex configure.in
|
|
|
|
A configure.in file for Cygnus configure consists of a declarations
|
|
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 sourced by configure at the appropriate time.
|
|
The interface between configure and the shell fragments is through a set
|
|
of shell variables. All sections are sourced in the build directory.
|
|
|
|
@cindex Per-host section
|
|
A line beginning with @code{# Per-host:} begins the per-host section.
|
|
|
|
@cindex Per-target section
|
|
A line beginning with @code{# Per-target:} begins the per-target
|
|
section.
|
|
|
|
@cindex Post-target section
|
|
If it exists, the post-target section begins with @code{# Per-target:}.
|
|
|
|
@menu
|
|
* Minimal:: A minimal configure.in
|
|
* Configure Variables:: Variables available to configure.in
|
|
* Declarations:: Per invocation
|
|
* Per-host:: On a host basis
|
|
* Per-target:: On a target basis
|
|
* Post-target:: After each target
|
|
* Example:: An example configure.in
|
|
@end menu
|
|
|
|
@node Minimal, Configure Variables, configure.in, configure.in
|
|
@subsection A minimal configure.in
|
|
|
|
@cindex Minimal configure.in example
|
|
A minimal @file{configure.in} consists of four lines.
|
|
|
|
@example
|
|
srctrigger=foo.c
|
|
srcname="source for the foo program"
|
|
# Per-host:
|
|
# Per-target:
|
|
@end example
|
|
|
|
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.
|
|
|
|
@node Configure Variables, Declarations, Minimal, configure.in
|
|
@subsection Variables available to configure.in
|
|
|
|
@cindex Configure.in interface
|
|
|
|
The following variables are available to the shell fragments in
|
|
@file{configure.in}.
|
|
|
|
@defvar{srctrigger}
|
|
Contains the name of a source file that is expected to live in the
|
|
source directory. This is usually set in the declations section of
|
|
@file{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.
|
|
@end defvar
|
|
|
|
@defvar{srcname}
|
|
Contains the name of the source contained in the source directory. This
|
|
is usually set in the declarations section of @file{configure.in}. If
|
|
the file named in @code{srctrigger} does not exist, configure uses the
|
|
value of this variable when it prints the error message.
|
|
@end defvar
|
|
|
|
@defvar{configdirs}
|
|
Contains the names of any subdirectories on which configure should
|
|
recur. This is usually set in the declarations section of
|
|
@file{configure.in}. If @file{Makefile.in} contains a line starting
|
|
with @code{SUBDIRS =}, then it will be replaced with an assignment to
|
|
@code{SUBDIRS} using the value of @code{configdirs}. This can be used
|
|
to determine which directories to configure and build depending on the
|
|
host and target configurations.
|
|
@end defvar
|
|
|
|
NOTE: support for multiple targets is currently suspended.
|
|
|
|
@defvar{target_dependent}
|
|
If this variable is not empty and @code{-subdirs} is in effect then
|
|
configure will create separate build directories for each target. This
|
|
is usually set in the declarations section of @file{configure.in}. The
|
|
default is to assume that a directory is target independent, create only
|
|
one real directory with symlinks from the other names. This means that
|
|
a target independent directory will be built exactly once regardless of
|
|
how many targets are being built.
|
|
@end defvar
|
|
|
|
@defvar{host}
|
|
Contains the actual name that the user entered for the host. Since many
|
|
things that the user could enter would map to the same canonical triple,
|
|
this variable is innappropriate to use for picking available
|
|
configurations. For that, use @code{host_cpu}, @code{host_vendor},
|
|
and/or @code{host_os}. This variable is useful, however, for error
|
|
messages.
|
|
@end defvar
|
|
|
|
@defvar{host_cpu}
|
|
Contains the first element of the canonical triple representing the host
|
|
as returned by @file{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.
|
|
@end defvar
|
|
|
|
@defvar{host_vendor}
|
|
Contains the second element of the canonical triple representing the
|
|
host as returned by @file{config.sub}. This is usually used to
|
|
distinguish betwen the numerous variations between @emph{common}
|
|
operating systems.
|
|
@end defvar
|
|
|
|
@defvar{host_os}
|
|
Contains the the third element of the canonical triple representing the
|
|
host as returned by @file{config.sub}.
|
|
@end defvar
|
|
|
|
@defvar{target}
|
|
Contains the actual name that the user entered for the target. Since
|
|
many things that the user could enter would map to the same canonical
|
|
triple, this variable is innappropriate to use for picking available
|
|
configurations. For that, use @code{target_cpu}, @code{target_vendor},
|
|
and/or @code{target_os}. This variable is useful, however, for error
|
|
messages.
|
|
@end defvar
|
|
|
|
@defvar{target_cpu}
|
|
Contains the first element of the canonical triple representing the
|
|
target as returned by @file{config.sub}. This is used heavily by
|
|
programs involved in building programs, like the compiler, assembler,
|
|
linker, etc. Most programs will not need the @code{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 are other than that of the system on which the program is
|
|
running.
|
|
@end defvar
|
|
|
|
@defvar{target_vendor}
|
|
Contains the second element of the canonical triple representing the
|
|
target as returned by @file{config.sub}. This is usually used to
|
|
distinguish betwen the numerous variations between @emph{common}
|
|
operating systems or object file formats. Sometimes it is used to
|
|
switch between different flavors of user interfaces.
|
|
@end defvar
|
|
|
|
@defvar{target_os}
|
|
Contains the the third element of the canonical triple representing the
|
|
target as returned by @file{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.
|
|
@end defvar
|
|
|
|
@defvar{nfp}
|
|
Is set to @code{true} if the user invoked configure with the @code{-nfp}
|
|
command line option, otherwise it is empty. This is a request to target
|
|
machines with @emph{no floating point} unit, even if the targets
|
|
ordinarily have floating point units available. This option has no
|
|
negation.
|
|
@end defvar
|
|
|
|
@defvar{gas}
|
|
Is set to @code{true} if the user invoked configure with the @code{-gas}
|
|
command line option, otherwise it is empty. This is a request to assume
|
|
that all target machines have gas available even if they ordinarily do
|
|
not. The converse option, @code{-no-gas} is not available.
|
|
@end defvar
|
|
|
|
@defvar{x}
|
|
Is set to @code{true} if the user invoked configure with the @code{-x}
|
|
command line option, otherwise it is empty. This is a request to assume
|
|
that @sc{mit x11} compatible headers files and libraries are available
|
|
on all hosts, regardless of what is normally available on them.
|
|
@end defvar
|
|
|
|
NOTE: support for @code{-subdirs} is at least temporarily suspended.
|
|
|
|
@defvar{srcdir}
|
|
Is set to the name of the directory containing the source for this
|
|
program. This will be different from @file{.} if the user has specified
|
|
either the @code{-srcdir=} or the @code{-subdirs} options. Note that
|
|
@code{srcdir} is not necessarily an absolute path.
|
|
@end defvar
|
|
|
|
@defvar{host_makefile_frag}
|
|
Is set to a file name representing to the default Makefile fragment for
|
|
this host. It may be set in @file{configure.in} to overide this
|
|
default.
|
|
@end defvar
|
|
|
|
@defvar{target_makefile_frag}
|
|
Is set to a file name representing to the default Makefile fragment for
|
|
this target. It may be set in @file{configure.in} to overide this
|
|
default.
|
|
@end defvar
|
|
|
|
@defvar{site_makefile_frag}
|
|
Is set to a file name representing to the default Makefile fragment for
|
|
this host. It may be set in @file{configure.in} to overide this
|
|
default. Normally @code{site_makefile_frag} is empty, but will have a
|
|
value if the user specified @code{-site=} on the command line. This
|
|
variable should probably not be overridden.
|
|
@end defvar
|
|
|
|
@defvar{Makefile}
|
|
Is set to the name of the generated @file{Makefile}. Normally this
|
|
value is precisely @file{Makefile} but some programs may want something
|
|
else.
|
|
@end defvar
|
|
|
|
@defvar{removing}
|
|
Is normally empty but will be set to some non-empty value if the user
|
|
specified @code{-rm} on the command line. That is, if @code{removing}
|
|
is non-empty, then configure is @emph{removing} a configuration rather
|
|
than creating one.
|
|
@end defvar
|
|
|
|
@defvar{files}
|
|
If this variable is non-empty following the @code{per-target:} section,
|
|
then each word in it's value will be the target of a symbolic link named
|
|
in the @code{links} variable.
|
|
@end defvar
|
|
|
|
@defvar{links}
|
|
If the @code{files} variable is non-empty following the
|
|
@code{per-target:} section, then symbolic links will be created 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.
|
|
@end defvar
|
|
|
|
|
|
@node Declarations, Per-host, Configure Variables, configure.in
|
|
@subsection Per invocation
|
|
|
|
@cindex Declarations section
|
|
|
|
Everything from the start of @file{configure.in} up to a line beginning
|
|
with @code{# Per-host:} is sourced by configure as a shell script
|
|
fragment immediately after parsing command line arguments. The
|
|
variables @code{srctrigger} and @code{srcname} @emph{must} be set here.
|
|
|
|
Some other things you might want to set here are the variables
|
|
@code{configdirs} or @code{target_dependent}. FIXME-soon.
|
|
target_dependent isn't useful without multiple targets.
|
|
|
|
@node Per-host, Per-target, Declarations, configure.in
|
|
@subsection On a host basis
|
|
|
|
@cindex Per-host section
|
|
@cindex Host basis
|
|
The per-host section of @file{configure.in} starts with a line beginning
|
|
with @code{# Per-host:} and ends before a line beginning with with
|
|
@code{# Per-target:}. Configure sources the per-host section once for
|
|
each host.
|
|
|
|
This section usually contains a big case statement using the variables
|
|
@code{host_cpu}, @code{host_vendor}, and @code{host_os} to determine
|
|
appropriate values for @code{host_makefile_frag} and @code{files},
|
|
although @code{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.
|
|
|
|
@node Per-target, Post-target, Per-host, configure.in
|
|
@subsection On a target basis
|
|
|
|
@cindex Per-target section
|
|
@cindex Target basis
|
|
|
|
The per-target section of @file{configure.in} starts with a line
|
|
beginning with @code{# Per-target:} and ends before a line beginning
|
|
with @code{# Post-target:} if it exists. Otherwise the per-target
|
|
section extends to the end of the file. Configure sources the
|
|
per-target section once for each target before building any files,
|
|
directories, or links.
|
|
|
|
This section usually contains a big case statement using the variables
|
|
@code{target_cpu}, @code{target_vendor}, and @code{target_os} to determine
|
|
appropriate values for @code{target_makefile_frag} and @code{files}.
|
|
The last lines in the per-target section normally set the variables
|
|
@code{files} and @code{links}.
|
|
|
|
@node Post-target, Example, Per-target, configure.in
|
|
@subsection After each target
|
|
|
|
The post-target section is optional. If it exists, the post-target
|
|
section starts with a line beginning with @code{# Post-target:} and
|
|
extends to the end of the file. If it exists, configure sources this
|
|
section once for each target after building all files, directories, or
|
|
links.
|
|
|
|
This section seldom exists but can be used to munge the configure
|
|
generated Makefile.
|
|
|
|
@node Example, , Post-target, configure.in
|
|
@subsection An example configure.in
|
|
|
|
@cindex Example configure.in
|
|
@cindex Bison configure.in
|
|
Here is a small example configure.in.
|
|
|
|
@example
|
|
# This file is a shell script fragment that supplies the information
|
|
# necessary to tailor a template configure script into the configure
|
|
# script appropriate for this directory. For more information, check
|
|
# any existing configure script.
|
|
|
|
configdirs=
|
|
srctrigger=warshall.c
|
|
srcname="bison"
|
|
|
|
# per-host:
|
|
case "$@{host_os@}" in
|
|
m88kbcs)
|
|
host_makefile_frag=config/mh-delta88
|
|
;;
|
|
esac
|
|
|
|
# per-target:
|
|
|
|
files="bison_in.hairy"
|
|
links="bison.hairy"
|
|
|
|
# post-target:
|
|
@end example
|
|
|
|
@node config.status, Makefile Fragments, configure.in, Reference
|
|
@section config.status
|
|
|
|
@cindex config.status
|
|
|
|
The final step in configuring a directory is to create an executable
|
|
shell script call @file{config.status}. This file is typically used to
|
|
rebuild the Makefile for the current directory. For this reason,
|
|
@file{config.status} uses the @code{-norecursion} option to configure
|
|
and is therefor probably inappropriate for actually reconfiguring a tree
|
|
of source code.
|
|
|
|
@node Makefile Fragments, , config.status, Reference
|
|
@section Makefile Fragments
|
|
|
|
@cindex Makefile fragments
|
|
|
|
Cygnus configure uses three types of Makefile fragments. In a
|
|
generated Makefile they occur in the order target fragment, host
|
|
fragment, and site fragment. This is so host fragments can override
|
|
target fragments etc.
|
|
|
|
Host specific Makefile fragments conventionally reside in the
|
|
@file{./config} directory with names of the form
|
|
@file{mh-@var{host}}. They are used for hosts that require
|
|
odd options to the standard compiler and for compile time options based
|
|
on the host configuration.
|
|
|
|
Target specific Makefile fragments conventionally reside in the
|
|
@file{./config} directory with names of the form @file{mt-@var{target}}.
|
|
They are used for target dependent compile time options.
|
|
|
|
Site specific Makefile fragments conventionally reside in the
|
|
@file{./config} directory with names of the form @file{ms-@var{site}}.
|
|
They are used to override host and target independent compile time
|
|
options. Note that these options can also be overridden on the
|
|
@code{make} invocation line.
|
|
|
|
@node Known Bugs, Variables Index, Reference, top
|
|
@chapter Known Bugs
|
|
|
|
@cindex bugs
|
|
|
|
The following bugs are known to exist.
|
|
|
|
@itemize @bullet
|
|
|
|
@item
|
|
There is no way to query about known hosts, known targets, or the
|
|
porting or testing status of any configuration.
|
|
|
|
@item
|
|
The negations to the options @code{-gas}, @code{-x}, and @code{-nfp} are
|
|
not available.
|
|
|
|
@end itemize
|
|
|
|
@page
|
|
@node Variables Index, Concept Index, Known Bugs, top
|
|
@appendix Variable Index
|
|
|
|
@printindex vr
|
|
|
|
@page
|
|
@node Concept Index, , Variables Index, top
|
|
@appendix Concept Index
|
|
|
|
@printindex cp
|
|
@contents
|
|
@bye
|
|
|
|
@c Local Variables:
|
|
@c fill-column: 79
|
|
@c outline-regexp: "@chap"
|
|
@c End:
|
|
@c (setq outline-regexp "@chapt\\\|@unnum\\\|@setf\\\|@conte\\\|@sectio\\\|@subsect\\\|@itemize\\\|@defvar{")
|