1440 lines
51 KiB
Text
1440 lines
51 KiB
Text
\input texinfo @c -*-para-*-
|
|
@c %**start of header
|
|
@setfilename configure.info
|
|
@settitle Cygnus Configure
|
|
@c %**end of header
|
|
@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.
|
|
(see @ref{Top, , , bash}.)
|
|
@c That's a rather extraordinary xref. What's it meant to clarify
|
|
@c ---shell scripts in general??
|
|
|
|
@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}. If
|
|
@code{datadir} is not empty, 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
|
|
@c singular "target" due to apparent direction of configure.
|
|
@emph{No floating point} unit available on the target; configure to
|
|
avoid dependencies on hardware floating point.
|
|
@c Can we even say "configure to use software floating point support"?
|
|
|
|
@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}).
|
|
@c Why *does* that use no recursion? Speed? geometric combinations
|
|
@c under some other script?
|
|
|
|
@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}. If
|
|
@code{prefix} is not empty, 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"?
|
|
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.
|
|
@c default?
|
|
|
|
@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=}.
|
|
@c This is self-referential. What was intended?: (See @ref{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
|
|
|
|
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}.
|
|
@c Self-ref? (See @ref{datadir}.)
|
|
|
|
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.
|
|
@c Won't make notice the installed copies aren't out of date and leave
|
|
@c 'em alone?
|
|
|
|
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
|
|
@c and make something-or-other, surely?
|
|
@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
|
|
@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.
|
|
|
|
@c "Makefile" treated as ordinary word through most of this; I've left it
|
|
@c that way since that seems to agree w ordinary usage. This one was
|
|
@c @code'd; if the intent is to emphasize that we're now talking of it
|
|
@c as a file, I suggest
|
|
@c "...builds @file{Makefile} files"
|
|
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, , 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, , 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}.
|
|
|
|
@c ..............................pesch rev..............................
|
|
|
|
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 @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 call @file{./config/mh-foo}. For more on this, 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 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 @ref{Build Directories}).
|
|
The format of configure.in is described in @ref{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 @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 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 @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 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 @ref{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 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 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 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 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{")
|