configure.texi

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

\input texinfo
@c %**start of header
@setfilename configure.info
@settitle The GNU configure and build system
@setchapternewpage off
@c %**end of header

@dircategory GNU admin
@direntry
* configure: (configure).	The GNU configure and build system
@end direntry

@ifinfo
This file documents the GNU configure and build system.

Copyright (C) 1998 Cygnus Solutions.

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


@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 the Foundation.
@end ifinfo

@titlepage
@title The GNU configure and build system
@author Ian Lance Taylor

@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1998 Cygnus Solutions

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 the Free Software Foundation.
@end titlepage

@ifinfo
@node Top
@top GNU configure and build system

The GNU configure and build system.

@menu
* Introduction::		Introduction.
* Getting Started::		Getting Started.
* Files::			Files.
* Configuration Names::		Configuration Names.
* Cross Compilation Tools::	Cross Compilation Tools.
* Canadian Cross::		Canadian Cross.
* Cygnus Configure::		Cygnus Configure.
* Multilibs::			Multilibs.
* FAQ::				Frequently Asked Questions.
* Index::			Index.
@end menu

@end ifinfo

@node Introduction
@chapter Introduction

This document describes the GNU configure and build systems.  It
describes how autoconf, automake, libtool, and make fit together.  It
also includes a discussion of the older Cygnus configure system.

This document does not describe in detail how to use each of the tools;
see the respective manuals for that.  Instead, it describes which files
the developer must write, which files are machine generated and how they
are generated, and where certain common problems should be addressed.

@ifnothtml
This document draws on several sources, including the autoconf manual by
David MacKenzie (@pxref{Top, , autoconf overview, autoconf, Autoconf}),
the automake manual by David MacKenzie and Tom Tromey (@pxref{Top, ,
automake overview, automake, GNU Automake}), the libtool manual by
Gordon Matzigkeit (@pxref{Top, , libtool overview, libtool, GNU
libtool}), and the Cygnus configure manual by K. Richard Pixley.
@end ifnothtml
@ifhtml
This document draws on several sources, including
@uref{http://www.delorie.com/gnu/docs/autoconf/autoconf_toc.html, the
autoconf manual} by David MacKenzie,
@uref{http://www.delorie.com/gnu/docs/automake/automake_toc.html, the
automake manual} by David MacKenzie and Tom Tromey,
@uref{http://www.delorie.com/gnu/docs/libtool/libtool_toc.html, the
libtool manual} by Gordon Matzigkeit, and the Cygnus configure manual by
K. Richard Pixley.
@end ifhtml

@menu
* Goals::			Goals.
* Tools::			The tools.
* History::			History.
* Building::			Building.
@end menu

@node Goals
@section Goals
@cindex goals

The GNU configure and build system has two main goals.

The first is to simplify the development of portable programs.  The
system permits the developer to concentrate on writing the program,
simplifying many details of portability across Unix and even Windows
systems, and permitting the developer to describe how to build the
program using simple rules rather than complex Makefiles.

The second is to simplify the building of programs distributed as source
code.  All programs are built using a simple, standardized, two step
process.  The program builder need not install any special tools in
order to build the program.

@node Tools
@section Tools

The GNU configure and build system is comprised of several different
tools.  Program developers must build and install all of these tools.

People who just want to build programs from distributed sources normally
do not need any special tools beyond a Unix shell, a make program, and a
C compiler.

@table @asis
@item autoconf
provides a general portability framework, based on testing the features
of the host system at build time.
@item automake
a system for describing how to build a program, permitting the developer
to write a simplified @file{Makefile}.
@item libtool
a standardized approach to building shared libraries.
@item gettext
provides a framework for translation of text messages into other
languages; not really discussed in this document.
@item m4
autoconf requires the GNU version of m4; the standard Unix m4 does not
suffice.
@item perl
automake requires perl.
@end table

@node History
@section History
@cindex history

This is a very brief and probably inaccurate history.

