configure.texi

来自「基于4个mips核的noc设计」· TEXI 代码 · 共 1,744 行 · 第 1/5 页

The others are generated by various tools.

The system is rather flexible, and can be used in many different ways.
In describing the files that it uses, I will describe the common case,
and mention some other cases that may arise.

@menu
* Developer Files::		Developer Files.
* Build Files::			Build Files.
* Support Files::		Support Files.
@end menu

@node Developer Files
@section Developer Files

This section describes the files written or generated by the developer
of a package.

@menu
* Developer Files Picture::	Developer Files Picture.
* Written Developer Files::	Written Developer Files.
* Generated Developer Files::	Generated Developer Files.
@end menu

@node Developer Files Picture
@subsection Developer Files Picture

Here is a picture of the files which are written by the developer, the
generated files which would be included with a complete source
distribution, and the tools which create those files.
@ifinfo
The file names are plain text and the tool names are enclosed by
@samp{*} characters
@end ifinfo
@ifnotinfo
The file names are in rectangles with square corners and the tool names
are in rectangles with rounded corners
@end ifnotinfo
(e.g., @samp{autoheader} is the name of a tool, not the name of a file).

@image{configdev}

@node Written Developer Files
@subsection Written Developer Files

The following files would be written by the developer.

@table @file
@item configure.in
@cindex @file{configure.in}
This is the configuration script.  This script contains invocations of
autoconf macros.  It may also contain ordinary shell script code.  This
file will contain feature tests for portability issues.  The last thing
in the file will normally be an @samp{AC_OUTPUT} macro listing which
files to create when the builder runs the configure script.  This file
is always required when using the GNU configure system.  @xref{Write
configure.in}.

@item Makefile.am
@cindex @file{Makefile.am}
This is the automake input file.  It describes how the code should be
built.  It consists of definitions of automake variables.  It may also
contain ordinary Makefile targets.  This file is only needed when using
automake (newer tools normally use automake, but there are still older
tools which have not been converted, in which the developer writes
@file{Makefile.in} directly).  @xref{Write Makefile.am}.

