configure.texi

早期freebsd实现

			  subdirectories
@end menu

@node prefix, exec_prefix, 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 exec_prefix, Install Details, prefix, Install Locations
@subsection Installing for multiple hosts
@cindex Configuring for multiple hosts
@cindex Sharing host independent files
@cindex The @file{exec_prefix} directory
@cindex Installing host independent files

By default, host dependent files are installed in subdirectories of
@file{@var{exec_prefix}}.  The location is determined by the value of the
@code{configure} variable @code{exec_prefix}, which determines the value of
the Makefile variable @code{exec_prefix}.  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 -exec_prefix=/usr/gnu/H-host1
make all info install install-info clean

configure @var{host2} -prefix=/usr/gnu -exec_prefix=/usr/gnu/H-host2
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}}.  

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}}.

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.

@node Install Details,  , exec_prefix, 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 exec_prefix
@defvr {Makefile and configure} exec_prefix
A directory for host dependent files.  You can specify the Makefile
default value by using the @code{-exec_prefix=} option to @code{configure}.
(See also @ref{Invoking}.)  The default value for @code{exec_prefix} is
@file{$(prefix)}.
@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{$(prefix)/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{$(prefix)/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.

@node Host, Target, Build Directories, Using Configure
@section Host

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}.