As the number of Unix variants increased during the 1980s, it became
harder to write programs which could run on all variants.  While it was
often possible to use @code{#ifdef} to identify particular systems,
developers frequently did not have access to every system, and the
characteristics of some systems changed from version to version.

By 1992, at least three different approaches had been developed:
@itemize @bullet
@item
The Metaconfig program, by Larry Wall, Harlan Stenn, and Raphael
Manfredi.
@item
The Cygnus configure script, by K. Richard Pixley, and the gcc configure
script, by Richard Stallman.  These use essentially the same approach,
and the developers communicated regularly.
@item
The autoconf program, by David MacKenzie.
@end itemize

The Metaconfig program is still used for Perl and a few other programs.
It is part of the Dist package.  I do not know if it is being developed.

In 1994, David MacKenzie and others modified autoconf to incorporate all
the features of Cygnus configure.  Since then, there has been a slow but
steady conversion of GNU programs from Cygnus configure to autoconf. gcc
has been converted, eliminating the gcc configure script.

GNU autoconf was regularly maintained until late 1996.  As of this
writing in June, 1998, it has no public maintainer.

Most programs are built using the make program, which requires the
developer to write Makefiles describing how to build the programs.
Since most programs are built in pretty much the same way, this led to a
lot of duplication.

The X Window system is built using the imake tool, which uses a database
of rules to eliminate the duplication.  However, building a tool which
was developed using imake requires that the builder have imake
installed, violating one of the goals of the GNU system.

The new BSD make provides a standard library of Makefile fragments,
which permits developers to write very simple Makefiles.  However, this
requires that the builder install the new BSD make program.

In 1994, David MacKenzie wrote the first version of automake, which
permitted writing a simple build description which was converted into a
Makefile which could be used by the standard make program.  In 1995, Tom
Tromey completely rewrote automake in Perl, and he continues to enhance
it.

Various free packages built libraries, and by around 1995 several
included support to build shared libraries on various platforms.
However, there was no consistent approach.  In early 1996, Gordon
Matzigkeit began working on libtool, which provided a standardized
approach to building shared libraries.  This was integrated into
automake from the start.

The development of automake and libtool was driven by the GNITS project,
a group of GNU maintainers who designed standardized tools to help meet
the GNU coding standards.

@node Building
@section Building

Most readers of this document should already know how to build a tool by
running @samp{configure} and @samp{make}.  This section may serve as a
quick introduction or reminder.

Building a tool is normally as simple as running @samp{configure}
followed by @samp{make}.  You should normally run @samp{configure} from
an empty directory, using some path to refer to the @samp{configure}
script in the source directory.  The directory in which you run
@samp{configure} is called the @dfn{object directory}.

In order to use a object directory which is different from the source
directory, you must be using the GNU version of @samp{make}, which has
the required @samp{VPATH} support.  Despite this restriction, using a
different object directory is highly recommended:
@itemize @bullet
@item
It keeps the files generated during the build from cluttering up your
sources.
@item 
It permits you to remove the built files by simply removing the entire
build directory.
@item
It permits you to build from the same sources with several sets of
configure options simultaneously.
@end itemize

If you don't have GNU @samp{make}, you will have to run @samp{configure}
in the source directory.  All GNU packages should support this; in
particular, GNU packages should not assume the presence of GNU
@samp{make}.

After running @samp{configure}, you can build the tools by running
@samp{make}.

To install the tools, run @samp{make install}.  Installing the tools
will copy the programs and any required support files to the
@dfn{installation directory}.  The location of the installation
directory is controlled by @samp{configure} options, as described below.

In the Cygnus tree at present, the info files are built and installed as
a separate step.  To build them, run @samp{make info}.  To install them,
run @samp{make install-info}.

All @samp{configure} scripts support a wide variety of options.  The
most interesting ones are @samp{--with} and @samp{--enable} options
which are generally specific to particular tools.  You can usually use
the @samp{--help} option to get a list of interesting options for a
particular configure script.

The only generic options you are likely to use are the @samp{--prefix}
and @samp{--exec-prefix} options.  These options are used to specify the
installation directory.

The directory named by the @samp{--prefix} option will hold machine
independent files such as info files.

The directory named by the @samp{--exec-prefix} option, which is
normally a subdirectory of the @samp{--prefix} directory, will hold
machine dependent files such as executables.

The default for @samp{--prefix} is @file{/usr/local}.  The default for
@samp{--exec-prefix} is the value used for @samp{--prefix}.

The convention used in Cygnus releases is to use a @samp{--prefix}
option of @file{/usr/cygnus/@var{release}}, where @var{release} is the
name of the release, and to use a @samp{--exec-prefix} option of
@file{/usr/cygnus/@var{release}/H-@var{host}}, where @var{host} is the
configuration name of the host system (@pxref{Configuration Names}).

Do not use either the source or the object directory as the installation
directory.  That will just lead to confusion.

@node Getting Started
@chapter Getting Started

To start using the GNU configure and build system with your software
package, you must write three files, and you must run some tools to
manually generate additional files.

@menu
* Write configure.in::		Write configure.in.
* Write Makefile.am::		Write Makefile.am.
* Write acconfig.h::		Write acconfig.h.
* Generate files::		Generate files.
* Getting Started Example::	Example.
@end menu

@node Write configure.in
@section Write configure.in
@cindex @file{configure.in}, writing

You must first write the file @file{configure.in}.  This is an autoconf
input file, and the autoconf manual describes in detail what this file
should look like.

You will write tests in your @file{configure.in} file to check for
conditions that may change from one system to another, such as the
presence of particular header files or functions.

For example, not all systems support the @samp{gettimeofday} function.
If you want to use the @samp{gettimeofday} function when it is
available, and to use some other function when it is not, you would
check for this by putting @samp{AC_CHECK_FUNCS(gettimeofday)} in
@file{configure.in}.

When the configure script is run at build time, this will arrange to
define the preprocessor macro @samp{HAVE_GETTIMEOFDAY} to the value 1 if
the @samp{gettimeofday} function is available, and to not define the
macro at all if the function is not available.  Your code can then use
@samp{#ifdef} to test whether it is safe to call @samp{gettimeofday}.

If you have an existing body of code, the @samp{autoscan} program may