1430 lines
52 KiB
Plaintext
1430 lines
52 KiB
Plaintext
\input texinfo @c -*-para-*-
|
|
@c %**start of header
|
|
@setfilename configure.info
|
|
@settitle Cygnus Configure
|
|
@c %**end of header
|
|
@synindex ky cp
|
|
@tex
|
|
\def\$#1${{#1}} % Kluge: collect RCS revision info without $...$
|
|
\xdef\manvers{\$Revision$} % For use in headers, footers too
|
|
@end tex
|
|
@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 @manvers, 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, What Configure Does, (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
|
|
* What Configure Does:: What Configure Does
|
|
* Invoking:: Invoking
|
|
* Using Configure:: Using Configure
|
|
* 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 What Configure Does, Invoking, top, top
|
|
@chapter What Configure Does
|
|
|
|
@code{configure} prepares source directories for building working
|
|
programs. A program cannot be built until its source has been
|
|
configured. 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.
|
|
|
|
@table @emph
|
|
@item Create build directories
|
|
(see @ref{Build Directories}). When you run @code{configure} with the
|
|
@code{-srcdir=} option, it uses the current directory as build
|
|
directory, creating under it a directory tree that parallels the
|
|
directory structure under the source directory. (See @ref{Invoking}).
|
|
|
|
NOTE: support for @code{-subdirs} is at least temporarily suspended.
|
|
@*
|
|
When you run @code{configure} with the @code{-subdirs} option, it
|
|
creates a build subdirectory in each source directory.
|
|
|
|
If you use both @code{-subdirs} and @code{-srcdir=}, a tree that
|
|
parallels the source directory structure is created in the current
|
|
directory, and the subdirectories are created in this directory tree
|
|
rather than in the source directories.
|
|
|
|
@item Generate makefiles
|
|
A makefile template from the source directory, usually called
|
|
@file{Makefile.in}, is copied to an output file in the build directory.
|
|
The output file is usually named @file{Makefile}. @code{configure}
|
|
places definitions for a number of standard makefile
|
|
macros at the beginning of the output file. If @code{-prefix=} or
|
|
@code{-datadir=} were specified on the @code{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. (See @ref{Makefiles, , , make, Makefiles}.)
|
|
|
|
@item Generate @file{.gdbinit}
|
|
If the source directory contains a @file{.gdbinit} file and the build
|
|
directory is not the same as the source directory, a @file{.gdbinit}
|
|
file is created in the build directory. (see @ref{Command Files, , ,
|
|
gdb, Command Files}.)
|
|
@c There doesn't seem to be anything else about this. Is the build-dir
|
|
@c .gdbinit identical with the source-dir one? If so should say "copy"
|
|
@c rather than "create" to make it clear.
|
|
|
|
@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 where
|
|
@code{configure} runs cannot support symbolic links, hard links are used
|
|
instead.
|
|
|
|
@item Miscellaneous
|
|
If the source directory has special needs, they are handled by shell
|
|
script fragments stored with the source. Usually there are no special
|
|
needs, but sometimes they involve changes to the output makefile.
|
|
|
|
@item Generate @file{config.status}
|
|
@code{configure} creates a shell script named @file{config.status} in
|
|
the build directory. This shell script, when run from the build
|
|
directory, will reconfigure the build directory (but not its
|
|
subdirectories). This is most often used to have a @code{Makefile} update
|
|
itself automatically if a new source directory is available.
|
|
|
|
@item Recursion
|
|
If the source directory has subdirectories that should also be
|
|
configured, @code{configure} is called for each.
|
|
@end table
|
|
|
|
@node Invoking, Using Configure, What Configure Does, top
|
|
@chapter Invoking
|
|
|
|
The usual way to invoke @code{configure} is as follows:
|
|
@example
|
|
configure @var{host}
|
|
@end example
|
|
This prepares 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.
|
|
|
|
@code{configure} prepares the source as you specify by selecting and
|
|
using script and Makefile fragments prepared in advance, and stored with
|
|
the source. @code{configure}'s command line options also allow you to
|
|
specify other aspects of the source configuration:
|
|
|
|
@table @code
|
|
@item -datadir=@var{dir}
|
|
Configure the source to install host independent files in @var{dir}.
|
|
|
|
This option sets the @code{configure} variable @code{datadir}.
|
|
Generated Makefiles will have their @code{datadir} variables set to this
|
|
value. (See @ref{Install Details}.)
|
|
|
|
@item -gas
|
|
Configure to use the @sc{GNU} assembler.
|
|
|
|
@item -help
|
|
Display a quick summary of how to invoke @code{configure}.
|
|
|
|
@item -host=@var{host}
|
|
FIXME-soon: I don't think this option should be documented.
|
|
@c Then why does it exist? /Pesch 7jan92
|
|
|
|
@item -namesubdir=@var{name}
|
|
NOTE: support for this @code{-namesubdir=} is at least temporarily
|
|
suspended. FIXME-soon
|
|
|
|
Name any subdirectories created by the @code{-subdirs} option
|
|
@file{@var{name}}.
|
|
|
|
@emph{Warning:} Avoid using this option if you specify multiple hosts
|
|
simultaneously. There is no way to specify separate names for
|
|
subdirectories, when you configure for multiple hosts in a single
|
|
invocation of @code{configure}.
|
|
|
|
@item -nfp
|
|
@emph{No floating point} unit available on the target; configure to
|
|
avoid dependencies on hardware floating point.
|
|
|
|
@item -norecursion
|
|
Configure only this directory; ignore any subdirectories. This is used
|
|
by the executable shell script @file{config.status} to reconfigure the
|
|
current directory. (see @ref{config.status}).
|
|
|
|
@ignore
|
|
@c This is complicated enough without "no longer supported" entries.
|
|
@c Should really delete this, but for ease of discourse...
|
|
@item -objdir=@var{dir}
|
|
This option is no longer supported. Use @code{-srcdir=} instead.
|
|
@end ignore
|
|
|
|
@item -prefix=@var{dir}
|
|
Configure the source to install programs and files under directory
|
|
@file{@var{dir}}.
|
|
|
|
This option sets the @code{configure} variable @code{prefix}. Generated
|
|
Makefiles will have their @code{prefix} variables set to this value.
|
|
(See @ref{Install Details}.)
|
|
|
|
@item -recurring
|
|
@c Wouldn't it make more sense to call this "-quiet"? (FIXME).
|
|
This option is used internally by @code{configure} when recurring on
|
|
subdirectories. Its sole purpose is to suppress status output. You can
|
|
override this effect with the @code{-verbose} option.
|
|
|
|
@item -rm
|
|
@emph{Remove} the configuration specified by @var{host} and the other
|
|
command-line options, rather than creating it.
|
|
|
|
@item -site=@var{site}
|
|
Generate Makefiles using site specific Makefile fragments for
|
|
@var{site}. See also @ref{Sites}.
|
|
|
|
@item -srcdir=@var{_dir}
|
|
Build Makefiles to use the sources located in directory @file{@var{dir}}. The
|
|
build directory is assumed to be @file{.}.
|
|
|
|
@item -subdirs
|
|
NOTE: support for this @code{-subdirs} is at least temporary suspended.
|
|
FIXME-soon
|
|
|
|
Place configurations in subdirectories of each build directory.
|
|
@code{configure} builds a separate subdirectory for each host specified,
|
|
and names it @file{H-@var{host}}. If a configuration is not native,
|
|
(@var{host} is not @var{target}), then the subdirectory is named
|
|
@file{X-@var{host}-@var{target}} instead. You can also name a
|
|
subdirectory explicitly using the @samp{-namesubdir} option, but this is
|
|
effective only when you specify one configuration at a time.
|
|
|
|
@item -target=@var{target}
|
|
Requests that the sources be configured to target the @var{target}
|
|
machine. If no target is specified explicitly, the target is assumed
|
|
to be the same as the host.
|
|
|
|
NOTE: support for multiple targets is at least temporarily suspended.
|
|
FIXME-soon
|
|
@*
|
|
If multiple targets are specified, configurations for each
|
|
are created and @code{-subdirs} is assumed.
|
|
|
|
@item -tmpdir=@var{tmpdir}
|
|
Use the directory @var{tmpdir} for @code{configure}'s temporary files.
|
|
The default is the value of the environment variable TMPDIR, or
|
|
@file{/tmp} if the environment variable is not set.
|
|
|
|
@item -verbose
|
|
@itemx -v
|
|
Print status lines for each directory configured. Normally, only the
|
|
status lines for the initial working directory are printed.
|
|
|
|
@item -x
|
|
Use @sc{MIT} style @sc{X11} header files and libraries on the host, even
|
|
if they are not normally available.
|
|
@end table
|
|
|
|
@node Using Configure, Porting, Invoking, top
|
|
@chapter Using Configure
|
|
|
|
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} creates 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
|
|
often 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 location is determined by the value of
|
|
the @code{configure} variable @code{prefix}; in turn, this determines the
|
|
value of the Makefile variable of the same name (@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 consistently 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=}.
|
|
|
|
|
|
@node datadir, Install Details, prefix, Install Locations
|
|
@subsection Installing for multiple hosts
|
|
@cindex Configuring for multiple hosts
|
|
@cindex Sharing host independent files
|
|
@cindex The @file{datadir} directory
|
|
@cindex Installing host independent files
|
|
|
|
By default, host independent files are installed in subdirectories of
|
|
@file{@var{prefix}/lib}. The location is determined by the value of the
|
|
@code{configure} variable @code{datadir}, which determines the value of
|
|
the Makefile variable @code{datadir}. This makes it simpler to install
|
|
for a single host, and simplifies changing the default location for the
|
|
install tree; but the default 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} to place host
|
|
specific programs in subdirectories of @file{/usr/gnu/H-@var{host1}},
|
|
and host independent files in @file{/usr/gnu/H-independent}.
|
|
|
|
The second line builds and installs all programs for @var{host1},
|
|
including both host independent and host specific files.
|
|
|
|
The third line reconfigures the source for @var{host2} to place host
|
|
specific programs in subdirectories of @file{/usr/gnu/H-@var{host2}},
|
|
and host independent files (once again) in
|
|
@file{/usr/gnu/H-independent}.
|
|
|
|
The fourth line builds and installs all programs for @var{host2}. Host
|
|
specific files are installed in new directories, but the host
|
|
independent files are 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
|
|
make all install
|
|
@end example
|
|
|
|
@node Install Details, , datadir, Install Locations
|
|
@subsection 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 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 the directory @code{srcdir}
|
|
at any time. @code{srcdir} is not an installation directory.
|
|
|
|
You can override all makefile variables on the command line to
|
|
@code{make}. (See @ref{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
|
|
@ref{Sites}.
|
|
|
|
During @code{make install}, a number of standard directories are
|
|
created and populated. The following Makefile variables define them.
|
|
Those whose defaults are set by corresponding @code{configure} variables
|
|
are marked ``Makefile and configure''.
|
|
|
|
@vindex prefix
|
|
@defvr {Makefile and configure} prefix
|
|
The root of the installation tree. You can set
|
|
its Makefile default with the @code{-prefix=} command line option to
|
|
@code{configure}. (@ref{Invoking}.) The default value for
|
|
@code{prefix} is @file{/usr/local}.
|
|
@end defvr
|
|
|
|
@vindex bindir
|
|
@defvr Makefile bindir
|
|
A directory for binary programs that users can run.
|
|
The default value for @code{bindir} depends on @code{prefix};
|
|
@code{bindir} is normally changed only indirectly through @code{prefix}.
|
|
The default value for @code{bindir} is @file{$(prefix)/bin}.
|
|
@end defvr
|
|
|
|
@vindex datadir
|
|
@defvr {Makefile and configure} datadir
|
|
A directory for host independent files. You can specify the Makefile
|
|
default value by using the @code{-datadir=} option to @code{configure}.
|
|
(See also @ref{Invoking}.) The default value for @code{datadir} is
|
|
@file{$(prefix)/lib}.
|
|
@end defvr
|
|
|
|
@vindex libdir
|
|
@defvr Makefile libdir
|
|
A directory for libraries and support programs. The default value for
|
|
@code{libdir} depends on @code{prefix}; @code{libdir} is normally
|
|
changed only indirectly through @code{prefix}. The default value for
|
|
@code{libdir} is @file{$(prefix)/lib}.
|
|
@end defvr
|
|
|
|
@vindex mandir
|
|
@defvr Makefile mandir
|
|
A directory for @code{man} format documentation (``man pages''). The
|
|
default value for @code{mandir} depends on @code{prefix};
|
|
@code{mandir} is normally changed only indirectly through @code{prefix}.
|
|
The default value for @code{mandir} is @file{$(datadir)/man}.
|
|
@end defvr
|
|
|
|
@vindex man@var{N}dir
|
|
@defvr Makefile man@var{N}dir
|
|
There are eight variables named @code{man1dir}, @code{man2dir}, etc.
|
|
They name the specific directories for each man page section. For
|
|
example, @code{man1dir} holds @file{emacs.1} (the man page for the emacs
|
|
program), while @code{man5dir} holds @file{rcsfile.5} (the man page
|
|
describing the @code{rcs} data file format). The default value for any
|
|
of the @code{man@var{N}dir} variables depends indirectly on
|
|
@code{prefix}, and is normally changed only through @code{prefix}. The
|
|
default value for @code{man@var{N}dir} is
|
|
@file{$(mandir)/man@var{N}}.
|
|
@end defvr
|
|
|
|
@vindex manext
|
|
@defvr Makefile manext
|
|
@emph{Not supported by @code{configure}}. The @sc{gnu} coding standards
|
|
do not call for @code{man1ext}, @code{man2ext}, so the intended use for
|
|
@code{manext} is apparently not parallel to @code{mandir}. Its use is
|
|
not clear. (See also @ref{Makefile Extensions}.)
|
|
@end defvr
|
|
|
|
@vindex infodir
|
|
@defvr Makefile infodir
|
|
A directory for @emph{info} format documentation. The default value for
|
|
@code{infodir} depends indirectly on @code{prefix}; @code{infodir} is
|
|
normally changed only through @code{prefix}. The default value for
|
|
@code{infodir} is @file{$(datadir)/info}.
|
|
@end defvr
|
|
|
|
@vindex docdir
|
|
@defvr Makefile docdir
|
|
A directory for any documentation that is in a format other than those
|
|
used by @code{info} or @code{man}. The default value for @code{docdir}
|
|
depends indirectly on @code{prefix}; @code{docdir} is normally changed only
|
|
through @code{prefix}. The default value for @code{docdir}
|
|
is @file{$(datadir)/doc}. @emph{This variable is an extension to
|
|
the @sc{gnu} coding standards}. (See also @ref{Makefile Extensions}.)
|
|
@end defvr
|
|
|
|
@vindex includedir
|
|
@defvr Makefile includedir
|
|
A directory for the header files accompanying the libraries installed in
|
|
@code{libdir}. The default value for @code{includedir} depends on
|
|
@code{prefix}; @code{includedir} is normally changed only indirectly
|
|
through @code{prefix}. The default value for @code{includedir} is
|
|
@file{$(prefix)/include}.
|
|
@end defvr
|
|
|
|
@node Build Directories, Host, Install Locations, Using Configure
|
|
@section Build Directories
|
|
@cindex Build directories
|
|
@kindex objdir
|
|
@cindex Object directories
|
|
@kindex 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 where @code{configure} builds a
|
|
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 use a different build directory with a sequence like the following:
|
|
|
|
@example
|
|
mkdir @var{builddir}
|
|
cd @var{builddir}
|
|
configure @var{host} -srcdir=@var{sourcedirectory}
|
|
@end example
|
|
|
|
@noindent
|
|
where @var{builddir} is the directory where 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.
|
|
|
|
@quotation
|
|
@emph{NOTE:} The rest of this section describes the @code{-subdirs} feature for
|
|
which support is at least temporarily suspended. FIXME-soon.
|
|
@end quotation
|
|
|
|
Another way to specify the build directory is with the @samp{-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, configuring for multiple hosts or multiple targets implies
|
|
@samp{-subdirs}.
|
|
|
|
When configuring for cross tools (the converse of native tools: when the
|
|
host is not the target), as in:
|
|
|
|
@example
|
|
configure @var{host} +target=@var{targ} -subdirs
|
|
@end example
|
|
|
|
@noindent
|
|
the subdirectories are named @file{X-@var{host}-@var{targ}}. This is
|
|
especially useful when configuring for multiple targets.
|
|
|
|
If you use both @samp{-subdirs} and @samp{-srcdir=}, a tree that
|
|
parallels the source directory structure is created in the current
|
|
directory, and the subdirectories are created in this directory
|
|
tree rather than in the source directories.
|
|
|
|
@emph{NOTE:} previously, @samp{-subdirs} built two-level subdirectories
|
|
as @file{./H-@var{host}/T-@var{target}}, created
|
|
@file{./H-@var{host}/Makefile} for building across all targets,
|
|
@file{./Makefile} for building across all hosts, and
|
|
@file{./config.status} and @file{./H-@var{host}/config.status} for
|
|
rebuilding these Makefiles.
|
|
|
|
@node Host, Target, Build Directories, Using Configure
|
|
@section Host
|
|
|
|
@quotation
|
|
@emph{NOTE:} support for multiple hosts is at least temporarily suspended.
|
|
FIXME-soon.
|
|
@end quotation
|
|
|
|
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 physical machine involved,
|
|
although it usually is.
|
|
|
|
For example, if some obscure machine running an operating system other
|
|
than @sc{un*x} 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 @ref{Host Environments, , 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 @sc{gnu}
|
|
tools, 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 @ref{Building
|
|
Development Environments, , 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 if
|
|
@code{configure}'s conventions differ from your local conventions, you
|
|
should probably consider site specific Makefile fragments. See also
|
|
@ref{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 Porting, Reference, Using Configure, top
|
|
@chapter Porting with Configure
|
|
@cindex Porting
|
|
|
|
This section explains how to add programs, host and target configuration
|
|
names, and site-specific information 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 criteria 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. @code{autoconf} will
|
|
be available soon from the @sc{fsf}.
|
|
|
|
To add Cygnus configure to an existing program, do the following:
|
|
|
|
@table @asis
|
|
@item Make sure the Makefile conforms to @sc{gnu} standard
|
|
The coding standard for @sc{gnu} Makefiles is described in
|
|
@cite{standards.text}.
|
|
|
|
@item Add Cygnus extensions to the Makefile
|
|
These are described in @ref{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 called @file{./config/mh-foo}. For more information, see @ref{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 site specific Makefile fragments can
|
|
override them (@pxref{Makefile Extensions,,Extensions to the @sc{gnu}
|
|
coding standards}).
|
|
|
|
@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 yours does
|
|
not, you will need to separate these two kinds of configuration
|
|
information. @dfn{Host specific} information is the information needed to
|
|
compile the program. @dfn{Target specific} information is 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 @code{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 @ref{Build Directories}).
|
|
The format of configure.in is described in @ref{configure.in}.
|
|
|
|
@item Rename @file{Makefile} to @file{Makefile.in}
|
|
@end table
|
|
|
|
At this point you should have a program that can be configured using
|
|
Cygnus @code{configure}.
|
|
|
|
@node Hosts and Targets, Sites, Programs, Porting
|
|
@section Adding hosts and targets
|
|
|
|
To add a host or target to a program that already 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 @ref{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 @ref{configure.in}.
|
|
|
|
@item
|
|
Look in @file{configure.in} for the variables @samp{files},
|
|
@samp{links}, @samp{host_makefile_frag}, and
|
|
@samp{target_makefile_frag}. The values assigned to these variables are
|
|
the names of the configuration files, relative to @code{srcdir} that the
|
|
program uses. Make sure that copies of the files exist for your host.
|
|
If not, create them. See also @ref{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
|
|
remains 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 source 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 whatever Makefile variables you need
|
|
to override to match your site's conventions.
|
|
|
|
@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 they are documented here for
|
|
completeness.
|
|
|
|
@table @code
|
|
@kindex info
|
|
@item info
|
|
Build all info files from texinfo source.
|
|
|
|
@kindex install-info
|
|
@item install-info
|
|
Install all info files.
|
|
|
|
@kindex clean-info
|
|
@item clean-info
|
|
Remove all info files and any intermediate files that can be generated
|
|
from texinfo source.
|
|
|
|
@kindex stage1
|
|
@item stage1
|
|
@kindex stage2
|
|
@itemx stage2
|
|
@kindex stage3
|
|
@itemx stage3
|
|
@kindex stage4
|
|
@itemx stage4
|
|
@kindex de-stage1
|
|
@itemx de-stage1
|
|
@kindex de-stage2
|
|
@itemx de-stage2
|
|
@kindex de-stage3
|
|
@itemx de-stage3
|
|
@kindex de-stage4
|
|
@itemx de-stage4
|
|
@kindex bootstrap
|
|
@itemx bootstrap
|
|
@kindex comparison
|
|
@itemx comparison
|
|
@kindex Makefile
|
|
@itemx Makefile
|
|
These targets are in transition and may be removed shortly.
|
|
@end table
|
|
|
|
In addition, the following Makefile targets have revised semantics:
|
|
|
|
@table @code
|
|
@kindex 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 you
|
|
to install programs 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.
|
|
|
|
@kindex 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 @file{Makefile.in} files, but
|
|
you are not required to use them to run Cygnus configure.
|
|
|
|
@table @code
|
|
@kindex 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.
|
|
|
|
@kindex 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. Most of them
|
|
describe installation directories; see also @ref{Install Details,,Full
|
|
description of all installation subdirectories}.
|
|
|
|
@table @code
|
|
|
|
@kindex manext
|
|
@item manext
|
|
is not used. The intended usage is not clear. For example, if you 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 what is the desired value
|
|
of @code{manext}?
|
|
|
|
@kindex datadir
|
|
@item datadir
|
|
is used for @emph{all} host independent files. This makes it possible
|
|
to share host independent files across multiple hosts without resorting
|
|
to symbolic links or to 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.
|
|
|
|
@kindex mandir
|
|
@item mandir
|
|
The default path for @code{mandir} depends on @code{datadir}, since man
|
|
pages are host independent.
|
|
|
|
@kindex infodir
|
|
@item infodir
|
|
The default path for @code{infodir} depends on @code{datadir}, since
|
|
info files are host independent.
|
|
|
|
@kindex BISON
|
|
@item BISON
|
|
is assumed to have a @code{yacc} calling convention. To use
|
|
@code{bison}, use @code{BISON=bison -y}.
|
|
@end table
|
|
|
|
Cygnus Makefiles also conform to one additional restriction:
|
|
|
|
@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 @code{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 @file{configure.in} file
|
|
@kindex configure.in
|
|
|
|
A @file{configure.in} file for Cygnus configure consists of a
|
|
@dfn{per-invocation} section, followed by a @dfn{per-host} section,
|
|
followed by a @dfn{per-target} section, optionally followed by a
|
|
@dfn{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-invocation section
|
|
The beginning of the @file{configure.in} file begins the per-invocation
|
|
section.
|
|
|
|
@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:: For each invocation
|
|
* Per-host:: For each host
|
|
* Per-target:: For each target
|
|
* Post-target:: After each target
|
|
* Example:: An example configure.in
|
|
@end menu
|
|
|
|
@node Minimal, Configure Variables, configure.in, configure.in
|
|
@subsection A minimal @file{configure.in}
|
|
|
|
@cindex Minimal @file{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 @samp{Per-host} and @samp{Per-target} lines divide the file into the
|
|
three required sections. The @samp{srctrigger} line names a file.
|
|
@code{configure} checks to see that this file exists in the source
|
|
directory before configuring. If the @samp{srctrigger} file does not
|
|
exist, @code{configure} uses the value of @samp{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 @file{configure.in} interface
|
|
|
|
The following variables pass information between the standard parts of
|
|
@code{configure} and the shell-script fragments in @file{configure.in}:
|
|
|
|
@defvar{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 @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 collection contained in the source
|
|
directory. You must usually set this in the per-invocation 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 where @code{configure} should
|
|
recur. You must usually set this in the per-invocation 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.
|
|
@c Most other matching makefile/config vars use the same name. Why not
|
|
@c this? (FIXME).
|
|
@end defvar
|
|
|
|
@defvar{target_dependent}
|
|
NOTE: support for multiple targets is currently suspended.
|
|
@*
|
|
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, and to 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 name that the user entered for the host. Since many things
|
|
that the user could enter would map to the same output from
|
|
@code{config.sub}, 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.
|
|
@c "@emph{common} OS" doesn't convey much to me. Is this meant to cover
|
|
@c cases like Unix, widespread but with many variations?
|
|
@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 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 differ from the system where 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.
|
|
@c above query re "@emph{common} OS" applies here too
|
|
@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 @sc{gas} available even if they ordinarily do
|
|
not. The converse option @samp{-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
|
|
|
|
@defvar{srcdir}
|
|
NOTE: support for @code{-subdirs} is at least temporarily suspended.
|
|
@*
|
|
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}
|
|
If set by @file{configure.in}, this variable should be the name a file,
|
|
relative to @code{srcdir} to be included in the resulting Makefile. If
|
|
the named file does not exist, @code{configure} will print a warning
|
|
message. This variable is not set by @code{configure}.
|
|
@end defvar
|
|
|
|
@defvar{target_makefile_frag}
|
|
If set by @file{configure.in}, this variable should be the name of a
|
|
file, relative to @code{srcdir}, to be included in the resulting
|
|
Makefile. If the named file does not exist, @code{configure} will print
|
|
a warning message. This variable is not set by @code{configure}.
|
|
@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 override this
|
|
default. Normally @code{site_makefile_frag} is empty, but will have a
|
|
value if the user specified @code{-site=} on the command line. It is
|
|
probably not a good idea to override this variable from
|
|
@file{configure.in}, since that may defeat the @code{configure} user's
|
|
intentions.
|
|
@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 its value will be the target of a symbolic link named
|
|
in the corresponding word from the @code{links} variable.
|
|
@end defvar
|
|
|
|
@defvar{links}
|
|
If the @code{files} variable is non-empty following the
|
|
@code{per-target:} section, then @code{configure} creates symbolic links
|
|
with the first word of @code{links} pointing to the first word of
|
|
@code{files}, the second word of @code{links} pointing to the second
|
|
word of @code{files}, and so on.
|
|
@end defvar
|
|
|
|
@node Declarations, Per-host, Configure Variables, configure.in
|
|
@subsection For each invocation
|
|
|
|
@cindex Declarations section
|
|
|
|
@code{configure} sources the entire shell script fragment from the start
|
|
of @file{configure.in} up to a line beginning with @samp{# Per-host:}
|
|
immediately after parsing command line arguments. The variables
|
|
@code{srctrigger} and @code{srcname} @emph{must} be set here.
|
|
|
|
You might also want to set the variables @code{configdirs} or
|
|
@code{target_dependent} here.
|
|
@*
|
|
FIXME-soon. target_dependent isn't useful without multiple targets.
|
|
|
|
@node Per-host, Per-target, Declarations, configure.in
|
|
@subsection For each host
|
|
@cindex per-host section
|
|
@cindex host shell-script fragment
|
|
|
|
The per-host section of @file{configure.in} starts with the line that begins
|
|
with @samp{# Per-host:} and ends before a line beginning with
|
|
@samp{# Per-target:}. @code{configure} sources the per-host section once for
|
|
each host.
|
|
|
|
This section usually contains a big case statement using the variables
|
|
@samp{host_cpu}, @samp{host_vendor}, and @samp{host_os} to determine
|
|
appropriate values for @samp{host_makefile_frag} and @samp{files},
|
|
although @samp{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 For each target
|
|
@cindex per-target section
|
|
@cindex target shell-script fragment
|
|
|
|
The per-target section of @file{configure.in} starts with the line that
|
|
begins with @samp{# Per-target:} and ends before the line that begins
|
|
with @samp{# Post-target:}, if there is such a line. Otherwise the
|
|
per-target section extends to the end of the file. @code{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 called
|
|
@samp{target_cpu}, @samp{target_vendor}, and @samp{target_os} to determine
|
|
appropriate values for @samp{target_makefile_frag} and @samp{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, @code{configure} sources 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 @code{configure}.
|
|
|
|
@node Example, , Post-target, configure.in
|
|
@subsection An example @file{configure.in}
|
|
@cindex example @file{configure.in}
|
|
@cindex sample @file{configure.in}
|
|
@cindex Bison @file{configure.in}
|
|
|
|
Here is a small example of a @file{configure.in} file.
|
|
|
|
@example
|
|
# 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_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 @code{config.status}
|
|
|
|
@kindex config.status
|
|
|
|
The final step in configuring a directory is to create an executable
|
|
shell script, @file{config.status}. The main purpose of this file
|
|
is to allow the Makefile for the current directory to rebuild itself, if
|
|
necessary. For this reason, @file{config.status} uses the
|
|
@samp{-norecursion} option to @code{configure}, and is therefore
|
|
probably inappropriate for reconfiguring a tree of source code.
|
|
|
|
@node Makefile Fragments, , config.status, Reference
|
|
@section Makefile Fragments
|
|
|
|
@cindex Makefile fragments
|
|
|
|
Cygnus @code{configure} uses three types of Makefile fragments. In a
|
|
generated Makefile they appear in the order target fragment, host
|
|
fragment, and site fragment. This allows host fragments to override
|
|
target fragments, and site fragments to override both.
|
|
|
|
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 you can also overridde these options on the
|
|
@code{make} invocation line.
|
|
|
|
@node Known Bugs, Variables Index, Reference, top
|
|
@chapter Known Bugs
|
|
|
|
@cindex bugs
|
|
|
|
We know of the following bugs:
|
|
|
|
@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{")
|