@item acconfig.h
@cindex @file{acconfig.h}
When the configure script creates a portability header file, by using
@samp{AM_CONFIG_HEADER} (or, if not using automake,
@samp{AC_CONFIG_HEADER}), this file is used to describe macros which are
not recognized by the @samp{autoheader} command.  This is normally a
fairly uninteresting file, consisting of a collection of @samp{#undef}
lines with comments.  Normally any call to @samp{AC_DEFINE} in
@file{configure.in} will require a line in this file. @xref{Write
acconfig.h}.

@item acinclude.m4
@cindex @file{acinclude.m4}
This file is not always required.  It defines local autoconf macros.
These macros may then be used in @file{configure.in}.  If you don't need
any local autoconf macros, then you don't need this file at all.  In
fact, in general, you never need local autoconf macros, since you can
put everything in @file{configure.in}, but sometimes a local macro is
convenient.

Newer tools may omit @file{acinclude.m4}, and instead use a
subdirectory, typically named @file{m4}, and define
@samp{ACLOCAL_AMFLAGS = -I m4} in @file{Makefile.am} to force
@samp{aclocal} to look there for macro definitions.  The macro
definitions are then placed in separate files in that directory.

The @file{acinclude.m4} file is only used when using automake; in older
tools, the developer writes @file{aclocal.m4} directly, if it is needed.
@end table

@node Generated Developer Files
@subsection Generated Developer Files

The following files would be generated by the developer.

When using automake, these files are normally not generated manually
after the first time.  Instead, the generated @file{Makefile} contains
rules to automatically rebuild the files as required.  When
@samp{AM_MAINTAINER_MODE} is used in @file{configure.in} (the normal
case in Cygnus code), the automatic rebuilding rules will only be
defined if you configure using the @samp{--enable-maintainer-mode}
option.

When using automatic rebuilding, it is important to ensure that all the
various tools have been built and installed on your @samp{PATH}.  Using
automatic rebuilding is highly recommended, so much so that I'm not
going to explain what you have to do if you don't use it.

@table @file
@item configure
@cindex @file{configure}
This is the configure script which will be run when building the
package.  This is generated by @samp{autoconf} from @file{configure.in}
and @file{aclocal.m4}.  This is a shell script.

@item Makefile.in
@cindex @file{Makefile.in}
This is the file which the configure script will turn into the
@file{Makefile} at build time.  This file is generated by
@samp{automake} from @file{Makefile.am}.  If you aren't using automake,
you must write this file yourself.  This file is pretty much a normal
@file{Makefile}, with some configure substitutions for certain
variables.

@item aclocal.m4
@cindex @file{aclocal.m4}
This file is created by the @samp{aclocal} program, based on the
contents of @file{configure.in} and @file{acinclude.m4} (or, as noted in
the description of @file{acinclude.m4} above, on the contents of an
@file{m4} subdirectory).  This file contains definitions of autoconf
macros which @samp{autoconf} will use when generating the file
@file{configure}.  These autoconf macros may be defined by you in
@file{acinclude.m4} or they may be defined by other packages such as
automake, libtool or gettext.  If you aren't using automake, you will
normally write this file yourself; in that case, if @file{configure.in}
uses only standard autoconf macros, this file will not be needed at all.

@item config.in
@cindex @file{config.in}
@cindex @file{config.h.in}
This file is created by @samp{autoheader} based on @file{acconfig.h} and
@file{configure.in}.  At build time, the configure script will define
some of the macros in it to create @file{config.h}, which may then be
included by your program.  This permits your C code to use preprocessor
conditionals to change its behaviour based on the characteristics of the
host system.  This file may also be called @file{config.h.in}.

@item stamp.h-in
@cindex @file{stamp-h.in}
This rather uninteresting file, which I omitted from the picture, is
generated by @samp{automake}.  It always contains the string
@samp{timestamp}.  It is used as a timestamp file indicating whether
@file{config.in} is up to date.  Using a timestamp file means that
@file{config.in} can be marked as up to date without actually changing
its modification time.  This is useful since @file{config.in} depends
upon @file{configure.in}, but it is easy to change @file{configure.in}
in a way which does not affect @file{config.in}.
@end table

@node Build Files
@section Build Files

This section describes the files which are created at configure and
build time.  These are the files which somebody who builds the package
will see.

Of course, the developer will also build the package.  The distinction
between developer files and build files is not that the developer does
not see the build files, but that somebody who only builds the package
does not have to worry about the developer files.

@menu
* Build Files Picture::		Build Files Picture.
* Build Files Description::	Build Files Description.
@end menu

@node Build Files Picture
@subsection Build Files Picture

Here is a picture of the files which will be created at build time.
@file{config.status} is both a created file and a shell script which is
run to create other files, and the picture attempts to show that.

@image{configbuild}

@node Build Files Description
@subsection Build Files Description

This is a description of the files which are created at build time.

@table @file
@item config.status
@cindex @file{config.status}
The first step in building a package is to run the @file{configure}
script.  The @file{configure} script will create the file
@file{config.status}, which is itself a shell script.  When you first
run @file{configure}, it will automatically run @file{config.status}.
An @file{Makefile} derived from an automake generated @file{Makefile.in}
will contain rules to automatically run @file{config.status} again when
necessary to recreate certain files if their inputs change.

@item Makefile
@cindex @file{Makefile}
This is the file which make will read to build the program.  The
@file{config.status} script will transform @file{Makefile.in} into
@file{Makefile}.

@item config.h
@cindex @file{config.h}
This file defines C preprocessor macros which C code can use to adjust
its behaviour on different systems.  The @file{config.status} script
will transform @file{config.in} into @file{config.h}.

@item config.cache
@cindex @file{config.cache}
This file did not fit neatly into the picture, and I omitted it.  It is
used by the @file{configure} script to cache results between runs.  This
can be an important speedup.  If you modify @file{configure.in} in such
a way that the results of old tests should change (perhaps you have
added a new library to @samp{LDFLAGS}), then you will have to remove
@file{config.cache} to force the tests to be rerun.

The autoconf manual explains how to set up a site specific cache file.
This can speed up running @file{configure} scripts on your system.

@item stamp.h
@cindex @file{stamp-h}
This file, which I omitted from the picture, is similar to
@file{stamp-h.in}.  It is used as a timestamp file indicating whether
@file{config.h} is up to date.  This is useful since @file{config.h}
depends upon @file{config.status}, but it is easy for
@file{config.status} to change in a way which does not affect
@file{config.h}.
@end table

@node Support Files
@section Support Files

The GNU configure and build system requires several support files to be
included with your distribution.  You do not normally need to concern
yourself with these.  If you are using the Cygnus tree, most are already
present.  Otherwise, they will be installed with your source by
@samp{automake} (with the @samp{--add-missing} option) and
@samp{libtoolize}.

You don't have to put the support files in the top level directory.  You
can put them in a subdirectory, and use the @samp{AC_CONFIG_AUX_DIR}
macro in @file{configure.in} to tell @samp{automake} and the
@file{configure} script where they are.

In this section, I describe the support files, so that you can know what
they are and why they are there.

@table @file
@item ABOUT-NLS
Added by automake if you are using gettext.  This is a documentation
file about the gettext project.
@item ansi2knr.c
Used by an automake generated @file{Makefile} if you put @samp{ansi2knr}
in @samp{AUTOMAKE_OPTIONS} in @file{Makefile.am}.  This permits
compiling ANSI C code with a K&R C compiler.
@item ansi2knr.1
The man page which goes with @file{ansi2knr.c}.
@item config.guess
A shell script which determines the configuration name for the system on
which it is run.
@item config.sub
A shell script which canonicalizes a configuration name entered by a
user.
@item elisp-comp
Used to compile Emacs LISP files.
@item install-sh
A shell script which installs a program.  This is used if the configure
script can not find an install binary.
@item ltconfig
Used by libtool.  This is a shell script which configures libtool for
the particular system on which it is used.
@item ltmain.sh
Used by libtool.  This is the actual libtool script which is used, after
it is configured by @file{ltconfig} to build a library.
@item mdate-sh
A shell script used by an automake generated @file{Makefile} to pretty
print the modification time of a file.  This is used to maintain version
numbers for texinfo files.
@item missing
A shell script used if some tool is missing entirely.  This is used by
an automake generated @file{Makefile} to avoid certain sorts of
timestamp problems.
@item mkinstalldirs
A shell script which creates a directory, including all parent
directories.  This is used by an automake generated @file{Makefile}
during installation.
@item texinfo.tex
Required if you have any texinfo files.  This is used when converting
Texinfo files into DVI using @samp{texi2dvi} and @TeX{}.
@item ylwrap
A shell script used by an automake generated @file{Makefile} to run
programs like @samp{bison}, @samp{yacc}, @samp{flex}, and @samp{lex}.
These programs default to producing output files with a fixed name, and
the @file{ylwrap} script runs them in a subdirectory to avoid file name
conflicts when using a parallel make program.
@end table

@node Configuration Names
@chapter Configuration Names
@cindex configuration names
@cindex configuration triplets
@cindex triplets
@cindex host names
@cindex host triplets
@cindex canonical system names
@cindex system names
@cindex system types

The GNU configure system names all systems using a @dfn{configuration
name}.  All such names used to be triplets (they may now contain four
parts in certain cases), and the term @dfn{configuration triplet} is
still seen.

@menu
* Configuration Name Definition::	Configuration Name Definition.
* Using Configuration Names::		Using Configuration Names.
@end menu

@node Configuration Name Definition
@section Configuration Name Definition

This is a string of the form
@var{cpu}-@var{manufacturer}-@var{operating_system}.  In some cases,
this is extended to a four part form:
@var{cpu}-@var{manufacturer}-@var{kernel}-@var{operating_system}.

When using a configuration name in a configure option, it is normally
not necessary to specify an entire name.  In particular, the
@var{manufacturer} field is often omitted, leading to strings such as
@samp{i386-linux} or @samp{sparc-sunos}.  The shell script
@file{config.sub} will translate these shortened strings into the
canonical form.  autoconf will arrange for @file{config.sub} to be run
automatically when it is needed.

The fields of a configuration name are as follows: