File:  [Local Repository] / gnujdoc / autoconf-2.13 / autoconf-ja.texi
Revision 1.2: download - view: text, annotated - select for diffs
Mon Sep 18 11:02:08 2000 UTC (20 years, 1 month ago) by futoshi
Branches: MAIN
CVS tags: HEAD
Replace install.texi to install-ja.texi

\input texinfo @c -*-texinfo-*-
@c %**start of header
@setfilename autoconf-ja.info
@settitle Autoconf
@c For double-sided printing, uncomment:
@c @setchapternewpage odd
@c %**end of header

@set EDITION 2.13
@set VERSION 2.13
@set UPDATED December 1998

@iftex
@finalout
@end iftex

@ifinfo
@format
START-INFO-DIR-ENTRY
* Autoconf-ja: (autoconf-ja).   Create source code configuration scripts.
END-INFO-DIR-ENTRY
@end format

Autoconf: Creating Automatic Configuration Scripts, by David MacKenzie.

This file documents the GNU Autoconf package for creating scripts to
configure source code packages using templates and an @code{m4} macro
package.

Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998 Free Software Foundation, Inc.

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

@titlepage
@title Autoconf
@subtitle Creating Automatic Configuration Scripts
@subtitle Edition @value{EDITION}, for Autoconf version @value{VERSION}
@subtitle @value{UPDATED}
@author by David MacKenzie and Ben Elliston
@c I think I've rewritten all of Noah and Roland's contributions by now.

@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1992, 93, 94, 95, 96, 98 Free Software Foundation, Inc.

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

@c Define an environment variable index.
@defcodeindex ev
@c Define an output variable index.
@defcodeindex ov
@c Define a CPP variable index.
@defcodeindex cv
@c Define a macro index that @@defmac doesn't write to.
@defcodeindex ma

@node Top, Introduction, (dir), (dir)
@comment  node-name,  next,  previous,  up

@ifinfo
このファイルは、GNU Autoconfパッケージの説明書です。
GNU Autoconfパッケージは、テンプレートと@code{m4}マクロパッケージを
用いて、ソースコードパッケージを自動設定するスクリプトを生成します。
説明書の版は@value{EDITION}で、Autoconfバージョン@value{VERSION}用のものです。

@end ifinfo

@c The master menu, created with texinfo-master-menu, goes here.

@menu
* Introduction::                Autoconfの目的、利点と欠点。
* Making configure Scripts::    Autoconfスクリプトの準備・作成方法。
* Setup::                       Initialization and output.
* Existing Tests::              Macros that check for particular features.
* Writing Tests::               How to write new feature checks.
* Results::                     What to do with results from feature checks.
* Writing Macros::              Adding new macros to Autoconf.
* Manual Configuration::        Selecting features that can't be guessed.
* Site Configuration::          Local defaults for @code{configure}.
* Invoking configure::          How to use the Autoconf output.
* Invoking config.status::      Recreating a configuration.
* Questions::                   Questions about Autoconf, with answers.
* Upgrading::                   Tips for upgrading from version 1.
* History::                     History of Autoconf.
* Old Macro Names::             Backward compatibility macros.
* Environment Variable Index::  Index of environment variables used.
* Output Variable Index::       Index of variables set in output files.
* Preprocessor Symbol Index::   Index of C preprocessor symbols defined.
* Macro Index::                 Index of Autoconf macros.

@detailmenu
 --- The Detailed Node Listing ---

Making @code{configure} Scripts

* Writing configure.in::        What to put in an Autoconf input file.
* Invoking autoscan::           Semi-automatic @file{configure.in} writing.
* Invoking ifnames::            Listing the conditionals in source code.
* Invoking autoconf::           How to create configuration scripts.
* Invoking autoreconf::         Remaking multiple @code{configure} scripts.

Initialization and Output Files

* Input::                       Where Autoconf should find files.
* Output::                      Creating output files.
* Makefile Substitutions::      Using output variables in @file{Makefile}s.
* Configuration Headers::       Creating a configuration header file.
* Subdirectories::              Configuring independent packages together.
* Default Prefix::              Changing the default installation prefix.
* Versions::                    Version numbers in @code{configure}.

Substitutions in Makefiles

* Preset Output Variables::     Output variables that are always set.
* Build Directories::           Supporting multiple concurrent compiles.
* Automatic Remaking::          Makefile rules for configuring.

Configuration Header Files

* Header Templates::            Input for the configuration headers.
* Invoking autoheader::         How to create configuration templates.

Existing Tests

* Alternative Programs::        Selecting between alternative programs.
* Libraries::                   Library archives that might be missing.
* Library Functions::           C library functions that might be missing.
* Header Files::                Header files that might be missing.
* Structures::                  Structures or members that might be missing.
* Typedefs::                    @code{typedef}s that might be missing.
* C Compiler Characteristics::  
* Fortran 77 Compiler Characteristics::  
* System Services::             Operating system services.
* UNIX Variants::               Special kludges for specific UNIX variants.

Alternative Programs

* Particular Programs::         Special handling to find certain programs.
* Generic Programs::            How to find other programs.

Library Functions

* Particular Functions::        Special handling to find certain functions.
* Generic Functions::           How to find other functions.

Header Files

* Particular Headers::          Special handling to find certain headers.
* Generic Headers::             How to find other headers.

Typedefs

* Particular Typedefs::         Special handling to find certain types.
* Generic Typedefs::            How to find other types.

Writing Tests

* Examining Declarations::      Detecting header files and declarations.
* Examining Syntax::            Detecting language syntax features.
* Examining Libraries::         Detecting functions and global variables.
* Run Time::                    Testing for run-time features.
* Portable Shell::              Shell script portability pitfalls.
* Testing Values and Files::    Checking strings and files.
* Multiple Cases::              Tests for several possible values.
* Language Choice::             Selecting which language to use for testing.

Checking Run Time Behavior

* Test Programs::               Running test programs.
* Guidelines::                  General rules for writing test programs.
* Test Functions::              Avoiding pitfalls in test programs.

Results of Tests

* Defining Symbols::            Defining C preprocessor symbols.
* Setting Output Variables::    Replacing variables in output files.
* Caching Results::             Speeding up subsequent @code{configure} runs.
* Printing Messages::           Notifying users of progress or problems.

Caching Results

* Cache Variable Names::        Shell variables used in caches.
* Cache Files::                 Files @code{configure} uses for caching.

Writing Macros

* Macro Definitions::           Basic format of an Autoconf macro.
* Macro Names::                 What to call your new macros.
* Quoting::                     Protecting macros from unwanted expansion.
* Dependencies Between Macros::  What to do when macros depend on other macros.

Dependencies Between Macros

* Prerequisite Macros::         Ensuring required information.
* Suggested Ordering::          Warning about possible ordering problems.
* Obsolete Macros::             Warning about old ways of doing things.

Manual Configuration

* Specifying Names::            Specifying the system type.
* Canonicalizing::              Getting the canonical system type.
* System Type Variables::       Variables containing the system type.
* Using System Type::           What to do with the system type.

Site Configuration

* External Software::           Working with other optional software.
* Package Options::             Selecting optional features.
* Site Details::                Configuring site details.
* Transforming Names::          Changing program names when installing.
* Site Defaults::               Giving @code{configure} local defaults.

Transforming Program Names When Installing

* Transformation Options::      @code{configure} options to transform names.
* Transformation Examples::     Sample uses of transforming names.
* Transformation Rules::        @file{Makefile} uses of transforming names.

Running @code{configure} Scripts

* Basic Installation::          Instructions for typical cases.
* Compilers and Options::       Selecting compilers and optimization.
* Multiple Architectures::      Compiling for multiple architectures at once.
* Installation Names::          Installing in different directories.
* Optional Features::           Selecting optional features.
* System Type::                 Specifying the system type.
* Sharing Defaults::            Setting site-wide defaults for @code{configure}.
* Operation Controls::          Changing how @code{configure} runs.

Questions About Autoconf

* Distributing::                Distributing @code{configure} scripts.
* Why GNU m4::                  Why not use the standard @code{m4}?
* Bootstrapping::               Autoconf and GNU @code{m4} require each other?
* Why Not Imake::               Why GNU uses @code{configure} instead of Imake.

Upgrading From Version 1

* Changed File Names::          Files you might rename.
* Changed Makefiles::           New things to put in @file{Makefile.in}.
* Changed Macros::              Macro calls you might replace.
* Invoking autoupdate::         Replacing old macro names in @code{configure.in}.
* Changed Results::             Changes in how to check test results.
* Changed Macro Writing::       Better ways to write your own macros.

History of Autoconf

* Genesis::                     Prehistory and naming of @code{configure}.
* Exodus::                      The plagues of @code{m4} and Perl.
* Leviticus::                   The priestly code of portability arrives.
* Numbers::                     Growth and contributors.
* Deuteronomy::                 Approaching the promises of easy configuration.

@end detailmenu
@end menu

@node Introduction, Making configure Scripts, Top, Top
@chapter Introduction

@display
物理学者、エンジニアとコンピュータ科学者が神の性質を論じていました。「確
かに物理学者だ」と物理学者が言いました。「なぜなら、創造の早いうちに神が
光を作った。ご存じのように、マックスウェル方程式、電磁波の二重の性質、相
対論者の結果@dots{}」。「エンジニアだ!」とエンジニアは言いました。「なぜ
なら、光を作る前に神はカオスを土地と水に分けた。それには大量のエンジニア
が必要で、大量の泥を処理し、液体から固体を正しく分離し@dots{}」。コンピュー
タ科学者は叫んだ。「そしてカオス、それはいったいどこからきたと思いますか。
ふーむ?」

---詠み人知らず
@end display
@c (via Franc,ois Pinard)

Autoconfは、各種UNIX系システムにあわせてソースコードパッケージを
設定(configure)するためのshellスクリプトを自動生成するツールです。
Autoconfによって生成された自動設定スクリプトは、実行されるときには
Autoconfとは独立に動きます。このため、自動設定スクリプトのユーザは
Autoconfを持っている必要がありません。

Autoconfによって生成される自動設定スクリプトは、ユーザの介入を
必要としません。普通はシステム種別を引数として指定する必要も
ありません。引数を求めたりするかわりに、ソフトウェアパッケージが使う
可能性のあるOSの機能が存在するかどうかがひとつづつチェックされます。
(各チェックの前に、何をチェックしているのかが1行メッセージとして
表示されます。このため、ユーザはスクリプトの実行を待っている間さほど
退屈せずにすみます)
結果として、ターゲットが通常のUNIX系のOSよりもカスタマイズされていたり、
(BSD系とSVR4系の)融合されたOSだったりしても、スクリプトはターゲットOSを
うまく扱うことができます。各々のUNIX系OSについて、どの機能がサポート
されているかをファイルに記録したりする必要はありません。

Autoconfは、Autoconfを用いる各ソフトウェアパッケージについて、
自動設定スクリプトを作成します。自動設定スクリプトは各パッケージが
必要とする、または用いることのできるOSの機能を並べた
テンプレートファイルから生成されます。
OSの機能を検出して反応するshellスクリプトが書けたなら、
Autoconfはそのshellスクリプトを複数のソフトウェアパッケージで
共有する機構を持っています。もし後でshellスクリプトを修正する
必要が生じた場合でも、定義を1箇所だけ変更すればいいようになっています。
各ソフトウェアパッケージの自動生成スクリプトを再生成すれば、
shellスクリプトへの修正が反映されます。

MetaconfigパッケージはAutoconfと似た目的をもっていますが、
Metaconfigによって生成されるスクリプトはユーザの介入を必要とし、
大きなソースツリーを設定する場合には不便です。
Metaconfigの生成するスクリプトと違い、Autoconfはクロスコンパイルの
設定も扱うことができます(設定ファイルを注意深く書けば)。

移植性の高いソフトウェアパッケージを作るためには、Autoconfの
してくれないことがいくつか必要になります。例えば、各ターゲット
プログラムのための@file{Makefile}の自動生成や、システムに欠けている
標準ライブラリ関数やヘッダファイルを補う、などです。これらを自動化
するための作業は現在進行中です。

Autoconfを使う場合、C言語のプログラムで@code{#ifdef}して使うシンボルの
名前に一部制限が生じます(@pxref{Preprocessor Symbol Index})。

Autoconfはスクリプトの生成のためにGNU @code{m4}を必要とします。
Autoconfは一部のUNIXについてくる@code{m4}にはない機能を使っています。
また、Autoconfは(GNU @code{m4} 1.0を含む)一部のバージョンの@code{m4}の
内部制限を越えてしまう場合があります。
Autoconfと一緒には、GNU @code{m4} 1.1以降を使う必要があります。
バージョン1.3あるいはそれ以降を使った場合、1.1や1.2を使う場合より
大幅に高速になります。

バージョン1からのアップグレードのためには@xref{Upgrading}を
参照してください。
Autoconfの開発経緯については@xref{History}を参照してください。
Autoconfに関する質問集は@xref{Questions}を参照してください。

Autoconfに関する御意見やバグレポートは
@code{bug-gnu-utils@@prep.ai.mit.edu}までmailでお寄せください。
Autoconfのバージョン番号を書くのを忘れずに。
バージョン番号は@samp{autoconf --version}で調べられます。

訳註: この和訳版は伊藤いとぢゅん純一郎 (@code{itojun@@itojun.org})に
よるものです。
訳し間違いがあっても、犬も食いません。
疑問点があったら、「必ず原文を参照する」ようにしてください。
再配布などについては原文に従います。

訳註: この和訳版のAutoconf version 2.12 -> 2.13 へのマージ作業を新井康司
@email{jca02266@@nifty.ne.jp}が行いました。一部、翻訳も行いました。訳が
おかしな所は新井の担当部分です@t{:-)}

@node Making configure Scripts, Setup, Introduction, Top
@chapter Making @code{configure} Scripts

Autoconfによって生成される自動設定スクリプトは、@code{configure}と
呼ばれることになってます。@code{configure}は実行されると、
設定パラメタを適切な値に書き換えながらいくつかのファイルを作成します。
@code{configure}が生成するファイルは以下のとおりです:

@itemize @bullet
@item
ひとつまたは複数(パッケージ中の各サブディレクトリ
にひとつづつ)の@file{Makefile}。
(@pxref{Makefile Substitutions})

@item
オプションで指定された場合、@code{#define}
ディレクティブを含むCヘッダファイル。
ファイル名は設定で変えられます。
(@pxref{Configuration Headers})

@item
@file{config.status}という名前のshellスクリプト。
このスクリプトを実行すると、上記のファイルが
再生成されます。
(@pxref{Invoking config.status})

@item
@file{config.cache}という名前のshellスクリプト。
たくさんのテスト結果を保存するファイルです。
(@pxref{Cache Files})

@item
コンパイラが出力したメッセージを記録する
@file{config.log}ファイル。
@code{configure}がうまく動かなかった場合の
デバッグに使います。
@end itemize

Autoconfを使って@code{configure}スクリプトを作成するためには、
Autoconfの入力ファイル@file{configure.in}を作り、@code{autoconf}を
実行する必要があります。Autoconfに標準でついてくるものを補うために、
OSの機能をチェックするための自作のshellスクリプトを書いた場合には、
それを@file{aclocal.m4}と@file{acsite.m4}に書いておくとよいでしょう。
@code{#define}ディレクティブを含むCヘッダファイルを使うなら、
@file{acconfig.h}を作成する必要があるかもしれません。
さらに、Autoconfの生成した@file{config.h.in}をパッケージとともに
配布することになります。

以下の図は、自動設定が行われるときにどのようにファイルが用いられる
のかを示しています。実行されるプログラム名には@samp{*}がつけてあります。
なくてもいいファイルは角カッコ(@samp{[]})でかこんであります。
@code{autoconf}と@code{autoheader}は、下図に加えてAutoconfマクロファイルを
読み込みます(@file{autoconf.m4}のことです)。

@noindent
配布用ソフトウェアパッケージの作成時に使われるファイル:
@example
@group
your source files --> [autoscan*] --> [configure.scan] --> configure.in

configure.in --.   .------> autoconf* -----> configure
               +---+
[aclocal.m4] --+   `---.
[acsite.m4] ---'       |
                       +--> [autoheader*] -> [config.h.in]
[acconfig.h] ----.     |
                 +-----'
[config.h.top] --+
[config.h.bot] --'

Makefile.in -------------------------------> Makefile.in
@end group
@end example

@noindent
ソフトウェアパッケージの設定時に使われるファイル:
@example
@group
                       .-------------> config.cache
configure* ------------+-------------> config.log
                       |
[config.h.in] -.       v            .-> [config.h] -.
               +--> config.status* -+               +--> make*
Makefile.in ---'                    `-> Makefile ---'
@end group
@end example

@menu
* Writing configure.in::        What to put in an Autoconf input file.
* Invoking autoscan::           Semi-automatic @file{configure.in} writing.
* Invoking ifnames::            Listing the conditionals in source code.
* Invoking autoconf::           How to create configuration scripts.
* Invoking autoreconf::         Remaking multiple @code{configure} scripts.
@end menu

@node Writing configure.in, Invoking autoscan, Making configure Scripts, Making configure Scripts
@section Writing @file{configure.in}

あるソフトウェアパッケージ用の@code{configure}スクリプトを
生成するためには、@file{configure.in}という名前のファイルを
作成する必要があります。このファイルには、ソフトウェアパッケージが
必要とする、または使う事のできるOSの機能をチェックするための
Autoconfマクロの呼出列が記述されます。
たくさんの機能をチェックするために、Autoconfマクロとして既に
たくさんのものが準備されています。@ref{Existing Tests}を
参照してください。
AutoconfマクロのないOSの機能でも、多くの場合には特製チェックルーチンを
作るのにAutoconfテンプレートマクロを使うことができます。
@ref{Writing Tests}を参照してください。
特にトリッキー、または特殊なOS機能のチェックをする場合、
@file{configure.in}に手でshellコマンド列を書かないといけないかも
しれません。
@code{autoscan}プログラムを使うと、@file{configure.in}を
書きはじめるための元ファイルを自動生成してくれます(より詳しくは
@pxref{Invoking autoscan}を参照)。

@file{configure.in}の中でAutoconfマクロを呼び出す順番は、一部の例外を
除けば重要ではありません。@file{configure.in}ファイルには@code{AC_INIT}
マクロの呼び出しが一番最初に、@code{AC_OUTPUT}マクロの呼び出しが
一番最後に入っている必要があります(@pxref{Output}参照)。
さらに、一部のマクロは先に呼ばれる他のマクロに依存しています。
先に呼ばれるマクロによって設定される値によって動作を変えるためです。
このようなマクロはそれぞれのマクロの説明に注意書きがしてあります
(@pxref{Existing Tests}参照)し、もし逆順に呼んだ場合、@code{configure}の
生成時に警告が出ます。

@file{configure.in}に統一性をもたせるため、以下の順でAutoconfマクロを
呼ぶことを推奨します。一般にいって、最後の方に書かれているものは
先にあるものに依存しています。例えば、ライブラリ関数のチェックは
typedefとライブラリファイルのチェック結果に依存します。

@display
@group
@code{AC_INIT(@var{file})}
checks for programs
checks for libraries
checks for header files
checks for typedefs
checks for structures
checks for compiler characteristics
checks for library functions
checks for system services
@code{AC_OUTPUT(@r{[}@var{file@dots{}}@r{]})}
@end group
@end display

@file{configure.in}に、1行にひとつづつマクロの呼び出しを記述することを
お勧めします。ほとんどのマクロは、余計な改行を生成しません。すなわち、
マクロ呼び出しの直後の改行があることに頼っています。
このようにすることで、余計な空行がなく、読みやすい@code{configure}
スクリプトを生成することができます。shell変数への代入を
マクロ呼び出しとおなじ行で行うのはたいていの場合安全です。
shellスクリプトでは代入文を改行をはさまず記入することができるからです。

引数をとるマクロを呼び出す場合、マクロ名と左括弧の間にスペースを
入れてはいけません。@code{m4}のquote文字@samp{[}と@samp{]}で
囲むことで、複数行にわたる引数を記述できます。ファイル名の羅列などで
長い行を書かないといけない場合、行末にbackslashを置くことで
論理的な行を続ける(backslashの次の改行を無視させる)ことができます。
これはshellによって実現されているもので、Autoconfが特別なことをしている
わけではありません。

マクロには場合分けを含んでいるものがあります: 条件が成立したときに
実行することがらと、条件が成立しなかったときに実行することがらを
記述するような場合です。条件が成立したときにはなにかを実行し、
成立しなかったときにはなにもしないようにしたい(あるいは逆)、ということが
あると思います。条件が成立したときになにもしない場合、マクロの
引数@var{action-if-found}に空文字列を渡してください。
条件が成立しなかったときになにもしない場合、マクロの引数
@var{action-if-not-found}を直前のカンマもろとも省略してください。

@file{configure.in}にはコメントを含めることができます。
コメントは@code{m4}組み込みマクロ@code{dnl}で始めます。
@code{dnl}マクロは次の改行までの文字列を単に無視します。
このようにして書かれたコメントは、@code{configure}スクリプトには現れません。
たとえば、@file{configure.in}を以下のような行ではじめれば
理解を助けることができるでしょう:

@example
dnl Process this file with autoconf to produce a configure script.
@end example

@node Invoking autoscan, Invoking ifnames, Writing configure.in, Making configure Scripts
@section Using @code{autoscan} to Create @file{configure.in}

@code{autoscan}プログラム、あるソフトウェアパッケージのための
@file{configure.in}を生成する際に役立ちます。@code{autoscan}は
コマンドライン引数で指定されたディレクトリ(指定されなかった場合
カレントディレクトリ)以下のソースファイルについて、移植性に
問題のある記述があるかどうかを探します。そして、結果を@file{configure.scan}
というファイルに出力します。このファイルはこのパッケージのための
@file{configure.in}の雛型として使えます。

@file{configure.scan}を@file{configure.in}にリネームする前に、
内容を確認する必要があります; たぶん手で調整が必要です。
@code{autoscan}の出力した@file{configure.scan}のマクロ列が、
マクロ間の依存関係からみて正しくない順で並んでいる場合があります。
このような場合、@code{autoconf}は警告を出力しますので、
マクロの順序を手で変更する必要があります。また、configuration header fileを
使いたい場合、@code{AC_CONFIG_HEADER}(@pxref{Configuration Headers})
マクロの呼び出しを追加する必要があります。さらに、プログラムが
Autoconfとうまく動くように、ソースコードの方に@code{#if}ディレクティブを
追加する必要があるでしょう(この作業を楽にするためのツールについては
@pxref{Invoking ifnames}を参照)。

@code{autoscan}はいくつかのデータファイルを使って、ソースファイルの中にある
シンボルをみつけたときに出力すべきマクロ名を決定します。
このファイルはAutoconfマクロファイルと一緒に配布され、全て
おなじフォーマットになっています。ファイルの各行はシンボル、スペース、
シンボルをみつけたときに出力するべきAutoconfのマクロ名、というふうに
なっています。@samp{#}で始まる行はコメントです。

@code{autoscan}はPerlがインストールされている場合にのみインストールされます。
@code{autoscan}のオプションには以下があります:

@table @code
@item --help
コマンドラインオプションの説明を出力して終了します。

@item --macrodir=@var{dir}
@evindex AC_MACRODIR
デフォルトのインストールディレクトリでなく、
ディレクトリ@var{dir}にある設定ファイルを
参照します。環境変数@code{AC_MACRODIR}を
設定しても同じ効果が得られます。
コマンドラインオプションは環境変数の設定より
優先されます。

@item --verbose
調べているファイルの名前と、みつけた重要そうな
シンボル名を表示します。出力されるメッセージ量は
膨大になる可能性があります。

@item --version
Autoconfのバージョン番号を出力して終了します。
@end table

@node Invoking ifnames, Invoking autoconf, Invoking autoscan, Making configure Scripts
@section Using @code{ifnames} to List Conditionals

@code{ifnames}はソフトウェアパッケージ用に@file{configure.in}を書くのを
支援します。@code{ifnames}は、パッケージ中のソースコードで
Cプリプロセッサの条件文(@samp{#if})に使われている識別子を出力します。
もし、パッケージが既に移植性を高めるように記述されている場合には、
@code{configure}でなにをチェックしないといけないか決めるのに使えます。
@code{autoscan}の出力を穴うめして@file{configure.in}を作成するのにも
役立ちます(@pxref{Invoking autoscan})。

@code{ifnames}はコマンドラインに指定されたCソースファイル(なにも
指定されなかったら標準入力)をチェックし、結果を標準出力に出力します。
結果は@code{#if}、@code{#elif}、@code{#ifdef}、または@code{#ifndef}
の各ディレクティブで使われている識別子をソートして出力します。
各行にはひとつの識別子と、その識別子を使っているファイル名をスペースで
区切ったものが出力されます。

@noindent
@code{ifnames}は以下のオプションを受け付けます:

@table @code
@item --help
@itemx -h
コマンドラインオプションの説明を出力して終了します。

@item --macrodir=@var{dir}
@itemx -m @var{dir}
@evindex AC_MACRODIR
デフォルトのインストールディレクトリでなく、
ディレクトリ@var{dir}にある設定ファイルを
参照します。環境変数@code{AC_MACRODIR}を
設定しても同じ効果が得られます。
コマンドラインオプションは環境変数の設定より
優先されます。

@item --version
Autoconfのバージョン番号を出力して終了します。
@end table

@node Invoking autoconf, Invoking autoreconf, Invoking ifnames, Making configure Scripts
@section Using @code{autoconf} to Create @code{configure}

@code{configure.in}から@code{configure}を生成するためには、
@code{autoconf}プログラムをコマンドライン引数なしで実行します。
@code{autoconf}は@file{configure.in}をAutoconfマクロを使って
@code{m4}マクロプロセッサに通します。@code{autoconf}にコマンドライン
引数を与えた場合、@file{configure.in}のかわりに引数で指定したファイルが
読み込まれ、結果は標準出力に出力されます(通常は@file{configure}に結果を
出力します)。@samp{-}をコマンドライン引数として指定した場合、
@file{configure.in}のかわりに標準入力を読み込み、設定スクリプトを
標準出力に出力します。

Autoconfマクロは複数のファイルで定義されます。
@code{autoconf}はAutoconfといっしょに配布されているマクロファイルを最初に
読み込みます。次に、Autoconfと一緒に配布されるマクロファイルとおなじ
ディレクトリにある、@file{acsite.m4}を読み込みます。
その次に、カレントディレクトリにある@file{aclocal.m4}を読み込みます。
各ファイルにはサイト単位の、またはパッケージ単位のAutoconfマクロ定義を
書いておくことができます(マクロの定義法については@pxref{Writing Macros}
参照)。同じマクロが@code{autoconf}が読み込むファイルのうち複数のファイルで
定義されていた場合、あとから読み込まれたものが有効になります。

@code{autoconf}は以下のオプションを受け付けます:

@table @code
@item --help
@itemx -h
コマンドラインオプションの説明を出力して終了します。

@item --localdir=@var{dir}
@itemx -l @var{dir}
@file{aclocal.m4}を探すとき、カレントディレクトリでなしに
ディレクトリ@var{dir}を探しにいきます。

@item --macrodir=@var{dir}
@itemx -m @var{dir}
@evindex AC_MACRODIR
デフォルトのインストールディレクトリでなく、
ディレクトリ@var{dir}にあるAutoconfマクロ
ファイルを参照します。環境変数@code{AC_MACRODIR}を
設定しても同じ効果が得られます。
コマンドラインオプションは環境変数の設定より
優先されます。

@item --version
Autoconfのバージョン番号を出力して終了します。
@end table

@node Invoking autoreconf,  , Invoking autoconf, Making configure Scripts
@section Using @code{autoreconf} to Update @code{configure} Scripts

Autoconfで生成された@code{configure}スクリプトがたくさんある場合、
@code{autoreconf}を使うと仕事量を減らせるかもしれません。
@code{autoreconf}は、カレントディレクトリ以下の@code{configure}スクリプトと
configuration headerテンプレートを、@code{autoconf}(と、必要なら
@code{autoheader})を繰り返し起動して再生成します。
デフォルトでは、@file{configure.in}と(もしあれば)@file{aclocal.m4}よりも
古いファイルのみを再生成します。ただし、これによって行われる作業は
必要最低限の作業とは限りません。これは、@code{autoheader}は出力ファイルの
内容が変化しなかったときにはファイルのタイムスタンプを変更しないためです。
新しいバージョンのAutoconfをインストールした場合、@code{autoreconf}に
@samp{--force}オプションを指定することで、@emph{全ての}ファイルを更新
させることができます。

@code{autoreconf}に、@samp{--macrodir=@var{dir}}または
@samp{--localdir=@var{dir}}のオプションを与えた場合、
これらは@code{autoreconf}から呼び出される@code{autoconf}や
@code{autoheader}に渡されます。その際、相対パス名は適切に調整されます。

@code{autoreconf}は同じディレクトリツリーの中で、(@file{aclocal.m4}と
@file{acconfig.h}を共有する)大きなパッケージの一部であるディレクトリと
(自身の@file{aclocal.m4}と@file{acconfig.h}をそれぞれ持つ)独立したパッケー
ジのディレクトリを両方持つことをサポートしません。もし@samp{--localdir} 
を使うならすべてが同じパッケージの一部であると仮定し、使わないなら、それ
ぞれのディレクトリは分割したパッケージであると仮定します。この制限は将来
なくなるかもしれません。

@file{Makefile}のルールで必要なときに@code{configure}スクリプトを
自動再生成させるためには@xref{Automatic Remaking}を参照してください。
この方法を使うとconfiguration headerテンプレートのタイムスタンプは
きちんと取り扱われますが、@samp{--macrodir=@var{dir}}や
@samp{--localdir=@var{dir}}は渡されません。

@noindent
@code{autoreconf}は以下のオプションを受け付けます:

@table @code
@item --help
@itemx -h
コマンドラインオプションの説明を出力して終了します。

@item --force
@itemx -f
@file{configure}スクリプトとconfiguration headerが
入力ファイルより新しい場合でも、これらの再生成を
行います。入力ファイルとは@file{configure.in}と、もし
存在すれば@file{aclocal.m4}のことです。

@item --localdir=@var{dir}
@itemx -l @var{dir}
@file{aclocal.m4}を探すとき、カレントディレクトリで
なしにディレクトリ@var{dir}を探しにいきます。
@file{autoheader}を呼び出す場合には、
@file{acconfig.h}を探すディレクトリも変わります。
@file{@var{file}.top}と@file{@var{file}.bot}に
ついては挙動は変わりません。

@item --macrodir=@var{dir}
@itemx -m @var{dir}
@evindex AC_MACRODIR
デフォルトのディレクトリでなく、ディレクトリ
@var{dir}にある Autoconfマクロファイルを参照します。
環境変数@code{AC_MACRODIR}を設定しても同じ効果が
得られます。コマンドラインオプションは環境変数の
設定より優先されます。

@item --verbose
@code{autoreconf}から@code{autoconf}(と、必要なら
@code{autoheader})を呼び出すディレクトリ名を表示します。

@item --version
Autoconfのバージョン番号を出力して終了します。
@end table

@node Setup, Existing Tests, Making configure Scripts, Top
@chapter Initialization and Output Files

Autoconfで生成された@code{configure}スクリプトは、初期化や結果出力の
ための情報を必要します。たとえば、パッケージのソースファイルは
どこにあるのかとか、どのような出力ファイルを生成すべきか、などです。
以下の節では、初期化と結果出力について説明します。

@menu
* Input::                       Where Autoconf should find files.
* Output::                      Creating output files.
* Makefile Substitutions::      Using output variables in @file{Makefile}s.
* Configuration Headers::       Creating a configuration header file.
* Subdirectories::              Configuring independent packages together.
* Default Prefix::              Changing the default installation prefix.
* Versions::                    Version numbers in @code{configure}.
@end menu

@node Input, Output, Setup, Setup
@section Finding @code{configure} Input

@code{configure}スクリプトは他の全てのマクロより先に、@code{AC_INIT}
マクロを呼び出さねばなりません。必ず呼び出されなければならないマクロは
@code{AC_INIT}と@code{AC_OUTPUT}だけです(@pxref{Output})。

@defmac AC_INIT (@var{unique-file-in-source-dir})
@maindex INIT
コマンドライン引数を処理し、ソースコードの置かれている
ディレクトリをみつけます。@var{unique-file-in-source-dir}は
パッケージのソースコードの置かれたディレクトリにある、
任意のファイルの名前です; @code{configure}は、指定された
ディレクトリにソースコードが実際あるかどうか、
そのファイルが存在するかどうかを調べることで判断します。
ときには、ユーザはコマンドラインオプション@samp{--srcdir}で
間違ったディレクトリを指定するかもしれません; この判定は、
安全のためのチェックです。詳しくは@xref{Invoking configure}を
参照してください。
@end defmac

手動で設定を行うパッケージや、@code{install}プログラムを
利用するパッケージでは、@code{AC_CONFIG_AUX_DIR}を使って、
@code{configure}に他のshellスクリプトがどこにあるかを
知らせる必要があるかもしれません。たいていはデフォルトで
調べにいく場所で正しいのですが。

@defmac AC_CONFIG_AUX_DIR(@var{dir})
@maindex CONFIG_AUX_DIR
ディレクトリ@var{dir}に格納されている
@file{install-sh}、@file{config.sub}、
@file{config.guess}、それからCygnus
@code{configure}スクリプトを利用することを
指定します。@var{dir}は絶対パス、または
@file{@var{srcdir}}からの相対パスで指定します。
デフォルトは@file{@var{srcdir}}または
@file{@var{srcdir}/..}または
@file{@var{srcdir}/../..}のうち、
@file{install-sh}が最初にみつかった場所です。
他のファイルの置き場所についてはチェックが
行われません。これは@code{AC_PROG_INSTALL}を
使っただけで他のファイルを配布しなければ
ならなくなるのを防ぐためです。
このマクロは@file{install.sh}もチェックしますが、
このファイル名はobsoleteです。なぜなら、
@file{Makefile}がない場合、@code{make}が組み込み
ルールを使って@file{install.sh}から@file{install}を
生成しようとするからです。
@end defmac

@node Output, Makefile Substitutions, Input, Setup
@section Creating Output Files

Autoconfで生成された@code{configure}スクリプトは、
最後に@code{AC_OUTPUT}を呼び出さねばなりません。
このマクロは、@file{Makefile}や他のファイルを自動設定結果にしたがって
生成します。@code{configure.in}に必ず含まれなければならない
マクロは、@code{AC_OUTPUT}の他には@code{AC_INIT}だけです(@pxref{Input})。

@defmac AC_OUTPUT (@r{[}@var{file}@dots{} @r{[}, @var{extra-cmds} @r{[}, @var{init-cmds}@r{]]]})
@maindex OUTPUT
出力ファイルを生成します。このマクロは
1度だけ、@file{configure.in}の末尾で
呼び出す必要があります。マクロの
引数@var{file}@dots{}は、スペースで
区切られた出力ファイル列です;
これは空でも構いません。
このマクロは、入力ファイルを
@file{@var{file}}へ出力変数の値を
置換しながらコピーすることで生成します。
入力ファイルの名前はデフォルトでは
@file{@var{file}.in}です。
@c もしファイルの内容が変化しない場合は、
@c タイムスタンプを保存するために置き換えを行いません。
出力変数の使い方については@xref{Makefile Substitutions}を
参照してください。出力変数を定めるためには、
@xref{Setting Output Variables}を参照してください。
このマクロは出力先のディレクトリがなければ
ディレクトリを作成します(が、さらに親のディレクトリは
作成されません)。通常、このマクロを使って生成する
ファイルは@file{Makefile}ですが、他のファイル、たとえば
@file{.gdbinit}を生成するのにも使えます。

@code{AC_CONFIG_HEADER}、@code{AC_LINK_FILES}、または
@code{AC_CONFIG_SUBDIRS}マクロが呼び出されていた場合、
@code{AC_OUTPUT}は各マクロの引数に指定されたファイルも
生成します。

たいてい、@code{AC_OUTPUT}は以下のように呼び出されます:
@example
AC_OUTPUT(Makefile src/Makefile man/Makefile X/Imakefile)
@end example

入力ファイルの名前は、@var{file}のあとにコロンをつけて、
そのあとに入力ファイル名を繋げることで変更できます。
たとえば:
@example
AC_OUTPUT(Makefile:templates/top.mk lib/Makefile:templates/lib.mk)
AC_OUTPUT(Makefile:templates/vars.mk:Makefile.in:templates/rules.mk)
@end example
こうすることで、ファイル名をMS-DOSでも使える
フォーマットにしたり、ファイルの前後に
メッセージ(訳註: boilerplate)をつけたり
することができます。

@var{extra-cmds}を指定した場合、指定された
コマンドは他の処理の後に実行されるように
@file{config.status}に追加されます。
@var{init-cmds}が指定された場合、それは
shell変数、コマンド、backslashの
置き換えが行われた後、@var{extra-cmds}の
直前に挿入されます。@var{init-cmds}を
使うことで、@code{configure}から
@var{extra-cmds}に変数を引き渡すことが
できます。@code{AC_OUTPUT_COMMANDS}マクロが
呼び出されていた場合、@code{AC_OUTPUT_COMMANDS}に
指定されたコマンドは、@code{AC_OUTPUT}に指定された
コマンドの直前に実行されます。
@end defmac

@defmac AC_OUTPUT_COMMANDS (@var{extra-cmds} @r{[}, @var{init-cmds}@r{]})
@file{config.status}の末尾で実行される
shellコマンドと、shellコマンド呼び出し前に
@code{configure}で行うべき変数初期化
手続きを指定します。このマクロは複数回呼び出しても
構いません。実用的でない例題はこんなかんじ:

@example
fubar=27
AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.], fubar=$fubar)
AC_OUTPUT_COMMANDS([echo this is another, extra, bit], [echo init bit])
@end example
@end defmac

@code{make}をサブディレクトリで実行する場合には、
変数@code{MAKE}を使って@code{make}を呼び出さねば
なりません。ほとんどの@code{make}では、変数
@code{MAKE}は@code{make}プログラムと与えられた
オプションに設定されます(が、多くの場合
コマンドラインでの変数値設定は含まれません)。
一部の古い@code{make}では、変数@code{MAKE}は
設定されません。以下のマクロを使うと、そのような
古い@code{make}でも変数@code{MAKE}を使うことができます。

@defmac AC_PROG_MAKE_SET
@maindex PROG_MAKE_SET
@code{make}が変数@code{MAKE}を設定しているなら、
変数@code{SET_MAKE}を空にします。
そうでない場合、@code{SET_MAKE}を@samp{MAKE=make}に
設定します。内部で@code{AC_SUBST}を
@code{SET_MAKE}を置換するように呼び出します。
@end defmac

このマクロを利用する場合、@code{MAKE}を利用する
各々の@code{Makefile.in}に以下のような行を置いてください:

@example
@@SET_MAKE@@
@end example

@node Makefile Substitutions, Configuration Headers, Output, Setup
@section Substitutions in Makefiles

配布パッケージの各サブディレクトリのうちでコンパイルやインストールが
必要なディレクトリには、@file{Makefile.in}を置きます。
@code{configure}は@file{Makefile.in}から@file{Makefile}を生成します。
@file{Makefile}を生成する際には、@code{configure}は単純な
変数置換を行います。これは、@file{Makefile.in}中に登場する
@samp{@@@var{variable}@@}を@code{configure}が求めた変数値で
置き換えることによって行われます。このようにして出力ファイルで
置換される変数のことを@dfn{output variables(出力変数)}と呼びます。
通常、出力変数は@code{configure}が設定するshell変数です。
@code{configure}にある変数値で置換を行わせる場合、変数名を
引数にしてマクロ@code{AC_SUBST}を呼び出す必要があります。
@code{AC_SUBST}の呼び出されていない変数については、
@samp{@@@var{variable}@@}はそのまま出力されます。
@code{AC_SUBST}を使って出力変数を決める方法については
@xref{Setting Output Variables}を参照してください。

@code{configure}スクリプトを用いるソフトウェアパッケージは、
@file{Makefile}ではなくて@file{Makefile.in}と一緒に配布される
必要があります; こうすれば、ユーザはコンパイルの前に必ず
@code{configure}スクリプトを実行して、各々のシステムにあわせた
設定を行うことになります。

@file{Makefile}に何かを書くことに関するより多くの情報のために
@xref{Makefile Conventions, , Makefile Conventions, standards, The
GNU Coding Standards}, を参照してください。

@menu
* Preset Output Variables::     Output variables that are always set.
* Build Directories::           Supporting multiple concurrent compiles.
* Automatic Remaking::          Makefile rules for configuring.
@end menu

@node Preset Output Variables, Build Directories, Makefile Substitutions, Makefile Substitutions
@subsection Preset Output Variables

Autoconfマクロでいくつかの出力変数が前もって設定されています。
Autoconfマクロの一部では、追加の出力変数を設定します。これについては
各マクロの説明のところで述べられています。
出力変数の完全なリストをみるには@xref{Output Variable Index}を
参照してください。前もって設定される出力変数の意味を以下に示します。
@samp{dir}で終る出力変数については、  @xref{Directory Variables, , Variables for Installation Directories,
standards, The GNU Coding Standards}, を参照してください。

@defvar bindir
@ovindex bindir
ユーザが実行する実行ファイルを格納するディレクトリです。
@end defvar

@defvar configure_input
@ovindex configure_input
「このファイルは@code{configure}によって
自動生成されました」というコメントと、
入力ファイル名を含んだコメント文字列です。
@code{AC_OUTPUT}は、生成する@file{Makefile}の
先頭に、この文字列を含むコメント行を
付け加えます。他のファイルについては、
この変数を各入力ファイル先頭のコメント
領域の中で参照しましょう。たとえば、
shellスクリプトである入力ファイルの先頭は
以下のようになります:

@example
#! /bin/sh
# @@configure_input@@
@end example

@noindent
また、この行を置いておくことで、ファイルを
編集するひとに@code{configure}を使って
処理しないといけない、ということを
思い出させることができます。
@end defvar

@defvar datadir
@ovindex datadir
読み込み専用のアーキテクチャ非依存の
データファイルを置くディレクトリ名です。
@end defvar

@defvar exec_prefix
@ovindex exec_prefix
アーキテクチャ依存のファイル名のプレフィックスです。
@end defvar

@defvar includedir
@ovindex includedir
Cヘッダファイルをインストールする先のディレクトリ名です。
@end defvar

@defvar infodir
@ovindex infodir
infoフォーマットのドキュメントをインストールする
先のディレクトリ名です。
@end defvar

@defvar libdir
@ovindex libdir
ライブラリファイルをインストールする先の
ディレクトリ名です。
@end defvar

@defvar libexecdir
@ovindex libexecdir
(ユーザからではなく)他の実行ファイルから呼び出される
実行ファイルをインストールする先のディレクトリ名です。
@end defvar

@defvar localstatedir
@ovindex localstatedir
各マシンごとの、変更可能なデータを格納するための
ディレクトリ名です(訳註: XXX)。
@end defvar

@defvar mandir
@ovindex mandir
manフォーマットのドキュメントをインストールする先の
トップディレクトリ名です。
@end defvar

@defvar oldincludedir
@ovindex oldincludedir
gcc以外のコンパイラ向けのCヘッダファイルを
インストールする先のディレクトリ名です。
@end defvar

@defvar prefix
@ovindex prefix
アーキテクチャ非依存のファイルをインストールする際の
ファイル名のプレフィックスです。
@end defvar

@defvar sbindir
@ovindex sbindir
システム管理者によって実行される実行ファイルを
インストールする先のディレクトリです。
@end defvar

@defvar sharedstatedir
@ovindex sharedstatedir
アーキテクチャ非依存の変更可能なデータを
インストールする先のディレクトリ名です。
@end defvar

@defvar srcdir
@ovindex srcdir
@file{Makefile}の処理すべきソースコードの入っている
ディレクトリ名です。
@end defvar

@defvar sysconfdir
@ovindex sysconfdir
読み込み専用のマシン単位のデータファイルを
インストールする先のディレクトリ名です。
@end defvar

@defvar top_srcdir
@ovindex top_srcdir
パッケージのトップディレクトリです。トップディレクトリでは、
@code{srcdir}とおなじです。
@end defvar

@defvar CFLAGS
@ovindex CFLAGS
Cコンパイラのデバッグ/最適化のための
オプションです。@code{configure}が
実行された環境で指定されていなかった場合、
@code{AC_PROG_CC}を呼び出したときの
デフォルト値(または、呼び出さなかったら空)が
設定されます。@code{configure}はこの変数の
値を使って、Cコンパイラの機能チェックのための
コンパイルを行います。
@end defvar

@defvar CPPFLAGS
@ovindex CPPFLAGS
CプリプロセッサとCコンパイラのための、
ヘッダファイル検索対象ディレクトリ
(@samp{-I@var{dir}})と、その他の
もろもろのオプションです。
もし@code{configure}が実行された
環境でこの変数が指定されなかった場合、
デフォルト値は空になります。
@code{configure}はこの変数の
値を使って、Cコンパイラの機能チェック
のためのコンパイル、または
プリプロセスを行います。
@end defvar

@defvar CXXFLAGS
@ovindex CXXFLAGS
C++コンパイラのデバッグ/最適化のための
オプションです。@code{configure}が
実行された環境で指定されていなかった場合、
@code{AC_PROG_CXX}を呼び出したときの
デフォルト値(または、呼び出さなかったら空)が
設定されます。@code{configure}はこの変数の
値を使って、C++コンパイラの機能チェックのための
コンパイルを行います。
@end defvar

@defvar FFLAGS
@ovindex FFLAGS
Fortran 77コンパイラのデバッグや最適化オプションです。もし
@code{configure}を実行するとき環境変数に設定されていなければ
@code{AC_PROG_F77}を呼ぶときにデフォルト値が設定されます。(または、
@code{AC_PROG_F77}を呼ばなければ空になります) @code{configure}はFortran
77 の特徴をテストするプログラムをコンパイルするときにこの変数を使用しま
す。
@end defvar

@defvar DEFS
@ovindex DEFS
Cコンパイラに渡す@samp{-D}オプションです。
@code{AC_CONFIG_HEADER}マクロが呼び出された
場合、@code{configure}は@samp{@@DEFS@@}を
@samp{-D}群でなく、@samp{-DHAVE_CONFIG_H}で
置き換えます(@pxref{Configuration Headers}
参照)。この変数は@code{configure}がテストを
行っている間は定義されません。出力ファイルを
生成するときにだけ定義されます。
既に行われてたテストの結果を参照する
場合には、@xref{Setting Output Variables}を
参照してください。
@end defvar

@defvar LDFLAGS
@ovindex LDFLAGS
リンカのためのstrip(@samp{-s})のためや
他のもろもろのためのオプションです。
@code{configure}が実行された環境で
指定されていなかった場合、
デフォルト値の空文字列が
設定されます。
@code{configure}はこの変数の値を
使って、Cコンパイラの機能チェックの
際のリンクを行います。
@end defvar

@defvar LIBS
@ovindex LIBS
リンカに渡す@samp{-l}オプションと
@samp{-L}です。
@end defvar

@node Build Directories, Automatic Remaking, Preset Output Variables, Makefile Substitutions
@subsection Build Directories

ソフトウェアパッケージを展開した単一のソースコードツリー上で、
同時に複数のアーキテクチャのためのコンパイルを行うことができます。
オブジェクトファイルは各アーキテクチャ別のディレクトリに格納されます。

このためには、@code{make}はソースコードをみつけるために
@code{make}変数@code{VPATH}を使用します。GNU @code{make}と
最近の@code{make}のほとんどはこの機能をサポートしています。
古い@code{make}は@code{VPATH}をサポートしていません;
古い@code{make}を使う場合、ソースコードとオブジェクトファイルは
同じディレクトリに置かれていなければなりません。

@code{VPATH}をサポートするために、各@file{Makefile.in}には
以下ような行が含まれている必要があります:

@example
srcdir = @@srcdir@@
VPATH = @@srcdir@@
@end example

@code{VPATH}を他の変数の値を使って設定しないでください(たとえば
@samp{VPATH = $(srcdir)}のように)。一部の@code{make}は@code{VPATH}の
値を設定する場合に変数置換を行います。

@code{configure}は@file{Makefile}を生成する際に、
@code{srcdir}を正しい値に設定し置換します。

@code{make}変数@code{$<}(@code{VPATH}を使ってみつけたソースディレクトリ中の
ファイルのパス名)は、暗黙的ルールの中以外では使わないでください
(暗黙的ルールとは、例えば@file{.c}ファイルから@file{.o}ファイルを
生成するための手順を定義する@samp{.c.o}のルールのことです)。
一部の@code{make}は明示的ルール(訳中: 暗黙的ルールでないルール)の中では、
@code{$<}定義しません; @code{$<}は空になります。

そのかわりに、@file{Makefile}に記述するコマンドラインはソースファイルを
@samp{$(srcdir)/}で始めるようにしてください。例えば:

@example
time.info: time.texinfo
        $(MAKEINFO) $(srcdir)/time.texinfo
@end example

@node Automatic Remaking,  , Build Directories, Makefile Substitutions
@subsection Automatic Remaking

以下に示すようなルールをトップレベルの@file{Makefile.in}に含めると、
設定ファイルを変更したら自動的に設定情報を更新させることができます。
この例題には@file{aclocal.m4}やconfiguration header fileのような、
使っても使わなくてもいいファイルが全て含まれています。
@file{Makefile.in}にルールを追加するときには、パッケージ中で
実際使わないものは省略してください。

@samp{$@{srcdir@}/}プレフィックスは@code{VPATH}の制限を回避するために
記述されています。

@file{config.h.in}と@file{config.h}の内容に変化がない場合、
これらのファイルのタイムスタンプは変わりません。
@file{stamp-}で始まる名前のファイルは、このせいで用いられています。
このようにすることで、余計な再設定を防ぐことができます。
この手法を使う場合、@code{make}が@file{config.h.in}が更新済みだと
思うように、@file{stamp-h.in}をパッケージの配布に含める必要があります。
古いBSD系のシステムでは、@code{touch}や他のファイルで空ファイルが
作成される場合、タイムスタンプが変わりません。
このため、逃げ道として@code{echo}を使っています。
@c @code{echo}のかわりに@code{date}を使うと、余計なCVSコンフリクトが
@c 発生します。

@example
@group
$@{srcdir@}/configure: configure.in aclocal.m4
        cd $@{srcdir@} && autoconf

# autoheader might not change config.h.in, so touch a stamp file.
$@{srcdir@}/config.h.in: stamp-h.in
$@{srcdir@}/stamp-h.in: configure.in aclocal.m4 acconfig.h \
    config.h.top config.h.bot
        cd $@{srcdir@} && autoheader
        echo timestamp > $@{srcdir@}/stamp-h.in

config.h: stamp-h
stamp-h: config.h.in config.status
        ./config.status

Makefile: Makefile.in config.status
        ./config.status

config.status: configure
        ./config.status --recheck
@end group
@end example

さらに、@samp{echo timestamp > stamp-h}を@code{AC_OUTPUT}の
引数@var{extra-cmds}に指定する必要があります。
@code{config.status}を実行したときに、@file{config.h}が更新されたという
ことがわかるようにするためです。@code{AC_OUTPUT}の詳細については
@xref{Output}を参照。

設定ファイルにまつわる依存関係については、@xref{Invoking config.status}を
参照。

@node Configuration Headers, Subdirectories, Makefile Substitutions, Setup
@section Configuration Header Files

パッケージの移植性テストで、Cプリプロセッサシンボルをいくつか以上
使う場合、コンパイラを起動するときのコマンドラインは、@samp{-D}オプションを
渡さなければならないので非常に長くなります。
この手法にはふたつの問題があります。まず@code{make}の出力を眺めて間違いを
みつけるのが難しくなります。もっと深刻なのは、一部のOSのコマンドライン
長の制限を越えてしまう可能性がある、ということです。
@samp{-D}オプションを使うかわりに、@code{configure}スクリプトは
@samp{#define}ディレクティブを含んだCヘッダファイルを生成することができます。
@code{AC_CONFIG_HEADER}マクロでこのような出力ファイルを選択します。
このマクロは@code{AC_INIT}の直後に呼び出す必要があります。

パッケージ中のソースコードでは、@samp{#include}ディレクティブを使って、
configuration header fileを他のどのヘッダファイルよりも前に
読み込む必要があります。
一番最初に読み込むのは、定義の一貫性を保つためです(例えば、@code{const}を
再定義するヘッダを先に読み込んだりしたら困ります)。
@samp{#include "config.h"}でなしに、@samp{#include <config.h>}を使い、
Cコンパイラに@samp{-I.}オプションを渡しましょう
(あるいは@samp{-I..}などと、@file{config.h}のあるディレクトリを
指定しましょう)。このようにすることで、ソースファイルのあるディレクトリに
@file{config.h}がある状態でも、他のビルドディレクトリを作成して
そちらの@file{config.h}を使ってパッケージをコンパイルすることができます
(訳註: 結構意訳)。

@defmac AC_CONFIG_HEADER (@var{header-to-create} @dots{})
@maindex CONFIG_HEADER
@cvindex HAVE_CONFIG_H
@code{AC_OUTPUT}にCプリプロセッサ向けの
@code{#define}ディレクティブ入りの
ファイルを作成させ、@samp{@@DEFS@@}を
(shell変数@code{DEFS}の値でなく)
@samp{-DHAVE_CONFIG_H}に置換させます。
出力ファイル名は@var{header-to-create}に、
スペースで区切って指定します。
通常、@var{header-to-create}に使う
ファイル名は@file{config.h}です。

もし@var{header-to-create}に指定された
ファイルが既に存在していて、@code{AC_OUTPUT}が
出力しようとしている内容と同じ内容だったら、
ファイルは更新されずそのままになります。
このようにすることで、パッケージの設定の
一部を変更したとき、@var{header-to-create}に
指定されたヘッダファイルに依存している
ファイルを余計に再コンパイルしなくて済みます。

通常、入力ファイルは
@file{@var{header-to-create}.in}という名前です;
が、もし名前を変えたい場合には
@var{header-to-create}にコロンで区切った
名前の列を繋げることで変えられます。
たとえば:
@example
AC_CONFIG_HEADER(defines.h:defines.hin)
AC_CONFIG_HEADER(defines.h:defs.pre:defines.h.in:defs.post)
@end example
@noindent
こうすることで、ファイル名をMS-DOSでも使える
フォーマットにしたり、ファイルの前後に
メッセージ(訳註: boilerplate)をつけたり
することができます。
@end defmac

@menu
* Header Templates::            Input for the configuration headers.
* Invoking autoheader::         How to create configuration templates.
@end menu

@node Header Templates, Invoking autoheader, Configuration Headers, Configuration Headers
@subsection Configuration Header Templates

配布パッケージには、ヘッダファイルのテンプレートを含める必要があります。
テンプレートは出力がこうあってほしいと思うとおりに書き、
コメントと、デフォルト値を含めた@code{#define}ディレクティブを
書いておく必要があります。
例えば、@file{configure.in}が以下のマクロ呼び出しを含んでいる場合:

@example
AC_CONFIG_HEADER(conf.h)
AC_CHECK_HEADERS(unistd.h)
@end example

@noindent
以下のような行が@file{conf.h.in}に含まれている必要があります。
@file{unistd.h}があるシステムでは、@code{configure}は
@samp{#define}の行の0を1に変えて出力します。ないシステムでは、
そのまま出力します。

@example
@group
/* Define as 1 if you have unistd.h.  */
#define HAVE_UNISTD_H 0
@end group
@end example

あなたのプログラムが@code{#if}でなく@code{#ifdef}で
設定オプションを調べている場合、入力ファイルにデフォルト値を設定する
@code{#define}の行を書くかわりに、@code{#undef}の行を書くことができます。
@file{unistd.h}があるシステムでは、@code{configure}は
2行目を@samp{#define HAVE_UNISTD_H 1}と書き換えます。
そうでないシステムでは、2行目をコメントアウトして出力します
(コメントアウトするのは、このシンボルがシステムで既に使われている
かもしれないからです)。

@example
@group
/* Define if you have unistd.h.  */
#undef HAVE_UNISTD_H
@end group
@end example

@node Invoking autoheader,  , Header Templates, Configuration Headers
@subsection Using @code{autoheader} to Create @file{config.h.in}

@code{autoheader}プログラムは、@code{configure}が使う
Cの@samp{#define}ディレクティブ入りのファイルを生成してくれます。
@file{configure.in}が@code{AC_CONFIG_HEADER(@var{file})}を
呼び出している場合、@code{autoheader}は@file{@var{file}.in}を
生成します。複数のファイルが指定されていたら、最初のファイル名を使います。
さもなくば、@code{autoheader}は@file{config.h.in}を生成します。

@code{autoheader}にコマンドライン引数を渡した場合、
入力として@file{configure.in}のかわりに指定されたファイルが使われ、
結果は(@file{config.h.in}でなく)標準出力に出力されます。
@code{autoheader}に@samp{-}をコマンドライン引数として渡すと、
(@file{configure.in}のかわりに)標準入力が読み込まれ、
結果は標準出力に出力されます。

@code{autoheader}は@file{configure.in}を調べ、どんなCプリプロセッサシンボルが
定義される可能性があるか推測します。そして、
@file{acconfig.h}というファイルからコメントと@code{#define}または
@code{#undef}の行をコピーします。
上記の@file{acconfig.h}はAutoconfと一緒に配布され、所定の場所にインストール
されているものです。
カレントディレクトリにも@file{acconfig.h}がある場合、こちらも使われます。
@code{AC_DEFINE}マクロで標準以外のシンボルを定義している場合、
それらのシンボルのぶんのエントリをカレントディレクトリの@file{acconfig.h}に
造っておく必要があります。
@code{AC_CHECK_HEADERS}、@code{AC_CHECK_FUNCS}、@code{AC_CHECK_SIZEOF}、
または@code{AC_CHECK_LIB}で定義されるシンボルについては、
(@file{acconfig.h}から定義をコピーするのではなく)
@code{autoheader}がコメントと@code{#undef}の行を自動生成します。
なぜなら、これらのマクロで使われる可能性のあるシンボルは事実上無限に
あるからです。

@code{autoheader}の生成したファイルは、主に@code{#define}または
@code{#undef}と、付随するコメントからなります。
@file{./acconfig.h}に@samp{@@TOP@@}という文字列があった場合、
@code{autoheader}は@samp{@@TOP@@}を含む行以前の行を
出力の先頭にコピーします。
同様に、@file{./acconfig.h}に@samp{@@BOTTOM@@}という文字列があった場合、
@code{autoheader}は@samp{@@BOTTOM@@}を含む行以降の行を
出力の末尾にコピーします。
どちらの文字列もなくても構いません。

@file{@var{file}.top}(通常@file{config.h.top}になります)や
@file{@var{file}.bot}という名前のファイルをカレントディレクトリに
作っておくと、同様の効果が得られます。
もしファイルがあった場合、@code{autoheader}はファイルの内容を
出力の先頭(または末尾)にコピーします。
これらのファイルを使うのはおすすめしません。
なぜなら、これらのファイル名はMS-DOSファイルシステムに格納できないからです;
また、2つのファイルを置くことでディレクトリがごちゃごちゃします。
でも利点もあります。
他のディレクトリにある@file{acconfig.h}を読み込むために
@code{autoheader}の@samp{--localdir=@var{dir}}オプションを使う場合には、
これら2つのファイルを使うと全ての出力ファイルに別々のメッセージ
(訳註: boilerplate)をつけることができます。

@code{autoheader}は以下のオプションを受け付けます:

@table @code
@item --help
@itemx -h
コマンドラインオプションの説明を出力して終了します。

@item --localdir=@var{dir}
@itemx -l @var{dir}
@file{aclocal.m4}や@file{acconfig.h}を
探すとき、カレントディレクトリでなしに
ディレクトリ@var{dir}を探しにいきます。
@file{autoheader}を呼び出す場合には、
@file{@var{file}.top}と@file{@var{file}.bot}に
ついては挙動は変わりません。

@item --macrodir=@var{dir}
@itemx -m @var{dir}
@evindex AC_MACRODIR
デフォルトのディレクトリでなく、ディレクトリ
@var{dir}にある@file{acconfig.h}を参照します。
環境変数@code{AC_MACRODIR}を設定しても同じ効果が
得られます。コマンドラインオプションは環境変数の
設定より優先されます。

@item --version
Autoconfのバージョン番号を出力して終了します。
@end table

@node Subdirectories, Default Prefix, Configuration Headers, Setup
@section Configuring Other Packages in Subdirectories

ほとんどの場合、サブディレクトリに@file{Makefile}を作るには
@code{AC_OUTPUT}を使えば十分です。
しかし、複数の独立したパッケージを制御する@code{configure}
スクリプトを作る場合には、@code{AC_CONFIG_SUBDIRS}を使うことで
サブディレクトリにある@code{configure}スクリプトを呼び出すことができます。

@defmac AC_CONFIG_SUBDIRS (@var{dir} @dots{})
@maindex CONFIG_SUBDIRS
@ovindex subdirs
@code{AC_OUTPUT}マクロに、
@var{dir}に指定されたディレクトリ
にある@code{configure}を実行させます。
ディレクトリが複数の場合は@var{dir}に
ディレクトリをスペースで区切って並べます。
ディレクトリ@var{dir}がみつからない場合、
エラーにはなりません。これは、
@code{configure}大きなソースコード
ツリーのうちの実在する一部分だけを
設定できるようにするためです。
@var{dir}に@file{configure.in}があって
@file{configure}がない場合、Cygnus
ディレクトリ@code{AC_CONFIG_AUXDIR}にある
Cygnus @code{configure}スクリプトが
使われます。

サブディレクトリにある@code{configure}
スクリプトには、現在実行中の
@code{configure}スクリプトと、
基本的には同じコマンドライン引数が
渡されます。
コマンドライン引数は必要な場合には
わずかに変更されます(例えば、
キャッシュファイルやソースファイルの
あるディレクトリへの相対パスの調整など)。
このマクロは出力変数@code{subdirs}に、
サブディレクトリのリスト(@var{dir} @dots{})
を設定します。@file{Makefile}ルールでは
この変数を使って、どのサブディレクトリを
再帰的に@code{make}すればいいのか決める
ことができます。このマクロは複数回
呼び出しても構いません。
@end defmac

@node Default Prefix, Versions, Subdirectories, Setup
@section Default Prefix

デフォルトでは、@code{configure}はインストールのためのファイル名の
ディレクトリプレフィクスを@file{/usr/local}に設定します。@code{configure}の
ユーザは、@samp{--prefix}と@samp{--exec-prefix}オプションを使って、
他のディレクトリプレフィクスを選択することができます。
デフォルトの設定を変更するにはふたつの方法があります:
@code{configure}生成時と、@code{configure}の実行時です。

一部のソフトウェアパッケージでは、デフォルトで@file{/usr/local}以外のところに
インストールしたい場合があるでしょう。このためには、
@code{AC_PREFIX_DEFAULT}マクロを使ってください。

@defmac AC_PREFIX_DEFAULT (@var{prefix})
デフォルトのインストールディレクトリ
プレフィクスを、@file{/usr/local}
でなく@var{prefix}にします。
@end defmac

@code{configure}スクリプトが、既にインストールされている
関係あるプログラムのインストール位置から、
インストールディレクトリプレフィクスを推測してくれると
便利なこともあるでしょう。このためには、@code{AC_PREFIX_PROGRAM}を
呼び出しましょう。

@defmac AC_PREFIX_PROGRAM (@var{program})
@maindex PREFIX_PROGRAM
ユーザがインストールディレクトリ
プレフィクスを(@samp{--prefix}オプションで)
指定しなかった場合、値を@var{program}の
位置から推測します。@var{program}は
shellと同様、@code{PATH}をたぐって
探されます。もし@var{program}が
@code{PATH}に書かれたディレクトリの
どこかに存在した場合、ディレクトリ
プレフィクスを@var{program}のある
ディレクトリの親ディレクトリに
設定します; もしなかったら、
@file{Makefile.in}に指定された
プレフィクスをそのままにします。
例えば、@var{program}が@code{gcc}で、
@code{PATH}を探した結果
@file{/usr/local/gnu/bin/gcc}が
見つかった場合、プレフィクスは
@file{/usr/local/gnu}になります。
@end defmac

@node Versions,  , Default Prefix, Setup
@section Version Numbers in @code{configure}

以下のマクロは@code{configure}スクリプトのバージョン番号を管理します。
このマクロは使っても使わなくても構いません。

@defmac AC_PREREQ (@var{version})
@maindex PREREQ
Autoconfの十分最近のバージョンが
使われているか確かめます。
@code{configure}を生成するのに
使われているAutoconfが@var{version}
以前のものだった場合、エラーメッセージを
標準エラー出力に出力し、@code{configure}を
生成しません。例えば:

@example
AC_PREREQ(1.8)
@end example

このマクロは、@file{configure.in}が、
Autoconfのバージョンアップで変化した
自明でないふるまいに依存している場合に
役立ちます。もし最近定義されたマクロが
必要なだけの場合、@code{AC_PREREQ}マクロは
あまり使いでがありません。なぜなら、
@code{autoconf}はAutoconfの
ユーザに、マクロがないというエラーを
出力しているはずだからです。
同様のことは、@file{cofigure.in}を
@code{AC_PREREQ}が追加される以前の
Autoconfに通したときに起こります。
@end defmac

@defmac AC_REVISION (@var{revision-info})
@maindex REVISION
@var{revision-info}に指定したRCS
リビジョンスタンプ(訳註: @samp{$}@samp{Id $}
とかのこと)を、@samp{$}マークや
ダブルクォートを取り除いてから
@code{configure}スクリプトに埋め込みます。
このマクロを使って@file{configure.in}の
リビジョンスタンプ@code{configure}スクリプトに
取り込むと、RCS/CVSによって
@code{configure}内のリビジョンスタンプを
書き換えられずに済みます。
このようにすれば、@code{configure}
スクリプトがどのリビジョンの
@file{configure.in}から生成されたかを
簡単に知ることができます。

このマクロを@code{AC_INIT}以前に
使うようにすると、リビジョン番号が
@file{configure.in}と@code{configure}の
どちらでも先頭部分に入るので、
具合がよいです。
このように使われることを想定して、
@code{AC_REVISION}の出力は
@samp{#! /bin/sh}という行ではじまります。
これは通常の@code{configure}の
始まり方と同じです。

例えば、@file{configure.in}中の以下のような行は:

@c The asis prevents RCS from changing the example in the manual.
@example
AC_REVISION($@asis{Revision: 1.30 }$)dnl
@end example

@noindent
@code{configure}に以下のような出力を生成します:

@example
#! /bin/sh
# From configure.in Revision: 1.30
@end example
@end defmac

@node Existing Tests, Writing Tests, Setup, Top
@chapter Existing Tests

以下のマクロは、パッケージが必要な、あるいは使いたい特定のOSの機能を
調べます。以下のマクロに定義されていない機能の有無をチェックしたい場合、
基本テストマクロ(primitive test macro)に適切な引数を渡してチェックを
実現することになります(@pxref{Writing Tests}参照)。

以下のテストは、どの機能をチェックしているか、なにがわかったかを
知らせるメッセージを出力します。チェック結果は@code{configure}を
再度実行したときのためにキャッシュされます(@pxref{Caching Results}参照)。

マクロには出力変数を設定するものがあります。出力変数の値を
参照するやりかたについては@xref{Makefile Substitutions}を参照してください。
以下で、「@var{name}を定義します」という文は、
「Cプリプロセッサシンボル@var{name}を1に定義します」という意味です。
定義された値をプログラム中で参照するやりかたについては@xref{Defining Symbols}
を参照してください。

@menu
* Alternative Programs::        Selecting between alternative programs.
* Libraries::                   Library archives that might be missing.
* Library Functions::           C library functions that might be missing.
* Header Files::                Header files that might be missing.
* Structures::                  Structures or members that might be missing.
* Typedefs::                    @code{typedef}s that might be missing.
* C Compiler Characteristics::  
* Fortran 77 Compiler Characteristics::  
* System Services::             Operating system services.
* UNIX Variants::               Special kludges for specific UNIX variants.
@end menu

@node Alternative Programs, Libraries, Existing Tests, Existing Tests
@section Alternative Programs

以下のマクロは特定のプログラムの有無、またはふるまいをチェックします。
マクロは、いくつかの候補となるプログラムからどれかひとつを選んだり、
選んだものをどう利用するかを定めるために使われます。
パッケージで使うプログラム専用のマクロが定義されておらず、
そのプログラムに関する特殊なチェックが必要ない場合、
汎用のマクロのうちいずれかを利用することができます。

@menu
* Particular Programs::         Special handling to find certain programs.
* Generic Programs::            How to find other programs.
@end menu

@node Particular Programs, Generic Programs, Alternative Programs, Alternative Programs
@subsection Particular Program Checks

以下のマクロは特定のプログラムをチェックします---
プログラムが存在するかどうか、およびいくつかのプログラムについては
プログラム特有の機能をチェックします。

@defmac AC_DECL_YYTEXT
@maindex DECL_YYTEXT
@cvindex YYTEXT_POINTER
@ovindex LEX_OUTPUT_ROOT
@code{yytext}の型が@samp{char []}でなく
@samp{char *}だった場合、
@code{YYTEXT_POINTER}を定義します。
また、@code{lex}の出力ファイル名を
出力変数@code{LEX_OUTPUT_ROOT}に
定義します。通常は@file{lex.yy}ですが
他の値のこともあります。これらの結果は
@code{lex}と@code{flex}のどちらが
利用されているかによって変わります。
@end defmac

@defmac AC_PROG_AWK
@maindex PROG_AWK
@ovindex AWK
@code{mawk}、@code{gawk}、@code{nawk}、
@code{awk}があるかどうかをこの順序で
調べ、出力変数@code{AWK}の値を
最初にみつけたプログラムの
名前に設定します。@code{mawk}を最初に
調べるのは、これが一番高速動作する
実装だと言われているからです。
@end defmac

@defmac AC_PROG_CC
@maindex PROG_CC
@ovindex CC
@ovindex CFLAGS
利用するCコンパイラを決定します。
環境変数@code{CC}が設定されて
いなかったら、@code{gcc}があるか
どうか調べ、なければ@code{cc}を
使います。出力変数@code{CC}を
みつけたコンパイラの名前に設定します。

このマクロは、GNU Cコンパイラを使う場合
shell変数@code{GCC}を@samp{yes}に、
そうでない場合空に設定します。
もし出力変数@code{CFLAGS}がまだ
設定されていなかったら、
GNU Cコンパイラの場合には
@samp{-g -O2}に設定します
(GCCが@samp{-g}を受け付けない場合
@samp{-O2}に、他のコンパイラの場合
@samp{-g}に設定します)。

現在利用することになっている
Cコンパイラが、@code{configure}が
実行されているシステム以外のための
バイナリを生成する場合、
shell変数@code{cross_compiling}を
@samp{yes}に設定します。
そうでない場合@samp{no}に設定します。
言い替えれば、このテストは
build対象のシステムが
ホストシステムタイプ(訳註:
コンパイルを行うシステムのタイプ)と
異なるかどうかを調べます
(「ターゲットシステムタイプ」は
このマクロとは無関係です)。
クロスコンパイルのサポートに
ついては@xref{Manual Configuration}を
参照してください。
@end defmac

@defmac AC_PROG_CC_C_O
@maindex PROG_CC_C_O
@cvindex NO_MINUS_C_MINUS_O
Cコンパイラがコマンドラインオプション
@samp{-c}と@samp{-o}を
同時に受け付けない場合、
@code{NO_MINUS_C_MINUS_O}を定義します。
@end defmac

@defmac AC_PROG_CPP
@maindex PROG_CPP
@ovindex CPP
出力変数@code{CPP}に、Cプリプロセッサを
実行するためのコマンド名を定義します。
@samp{$CC -E}が動かない場合、
@file{/lib/cpp}が使われます。
@code{CPP}を@file{.c}ファイル以外に
用いるのは移植性がありません。
移植性のために、@code{CPP}に通すのは
拡張子が@file{.c}のファイルだけにしましょう。

現在選択されている言語がCの場合
(@pxref{Language Choice}参照)、
一部のテストマクロは出力変数@code{CPP}の
値を間接的に利用しています。
「間接的に」というのは、テストマクロ内部でマクロ
@code{AC_TRY_CPP}、@code{AC_CHECK_HEADER}、
@code{AC_EGREP_HEADER}、@code{AC_EGREP_CPP}を
呼び出しているからです。
@end defmac

@defmac AC_PROG_CXX
@maindex PROG_CXX
@ovindex CXX
@ovindex CXXFLAGS
利用するC++コンパイラを判別します。
環境変数@code{CXX}または@code{CCC}が
定義されていないか(@code{CXX}を先に)
調べます;
もし定義されていたら、定義されている値を
出力変数@code{CXX}にセットします。
さもなくば、C++コンパイラらしい名前の
プログラムを探します
(@code{c++}, @code{g++}, @code{gcc}, @code{CC},
@code{cxx}, それから@code{cc++})。
もし以上のチェックが全て失敗したら、
最後の手段として@code{CXX}を@code{gcc}にセットします。

GNU C++コンパイラを利用する場合、
shell変数@code{GXX}を@samp{yes}に、
さもなくば空にセットします。
出力変数@code{CXXFLAGS}がまだ定義されて
いない場合、@code{CXXFLAGS}を定義します。
GNU C++コンパイラを
利用するなら@samp{-g -O2}(GNU C++が
@samp{-g}を受け付けない場合@samp{-O2})に、
他のコンパイラの場合は@samp{-g}になります。

現在利用することになっている
C++コンパイラが、@code{configure}が
実行されているシステム以外のための
バイナリを生成する場合、
shell変数@code{cross_compiling}を
@samp{yes}に設定します。
そうでない場合@samp{no}に設定します。
言い替えれば、このテストは
build対象のシステムが
ホストシステムタイプ(訳註:
コンパイルを行うシステムのタイプ)と
異なるかどうかを調べます
(「ターゲットシステムタイプ」は
このマクロとは無関係です)。
クロスコンパイルのサポートに
ついては@xref{Manual Configuration}を
参照してください。
@end defmac

@defmac AC_PROG_CXXCPP
@maindex PROG_CXXCPP
@ovindex CXXCPP
出力変数@code{CXXCPP}に、C++プリプロセッサを
実行するためのコマンド名を定義します。
@samp{$CXX -E}が動かない場合、
@file{/lib/cpp}が使われます。
@code{CXXCPP}を@file{.c}、@file{.C}
または@file{.cc}以外のファイルに
用いるのは移植性がありません。
移植性のために、@code{CPP}に通すのは
上記に挙げた拡張子をもつファイルだけにしましょう。

現在選択されている言語がC++の場合
(@pxref{Language Choice}参照)、
一部のテストマクロは出力変数@code{CXXCPP}の
値を間接的に利用しています。
「間接的に」というのは、テストマクロ内部でマクロ
@code{AC_TRY_CPP}、@code{AC_CHECK_HEADER}、
@code{AC_EGREP_HEADER}、@code{AC_EGREP_CPP}を
呼び出しているからです。
@end defmac

@defmac  AC_PROG_F77
@maindex PROG_FORTRAN
@ovindex F77
@ovindex FFLAGS
利用するFortran 77コンパイラを決定します。環境変数@code{F77}が設定されて
いなかったら、@code{g77}、@code{f77} そして @code{f2c}を
この順番で調べます。出力変数@code{F77}をみつけたコンパイラの名前に設定し
ます。

@code{g77}(GNU Fortran 77コンパイラ)を使う場合@code{AC_PROG_F77}はshell 
変数@code{G77}を@samp{yes}に、そうでない場合空に設定します。もし出力変数
@code{FFLAGS}がその環境でまだ設定されていなかったら、@code{g77}の場合に
は@samp{-g -02}を(@code{g77}が@samp{-g}を受け付けない場合@samp{-O2}に設
定します)、他のコンパイラの場合@samp{-g}に@code{FFLAGS}を設定します
@end defmac

@defmac AC_PROG_F77_C_O
@maindex PROG_F77_C_O
@cvindex F77_NO_MINUS_C_MINUS_O
Fortran 77コンパイラがオプション@samp{-c}と@samp{-o}を同時に受け付けるか
どうかテストします。もし受け付けなければ@code{F77_NO_MINUS_C_MINUS_O} を
定義します。
@end defmac

@defmac AC_PROG_GCC_TRADITIONAL
@maindex PROG_GCC_TRADITIONAL
@ovindex CC
GNU Cコンパイラを使っていて、
@samp{-traditional}フラグを指定しないと
@code{ioctl}がうまく動かない場合、
出力変数@code{CC}に@samp{-traditional}を
付け加えます。
通常、これはGNU Cコンパイラ用に修正された
ヘッダファイルがインストールされていない
古いシステムで起こります。
GNU Cコンパイラの最近のバージョンでは、
インストール時にヘッダファイルを修正するので、
この問題は起きなくなってきました。
@end defmac

@defmac AC_PROG_INSTALL
@maindex PROG_INSTALL
@ovindex INSTALL
@ovindex INSTALL_PROGRAM
@ovindex INSTALL_DATA
@ovindex INSTALL_SCRIPT
現在の@code{PATH}上にBSD互換の
@code{install}プログラムがあった場合、
出力変数@code{INSTALL}をその名前にセットします。
さもなくば、@samp{@var{dir}/instal-sh -c}を
セットします。
後者の場合、@code{AC_CONFIG_AUX_DIR}に
指定されたディレクトリ(またはデフォルトの
ディレクトリ)を使って@var{dir}を決定します
(@pxref{Output})。
さらに、@code{INSTALL_PROGRAM}と@code{INSTALL_SCRIPT}を@samp{$@{INSTALL@}}に、
@code{INSTALL_DATA}を@samp{$@{INSTALL@} -m 644}にセットします。

このマクロは、うまく動作しない
@code{install}プログラムを無視します。
プログラムを探す際には、速度のためにスクリプトよりは
Cで書かれたプログラムの方を優先します。
@file{install-sh}以外に、@file{install.sh}を
使うこともできますが、@file{install.sh}という
ファイル名はobsoleteなので使わない方がいいでしょう(訳註: 意訳)。
これは、
一部の@code{make}が、@file{Makefile}がないときに
@file{install.sh}から@file{install}を生成する
ルールをもっているためです。

パッケージに含める(訳註: 意訳)
@file{install-sh}としては、
Autoconfと一緒に配布されている@file{install-sh}を
利用することができます。
@code{AC_PROG_INSTALL}を利用した場合、
@file{install-sh}または@file{install.sh}を
配布に含める必要があります。
含めなかった場合、@code{configure}は
ファイルがみつからなかった旨
エラーメッセージを出力します。
エラーメッセージは正しく動作する
@code{install}がある場合にも出力されます。
このチェックは、@code{install-sh}を
パッケージに含め忘れないための安全策です。
含め忘れた場合、あなたのパッケージを
BSD互換の@code{install}プログラムのない
システムでインストールできなくなってしまいます。

標準的な@code{install}プログラムにない機能が
必要で独自のインストールプログラムを利用したい
場合には、@code{AC_PROG_INSTALL}を利用する
必要はありません; 御自分のインストールプログラムへの
パス名を@file{Makefile.in}に単に含めればいいのです。
@end defmac

@defmac AC_PROG_LEX
@maindex PROG_LEX
@ovindex LEX
@ovindex LEXLIB
@code{flex}があったら、出力変数@code{LEX}を
@samp{flex}に、(もし@samp{libfl.a}が
標準的な場所にあったら)@code{LEXLIB}を
@samp{-lfl}に設定します。
もし@code{flex}がなかったら、
@code{LEX}を@samp{lex}に、
@code{LEXLIB}を@samp{-ll}に設定します。
@end defmac

@defmac AC_PROG_LN_S
@maindex PROG_LN_S
@ovindex LN_S
@samp{ln -s}が現在のファイルシステムで
うまく使えたら(すなわち、OSとファイルシステムが
シンボリックリンクをサポートしていたら)、
出力変数@code{LN_S}を@samp{ln -s}に設定します。
動かなかったら、@samp{ln}に設定します。

カレントディレクトリ以外のパス名をリンク先として
指定した場合、@samp{ln}と@samp{ln -s}では
意味が異なってきます。
@samp{$(LN_S)}を使って安全にリンクを作成するためには、
makefile中でどちらが使われているか調べて動作を変えるか、
@code{ln}コマンドをリンクが置かれるディレクトリで
呼び出すかのいずれかを行わねばなりません。

言い替えれば、以下はうまく動きません:
@example
$(LN_S) foo /x/bar
@end example

ので、かわりにこうしましょう:
@example
(cd /x && $(LN_S) foo bar)
@end example
@end defmac

@defmac AC_PROG_RANLIB
@maindex PROG_RANLIB
@ovindex RANLIB
もし@code{ranlib}がみつかったら、出力変数
@code{RANLIB}を@samp{ranlib}に設定します。
さもなくば、@code{:}(なにもしない)に設定します。
@end defmac

@defmac AC_PROG_YACC
@maindex PROG_YACC
@ovindex YACC
もし@code{bison}がみつかったら、出力変数
@code{YACC}を@samp{bison -y}に設定します。
かわりに@code{byacc}がみつかったら、出力変数
@code{YACC}を@samp{byacc}に設定します。
さもなくば、@code{yacc}に設定します。
@end defmac

@node Generic Programs,  , Particular Programs, Alternative Programs
@subsection Generic Program and File Checks

以下のマクロは、プログラムをみつけるための専用マクロが特に
定義されていないプログラムをみつけるために使われます。
プログラムの存在だけでなくプログラムの挙動を調べたい場合、
自分でテストスクリプトを記述する必要があります(@pxref{Writing Tests})。
デフォルトでは、マクロは環境変数@code{PATH}を使います。
ユーザの@code{PATH}にないようなプログラムをチェックする場合、
以下のように自分でサーチパスを変更してマクロに渡すことができます:

@example
AC_PATH_PROG(INETD, inetd, /usr/libexec/inetd,
  $PATH:/usr/libexec:/usr/sbin:/usr/etc:etc)
@end example

@defmac AC_CHECK_FILE (@var{file} @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex CHECK_FILE
ファイル@var{file}がシステムに存在するかどうかを検査します。
もしみつかれば@var{action-if-found}が実行され、みつからなければ
(もし与えられていれば)@var{action-if-not-found}が実行されます。
@end defmac

@defmac AC_CHECK_FILES (@var{files}@r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex CHECK_FILES
@code{AC_CHECK_FILE}を@var{files}に列挙したそれぞれのファイルごとに一度
ずつ実行します。さらに見つけたファイルそれぞれに対して
@samp{HAVE_@var{file}}を1に定義します。
@end defmac

@defmac AC_CHECK_PROG (@var{variable}, @var{prog-to-check-for}, @var{value-if-found} @r{[}, @var{value-if-not-found} @r{[}, @var{path}, @r{[} @var{reject} @r{]]]})
@maindex CHECK_PROG
プログラム@var{prog-to-check-for}が@code{PATH}中に
あるかどうかを調べます。もし発見された場合@var{variable}を
@var{value-if-found}に設定します。発見されなかった場合
(@var{value-if-not-found}が指定されていた場合は)
@var{value-if-not-found}に設定します。
このマクロは、@var{reject} (絶対パスのファイル名)を
サーチパス上で発見してもそれは無視します。
この場合、@var{variable}はパス上でみつかった
@var{prog-to-check-for}で、@var{reject}ではない
ファイルの絶対パス名になります。
@var{variable}が既に設定されていた場合、なにもしません。
@var{variable}のために、@code{AC_SUBST}を呼び出します。
@end defmac

@defmac AC_CHECK_PROGS (@var{variable}, @var{progs-to-check-for} @r{[}, @var{value-if-not-found} @r{[}, @var{path}@r{]]})
@maindex CHECK_PROGS
@var{progs-to-check-for}に指定された、
スペースで区切られたプログラム名たちが@code{PATH}上に
あるかどうかを調べます。もしあった場合、
そのプログラム名を@var{variable}に設定します。
さもなくば、次のプログラム名を探します。
もし、指定された全てのプログラムがなかった場合、
@var{value-if-not-found}の値を@var{variable}に設定します。
もし@var{value-if-not-found}が指定されていなかったら、
@var{variable}の値は変更されません。
@var{variable}のために、@code{AC_SUBST}を呼び出します。
@end defmac

@defmac AC_CHECK_TOOL (@var{variable}, @var{prog-to-check-for} @r{[}, @var{value-if-not-found} @r{[}, @var{path}@r{]]})
@maindex CHECK_TOOL
@code{AC_CHECK_PROG}と同様ですが、@var{prog-to-check-for}の
先頭に@code{AC_CANONICAL_HOST}で判定されたホストタイプを
つけたものを最初に探します(@pxref{Canonicalizing}参照)。
例えば、ユーザが@samp{configure --host=i386-gnu}を
実行し、その中で
@example
AC_CHECK_TOOL(RANLIB, ranlib, :)
@end example
@noindent
というマクロが使われていたなら、まずパス上の
@file{i386-gnu-ranlib}が探され、もしあったなら
@file{i386-gnu-ranlib}を@code{RANLIB}に設定します。
プログラムがなければ@code{RANLIB}は@samp{:}にされます。
@end defmac

@defmac AC_PATH_PROG (@var{variable}, @var{prog-to-check-for} @r{[}, @var{value-if-not-found} @r{[}, @var{path}@r{]]})
@maindex PATH_PROG
@code{AC_CHECK_PROG}と同様ですが、
プログラムが発見された場合@var{variable}を
@var{prog-to-check-for}の絶対パスに設定します。
@end defmac

@defmac AC_PATH_PROGS (@var{variable}, @var{progs-to-check-for} @r{[}, @var{value-if-not-found} @r{[}, @var{path}@r{]]})
@maindex PATH_PROGS
@code{AC_CHECK_PROGS}と同様ですが、
@var{progs-to-check-for}の中のいずれかが
見付かったら、プログラムの絶対パスを
@var{variable}に設定します。
@end defmac

@node Libraries, Library Functions, Alternative Programs, Existing Tests
@section Library Files

以下のマクロは指定されたC、C++、Fortran 77ライブラリファイル(および中身)が
存在するかどうかを調べます。

@defmac AC_CHECK_LIB (@var{library}, @var{function} @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found} @r{[}, @var{other-libraries}@r{]]]})
@maindex CHECK_LIB
現在選択されている言語によって(@pxref{Language Choice})、
@var{function}に指定されたC、C++、Fortran 77の関数が存在するか
どうかを調べます。
チェックはテスト用のCプログラムとライブラリ
@var{library}を一緒にリンクしてみて成功するかどうかで
行われます。
@var{library}はライブラリのベースネームです。
例えば、@samp{-lmp}を調べる場合、@samp{mp}を
引数@var{library}に指定することになります。

@var{action-if-found}には、リンクが成功した場合に
呼び出されるshellコマンド列を指定します。
@var{action-if-not-found}には、リンクが失敗したときに
呼び出されるshellコマンド列を指定します。
@var{action-if-found}が
指定されなかった場合、デフォルトの動作になります。
デフォルトの動作は@code{LIB}に@samp{-l@var{library}}を追加し、
@samp{HAVE_LIB@var{library}}を(全部大文字)定義するように
なっています。

もし@var{library}だけとリンクするのでは未解決のシンボルが
出てしまい、他のライブラリをリンクしないといけない場合には、
それらのライブラリ名をスペースで区切って@var{other-libraries}に
指定してください: @samp{-lXt -lX11}のように。
指定しなかった場合、マクロは@var{library}が存在することを
検出できません。なぜなら、未解決シンボルのせいでリンクが
常に失敗するからです。
@end defmac

@defmac AC_HAVE_LIBRARY (@var{library}, @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found} @r{[}, @var{other-libraries}@r{]]]})
@maindex HAVE_LIBRARY
このマクロは@code{AC_CHECK_LIB}を、引数@var{function}を
@code{main}にして呼び出すのと同じです。引数@var{library}は
@samp{foo}でも@samp{-lfoo}でも、あるいは@samp{libfoo.a}
とでも指定できます。これらの全ての場合に、コンパイラには
引数@samp{-lfoo}が渡ります。
@var{library}にshell変数を渡すことはできません。
@var{library}は文字列リテラルである必要があります。
このマクロはobsoleteです。
@end defmac

@defmac AC_SEARCH_LIBS (@var{function}, @var{search-libs} @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found} @r{[}, @var{other-libraries}@r{]]]})
@maindex SEARCH_LIBS
もしまだそのライブラリを利用するように設定されていなければ@var{function} 
を定義したライブラリを探します。これは@code{AC_TRY_LINK_FUNC}を最初にラ
イブラリなしで、それから@var{search-libs}に列挙されたライブラリをそれぞ
れ指定して呼び出すのと同じです。

関数が見つかれば@var{action-if-found}を実行します。そうでなければ
@var{action-if-not-found}を実行します。

もし、@var{library}のリンクがシンボル未解決という結果になり、追加のライ
ブラリとともにリンクすることによってそれが解決するようならば、そのような
ライブラリを@var{other-libraries}引数に空白区切りで@samp{-lXt -lX11}のよ
うに与えてください。そうでなければ、テストプログラムのリンクがいつもシン
ボル未解決で失敗するので、このマクロは@var{function}が存在することを発見
するのに失敗するでしょう。
@end defmac

@defmac AC_SEARCH_LIBS (@var{function}, @var{search-libs}@r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex SEARCH_LIBS
このマクロは、それぞれのライブラリを@var{search-libs}でリストアップした
@code{AC_TRY_LINK_FUNC}の一回の呼び出しと同じです。特定の@var{function} 
が見つかった最初のライブラリに対し、@samp{-l@var{library}}を@code{LIBS} 
に追加し、@var{action-if-found}を実行します。それ以外の場合は
@var{action-if-not-found}を実行します。
@end defmac

@node Library Functions, Header Files, Libraries, Existing Tests
@section Library Functions

以下のマクロは、Cのライブラリ関数があるかどうかを調べます。
もし、あるマクロをチェックする特別の関数が定義されておらず、
特殊なチェックが必要でない場合には、汎用の関数チェックマクロを
用いることができます。

@menu
* Particular Functions::        Special handling to find certain functions.
* Generic Functions::           How to find other functions.
@end menu

@node Particular Functions, Generic Functions, Library Functions, Library Functions
@subsection Particular Function Checks

以下のマクロは、特定のCライブラリ関数をチェックします ---
関数が存在するかどうか、および特定の引数を与えられたときの
挙動がチェックされます。

@defmac AC_FUNC_ALLOCA
@maindex FUNC_ALLOCA
@cvindex C_ALLOCA
@cvindex HAVE_ALLOCA_H
@ovindex ALLOCA
@code{alloca}の有無をチェックします。
このチェックでは、なるべくコンパイラ組み込みの
@code{alloca}を探そうとします。
このために、@file{alloca.h}があるかどうかおよび
Cプリプロセッサマクロ@code{__GNUC__}と
@code{_AIX}があらかじめ定義されているかを調べます。
もし@file{alloca.h}がみつかったら、
@code{HAVE_ALLOCA_H}が定義されます。

上記のチェックが失敗したら、標準Cライブラリに
関数があるかどうかを探します。
ここまでのチェックのいずれかが成功した場合、
@code{HAVE_ALLOCA}を定義します。
全てが失敗した場合、出力変数@code{ALLOCA}を
@samp{alloca.o}に定義し、@code{C_ALLOCA}を定義します
(@code{C_ALLOCA}は、プログラムがGCのために
定期的に@samp{alloca(0)}を呼び出すことが
できるようにするため定義されます)。
@code{ALLOCA}は@code{LIBOBJS}とは独立に定義されます。
これは複数のプログラムをコンパイルするとき、
@code{alloca}を実際使うものが少なかった場合に
いちいち@samp{alloca.o}をコンパイルしなくて済むようにするためです
(訳註: 超意訳。自信なし。原文は「
This variable is separate from @code{LIBOBJS} so multiple programs can
share the value of @code{ALLOCA} without needing to create an actual
library, in case only some of them use the code in @code{LIBOBJS}.」)。

このマクロはSystem V R3の@file{libPW}や
System V R4の@file{libucb}に含まれる
@code{alloca}を探すことはしません。
なぜなら、これらのライブラリには
場合によっては@code{alloca}が
含まれていなかったり、
含まれていても@code{alloca}バグがあったり、
あるいは互換性に問題のある@code{alloca}以外の
関数が含まれていたりするためです。
どうしてもこれらのライブラリに含まれる
@code{alloca}を利用したい場合には、
(@file{alloca.c}をコンパイルするのではなく)
@code{ar}を使って@file{alloca.o}を取り出してください。

@code{alloca}を利用するソースファイルには、
正しく定義を行うため先頭部分に以下のような
コードが含まれている必要があります。
AIXの一部のバージョンにおいては、@code{alloca}の
宣言は(コメントやプリプロセッサディレクティブを
除いて)ファイルの一番先頭に現れる必要があります。
@code{#pragma}ディレクティブはANSI以前のCコンパイラでは
無視されることを期待して書かれています。

@example
@group
/* AIX requires this to be the first thing in the file.  */
#ifndef __GNUC__
# if HAVE_ALLOCA_H
#  include <alloca.h>
# else
#  ifdef _AIX
 #pragma alloca
#  else
#   ifndef alloca /* predefined by HP cc +Olibcalls */
char *alloca ();
#   endif
#  endif
# endif
#endif
@end group
@end example
@end defmac

@defmac AC_FUNC_CLOSEDIR_VOID
@maindex FUNC_CLOSEDIR_VOID
@cvindex CLOSEDIR_VOID
ライブラリ関数@code{closedir}が
意味のある値を返さない場合、@code{CLOSEDIR_VOID}を
定義します。
定義されなかった場合には、
@code{closedir}を呼んだ場合
返り値を用いてエラーチェックを行うべきです。
@end defmac

@defmac AC_FUNC_FNMATCH
@maindex FUNC_FNMATCH
@ovindex LIBOBJS
ライブラリ関数@code{fnmatch}が存在し、かつ動作するなら、
@code{HAVE_FNMATCH}を定義します
(ちなみに、SunOS 5.4付属のものは動きません)。
@end defmac

@defmac AC_FUNC_GETLOADAVG
@maindex FUNC_GETLOADAVG
@cvindex SVR4
@cvindex DGUX
@cvindex UMAX
@cvindex UMAX4_3
@cvindex NLIST_STRUCT
@cvindex NLIST_NAME_UNION
@cvindex GETLODAVG_PRIVILEGED
@cvindex NEED_SETGID
@ovindex LIBOBJS
@ovindex NEED_SETGID
@ovindex KMEM_GROUP
システムのロードアベレージを得る方法をチェックします。
現在のシステムで@code{getloadavg}が利用できるなら、
@code{HAVE_GETLOADAVG}を定義し、
@code{LIBS}に必要なライブラリファイルを追加します。

もし@code{getloadavg}が利用できないなら、
@samp{getloadavg.o}を出力変数@code{LIBOBJS}に追加し、
必要ならいくつかのCプリプロセッサマクロや出力変数を定義します:

@enumerate
@item
@code{SVR4}、@code{DGUX}、@code{UMAX}または
@code{UMAX4_3}のうちであてはまるものを定義します。

@item
@file{nlist.h}があった場合、@code{NLIST_STRUCT}を定義します。

@item
@samp{struct nlist}にメンバ@samp{n_un}があった場合、
@code{NLIST_NAME_UNION}を定義します。

@item
@file{getloadavg.c}をコンパイルする際に
@code{LDAV_PRIVILEGED}が定義された場合、
@code{getloadavg}が正しく動作するには、
プログラムは(setuid bitをたてるなどして)
root権限で動作するようにインストールされる必要があります。
この場合、@code{GETLOADAVG_PRIVILEGED}が定義されます。

@item
出力変数@code{NEED_SETGID}が定義されます。
インストールする際にsetgid bitをたてる必要がある場合には
値は@samp{true}に、さもなくば値は@samp{false}になります。
@code{NEED_SETGID}が@samp{true}である場合には、
プログラムファイルの所属すべき
gidが@code{KMEM_GROUP}に定義されます。
@end enumerate
@end defmac

@defmac AC_FUNC_GETMNTENT
@maindex FUNC_GETMNTENT
@cvindex HAVE_GETMNTENT
@code{getmntent}がライブラリファイル
@file{sun}、@file{seq}および@file{gen}の
いずれかに含まれているかどうか調べます
(順に、Irix 4、PTX、Unixwareの場合の
ライブラリファイルです)。
@code{getmntent}が存在した場合、
@code{HAVE_GETMNTENT}を定義します。
@end defmac

@defmac AC_FUNC_GETPGRP
@maindex FUNC_GETPGRP
@cvindex GETPGRP_VOID
@code{getpgrp}が引数をとらない場合
(つまりPOSIX.1準拠の場合)、
@code{GETPGRP_VOID}を定義します。
定義されなかった場合、@code{getpgrp}はBSDでのように
プロセスIDを引数にとります。
このマクロは@code{getpgrp}があるかどうかは
全く調べません; @code{getpgrp}がない場合に
対処するには、先に@code{AC_CHECK_FUNC}を使って
@code{getpgrp}があるかどうか調べてください。
@end defmac

@defmac AC_FUNC_MEMCMP
@maindex FUNC_MEMCMP
@ovindex LIBOBJS
ライブラリ関数@code{memcmp}がないか、
または(SunOS 4.1.3のように)8bitデータに対して
使えない場合、@samp{memcmp.o}を
出力変数@code{LIBOBJS}に追加します。
@end defmac

@defmac AC_FUNC_MMAP
@maindex FUNC_MMAP
@cvindex HAVE_MMAP
@code{mmap}が存在して正常動作する場合、
@code{HAVE_MMAP}を定義します。
動作チェックは、既にマップされたメモリを
自プロセスの固定アドレスにマップする場合に関してのみ
行われます。
@end defmac

@defmac AC_FUNC_SELECT_ARGTYPES
@maindex FUNC_SELECT_ARGTYPES
@cvindex SELECT_TYPE_ARG1
@cvindex SELECT_TYPE_ARG234
@cvindex SELECT_TYPE_ARG5
関数@code{select}の引数それぞれに渡される正しい型を決定し、
@code{SELECT_TYPE_ARG1}、@code{SELECT_TYPE_ARG234}、
@code{SELECT_TYPE_ARG5}それぞれにその型を定義します。
@code{SELECT_TYPE_ARG1}は@samp{int}にデフォルト設定され、
@code{SELECT_TYPE_ARG234}は@samp{int *}にデフォルト設定され、
@code{SELECT_TYPE_ARG5}は@samp{struct timeval *}にデフォルト設定されます。
@end defmac

@defmac AC_FUNC_SETPGRP
@maindex FUNC_SETPGRP
@cvindex SETPGRP_VOID
@code{setpgrp}が引数をとらない場合
(つまりPOSIX.1準拠の場合)、
@code{SETPGRP_VOID}を定義します。
定義されなかった場合、@code{setpgrp}はBSDでのように
プロセスIDを引数にとります。
このマクロは@code{setpgrp}があるかどうかは
全く調べません; @code{setpgrp}がない場合に
対処するには、先に@code{AC_CHECK_FUNC}を使って
@code{setpgrp}があるかどうか調べてください。
@end defmac

@defmac AC_FUNC_SETVBUF_REVERSED
@maindex FUNC_SETVBUF_REVERSED
@cvindex SETVBUF_REVERSED
@code{setvbuf}の第2引数がバッファリングの形式で、
第3引数がバッファへのポインタの場合、
@code{SETVBUF_REVERSED}を定義します。
@code{SETVBUF_REVERSED}が定義されるのは、
release 3以前のSystem Vの場合です。
@end defmac

@defmac AC_FUNC_STRCOLL
@maindex FUNC_STRCOLL
@cvindex HAVE_STRCOLL
@code{strcoll}が存在して正常動作する場合、
@code{HAVE_STRCOLL}を定義します。
このマクロは@code{strcoll}があるかどうかを
@code{AC_CHECK_FUNC}より詳しく調べます。
一部のシステムでは、@code{strcoll}の
定義が誤っているためこの関数を使うべきではないからです。
@end defmac

@defmac AC_FUNC_STRFTIME
@maindex FUNC_STRFTIME
@cvindex HAVE_STRFTIME
@code{strftime}が@file{intl}ライブラリにあるかどうかを調べます
(これはSCO UNIXのためです)。
もしあった場合、@code{HAVE_STRFTIME}を定義します。
@end defmac

@defmac AC_FUNC_UTIME_NULL
@maindex FUNC_UTIME_NULL
@cvindex HAVE_UTIME_NULL
@samp{utime(@var{file}, NULL)}が@var{file}の
タイムスタンプを現在時刻に設定する場合、
@code{HAVE_UTIME_NULL}を定義します。
@end defmac

@defmac AC_FUNC_VFORK
@maindex FUNC_VFORK
@cvindex HAVE_VFORK_H
@cvindex vfork
@file{vfork.h}があった場合、@code{HAVE_VFORK_H}を定義します。
正常動作動作する@code{vfork}が発見されなかった場合、
@code{vfork}を@code{fork}に@code{#define}します。
このマクロは、いくつかのシステムでの@code{vfork}の
バグをチェックし、バグつきの場合には@code{vfork}が
みつからなかったかのように振舞います。
ただし、子プロセスで@code{signal}を呼んでも
親プロセスのシグナルハンドラが変更されない場合には
これはバグつきとはみなされません。
子プロセスでシグナルハンドラを変更することは
めったにないからです。
@end defmac

@defmac AC_FUNC_VPRINTF
@maindex FUNC_VPRINTF
@cvindex HAVE_VPRINTF
@cvindex HAVE_DOPRNT
@code{vprintf}が存在する場合、
@code{HAVE_VPRINTF}を定義します。
ない場合に@code{_doprnt}が存在したら、
@code{HAVE_DOPRNT}を定義します。
ちなみに、@code{vprintf}が存在したら、
@code{vfprintf}と@code{vsprintf}も
存在すると仮定して構いません。
@end defmac

@defmac AC_FUNC_WAIT3
@maindex FUNC_WAIT3
@cvindex HAVE_WAIT3
@code{wait3}が存在し、呼び出し時に第3引数
(@samp{struct rusage *})の指し先の内容がきちんと
設定される場合、
@code{HAVE_WAIT3}を定義します。
ちなみに、HP-UXでは第3引数の差し先はきちんと設定されません。
@end defmac

@node Generic Functions,  , Particular Functions, Library Functions
@subsection Generic Function Checks

以下のマクロは、チェックのための特別のマクロがないライブラリ関数について
調べるために用意されています。
ライブラリ関数がデフォルトのCライブラリに入っていない
可能性がある場合には、@code{AC_CHECK_LIB}を用いて
そのライブラリファイルがあるかどうか調べてください。
ライブラリ関数があるかどうかだけでなく、その振舞いも調べる
必要がある場合には、自前でテストを記述する必要があるでしょう
(@pxref{Writing Tests})。

@defmac AC_CHECK_FUNC (@var{function}, @r{[}@var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex CHECK_FUNC
Cの関数@var{function}が存在する場合、shellコマンド@var{action-if-found}を
実行します。
ない場合には@var{action-if-not-found}を実行します。
関数のあるなしによってシンボルを定義したいだけであれば、
@code{AC_CHECK_FUNCS}を使ったほうがいいでしょう。
このマクロは@code{AC_LANG_CPLUSPLUS}が呼ばれているいないに関わらず
C linkageで関数を探します。
C++ではCよりもライブラリ関数がきちんと標準化されているので、
@code{AC_CHECK_FUNC}を使う機会は少なそうだからです
(環境を調べる対象の言語を選ぶやりかたについては、
@pxref{Language Choice}を参照)。
@end defmac

@defmac AC_CHECK_FUNCS (@var{function}@dots{} @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex CHECK_FUNCS
@cvindex HAVE_@var{function}
スペースで区切られた複数の@var{function}のうち、
実際存在するものについて@code{HAVE_@var{function}}(全部大文字)を定義します。
@var{action-if-found}には、
各々の関数がみつかったときに実行したいshellスクリプトを記述します。
@var{action-if-found}を@samp{break}にすると、
最初に関数が見つかったところでループを抜けることができます。
@var{action-if-not-found}には、
各関数がみつからなかったときに実行されるshellスクリプトを記述します。
@end defmac

@defmac AC_REPLACE_FUNCS (@var{function}@dots{})
@maindex REPLACE_FUNCS
@ovindex LIBOBJS
このマクロは、
特定の関数@var{function}が存在しない場合に
@code{LIBOBJS}に@samp{@var{function}.o}を追加します。
この動作は、
@code{AC_CHECK_FUNCS}で
@var{action-if-not-found}に
「出力変数@code{LIBOBJS}に@samp{@var{function}.o}を追加する」
と記述した場合と似ています。
ライブラリの置き換え用の関数を定義するときには、
プロトタイプ宣言を@samp{#ifndef HAVE_@var{function}}で
くくっておいた方がいいでしょう。
システムに@var{function}がある場合、
システム定義のincludeファイルのどこかにプロトタイプ宣言があるはずです。
定義が矛盾するかもしれないから、システムに@var{function}が
あるときには再定義を避けるべきです。
@end defmac

@node Header Files, Structures, Library Functions, Existing Tests
@section Header Files

以下のマクロはCヘッダファイルがあるかないか調べます。
あなたのチェックしたいヘッダファイルについて
特定ヘッダファイル向けのマクロがなくて、
しかも特殊なことを調べる必要がなければ、
汎用のヘッダファイル検査マクロを使うとよいでしょう。

@menu
* Particular Headers::          Special handling to find certain headers.
* Generic Headers::             How to find other headers.
@end menu

@node Particular Headers, Generic Headers, Header Files, Header Files
@subsection Particular Header Checks

以下のマクロは特定のシステムヘッダファイルを検査します。
ファイルがあるかどうか、それから必要なときには
なにを定義しているかを検査します。

@defmac AC_DECL_SYS_SIGLIST
@maindex DECL_SYS_SIGLIST
@cvindex SYS_SIGLIST_DECLARED
@code{sys_siglist}が@file{signal.h}または@file{unistd.h}で定義されているなら、
@code{SYS_SIGLIST_DECLARED}を定義します。
@end defmac

@defmac AC_DIR_HEADER
@maindex DIR_HEADER
@cvindex DIRENT
@cvindex SYSDIR
@cvindex SYSNDIR
@cvindex NDIR
@cvindex VOID_CLOSEDIR
@code{AC_HEADER_DIRENT}と@code{AC_FUNC_CLOSEDIR_VOID}を呼ぶのと似ていますが、
定義するCプリプロセッサマクロが違います。
@code{AC_DIR_HEADER}は
どのヘッダファイルがみつかったのかを表すCプリプロセッサマクロを定義します。
@code{AC_DIR_HEADER}、およびこれにより定義されるCプリプロセッサマクロは
obsoleteです。
定義されるCプリプロセッサマクロは以下のとおり:

@c The printed table looks too spaced out with blank lines between the entries.
@table @file
@item dirent.h
@code{DIRENT}
@item sys/ndir.h
@code{SYSNDIR}
@item sys/dir.h
@code{SYSDIR}
@item ndir.h
@code{NDIR}
@end table

さらに、関数@code{closedir}の返り値に意味がない場合には
@code{VOID_CLOSEDIR}を定義します。
@end defmac

@defmac AC_HEADER_DIRENT
@maindex HEADER_DIRENT
@cvindex HAVE_DIRENT_H
@cvindex HAVE_NDIR_H
@cvindex HAVE_SYS_DIR_H
@cvindex HAVE_SYS_NDIR_H
以下のヘッダファイルの有無を調べます。
そして、ヘッダファイルが存在し@samp{DIR}を定義した最初のファイルについて
以下のCプリプロセッサマクロを定義します:

@c The printed table looks too spaced out with blank lines between the entries.
@table @file
@item dirent.h
@code{HAVE_DIRENT_H}
@item sys/ndir.h
@code{HAVE_SYS_NDIR_H}
@item sys/dir.h
@code{HAVE_SYS_DIR_H}
@item ndir.h
@code{HAVE_NDIR_H}
@end table

ソースコード中でディレクトリライブラリのための定義をするには、
以下のようにするといいでしょう:

@example
@group
#if HAVE_DIRENT_H
# include <dirent.h>
# define NAMLEN(dirent) strlen((dirent)->d_name)
#else
# define dirent direct
# define NAMLEN(dirent) (dirent)->d_namlen
# if HAVE_SYS_NDIR_H
#  include <sys/ndir.h>
# endif
# if HAVE_SYS_DIR_H
#  include <sys/dir.h>
# endif
# if HAVE_NDIR_H
#  include <ndir.h>
# endif
#endif
@end group
@end example

上記の定義を使う場合、プログラム中では変数を(@code{struct direct}でなく)
@code{struct dirent}型として定義します。
ディレクトリエントリ名をとるためには@code{NAMLEN}マクロに
@code{struct dirent}へのポインタを渡します。

このマクロはSCO Xenixの@file{dir}と@file{x}ライブラリも検査します。
@end defmac

@defmac AC_HEADER_MAJOR
@maindex HEADER_MAJOR
@cvindex MAJOR_IN_MKDEV
@cvindex MAJOR_IN_SYSMACROS
@file{sys/types.h}に@code{major}、@code{minor}、それから
@code{makedev}が定義されておらず、
@file{sys/mkdev.h}で定義されている場合、
@code{MAJOR_IN_MKDEV}を定義します。
@file{sys/sysmacros.h}で定義されている場合、
@code{MAJOR_IN_SYSMACROS}を定義します。
@end defmac

@defmac AC_HEADER_STDC
@maindex HEADER_STDC
@cvindex STDC_HEADERS
システムにANSI Cヘッダファイルがある場合、@code{STDC_HEADERS}を定義します。
具体的には、@file{stdlib.h}、@file{stdarg.h}、@file{string.h}、
それから@file{float.h}をチェックします。
これらのヘッダがあれば、多分他のANSI Cヘッダファイルもあるでしょう。
このマクロは、@file{string.h}で@code{memchr}が定義されているかどうか
調べます(もし@code{memchr}があればほかの@code{mem}系関数もあるでしょう)。
それから、@file{stdlib.h}で@code{free}が定義されているかどうか
調べます(もしokなら@code{malloc}や他の関連関数もあるでしょう)。
さらに、@file{ctype.h}で定義されるマクロがANSI Cの定義どおり、
@samp{2^7}のビットが立っていても動くかどうか調べます。

ANSI互換のヘッダファイル(とCライブラリ関数)があるかどうか決めるには、
@code{__STDC__}でないしに@code{STDC_HEADERS}を使いましょう。
GCCがインストールされているシステムの多くには
ANSI Cヘッダファイルがないからです(訳註: つまり、@code{__STDC__}が
あってもANSI Cヘッダファイルがあるとは限らない、ということ)。

ANSI Cヘッダのないシステムでは、どのヘッダでなにを定義しているかは
全くばらばらです。
ですから、どのヘッダファイルに定義があるか探すよりも、
自分で使う関数を自分で定義した方が簡単です。
あるシステムではANSIとBSDの関数が混在しています。
あるシステムはほぼANSI互換なのに@samp{memmove}がありません。
あるシステムはBSD由来の関数を@file{string.h}や@file{strings.h}註の
マクロとして定義しています。
あるシステムではBSD由来の関数しかなく、@file{string.h}がありません。
メモリ関係の関数は@file{memory.h}で定義されていたり、@file{string.h}で
定義されていたりします。
他にもいろいろ変種があります。
とりあえず、ANSIで定義されている関数が
文字列関係関数をひとつ、
メモリ関係関数を検査すれば多分こと足りるでしょう。
検査が成功すれば、多分他のANSI定義の関数もあるでしょう。
以下を@file{configure.in}に含めた場合:

@example
AC_HEADER_STDC
AC_CHECK_FUNCS(strchr memcpy)
@end example

@noindent
プログラム中では以下のように定義します:

@example
@group
#if STDC_HEADERS
# include <string.h>
#else
# ifndef HAVE_STRCHR
#  define strchr index
#  define strrchr rindex
# endif
char *strchr (), *strrchr ();
# ifndef HAVE_MEMCPY
#  define memcpy(d, s, n) bcopy ((s), (d), (n))
#  define memmove(d, s, n) bcopy ((s), (d), (n))
# endif
#endif
@end group
@end example

@noindent
もしプログラム中で@code{memchr}、@code{memset}、@code{strtok}、
@code{strspn}など、BSD系OSに代用になる関数がないような関数を使う場合、
この定義だけでは足りません。
各関数について配布キット中にプログラムコードを添付しなければなりません。
添付したプログラムを必要なときにだけ使うにはどうすればいいでしょう?
(システムのCライブラリに入っている関数の方が最適化されていて
速いかもしれないので)
例えば関数@code{memchr}の場合、
@file{memchr.c}というファイルを置いて、
@samp{AC_REPLACE_FUNCS(memchr)}を使えば大丈夫です。
@end defmac

@defmac AC_HEADER_SYS_WAIT
@maindex HEADER_SYS_WAIT
@cvindex HAVE_SYS_WAIT_H
@file{sys/wait.h}があって、POSIX.1互換なら、
@code{HAVE_SYS_WAIT_H}を定義します。
@file{sys/wait.h}がない場合、exit statusを保持するのに@code{int}でなしに
古いBSDのように@code{union wait}を使っている場合にはPOSIX.1非互換です。
@file{sys/wait.h}がPOSIX.1互換でない場合には、
ヘッダファイルをincludeせず、
POSIX.1マクロを自分で定義しましょう。
例えば:

@example
@group
#include <sys/types.h>
#if HAVE_SYS_WAIT_H
# include <sys/wait.h>
#endif
#ifndef WEXITSTATUS
# define WEXITSTATUS(stat_val) ((unsigned)(stat_val) >> 8)
#endif
#ifndef WIFEXITED
# define WIFEXITED(stat_val) (((stat_val) & 255) == 0)
#endif
@end group
@end example
@end defmac

@defmac AC_MEMORY_H
@maindex MEMORY_H
@cvindex NEED_MEMORY_H
@code{memcpy}や@code{memcmp}などが@file{string.h}で定義されておらず、
@file{memory.h}が存在する場合、@code{NEED_MEMORY_H}を定義します。
このマクロはobsoleteです。
かわりに@code{AC_CHECK_HEADERS(memory.h)}を使ってください。
@code{AC_HEADER_STDC}の例参照。
@end defmac

@defmac AC_UNISTD_H
@maindex UNISTD_H
@cvindex HAVE_UNISTD_H
@file{unistd.h}があれば@code{HAVE_UNISTD_H}を定義します。
このマクロはobsoleteです。
かわりに@samp{AC_CHECK_HEADERS(unistd.h)}を使ってください。

POSIX.1互換かどうか調べるには以下のようにします:

@example
@group
#if HAVE_UNISTD_H
# include <sys/types.h>
# include <unistd.h>
#endif

#ifdef _POSIX_VERSION
/* Code for POSIX.1 systems.  */
#endif
@end group
@end example

@cvindex _POSIX_VERSION
@code{_POSIX_VERSION}は、POSIX.1互換のシステムで@file{unistd.h}をinclude
すると定義されます。
@file{unistd.h}がないシステムは間違いなくPOSIX.1非互換です。
でも、一部のPOSIX.1非互換のシステムには@file{unistd.h}があります。
@end defmac

@defmac AC_USG
@maindex USG
@cvindex USG
@file{strings.h}、@code{rindex}や@code{bzero}がないシステムなら
@code{USG}を定義します。
このマクロは
@file{string.h}、@code{strrchr}、@code{memset}等が存在すると仮定しています。

@code{USG}はobsoleteです。
このマクロでなしに、@code{AC_HEADER_STDC}の例題をみてください。
@end defmac

@node Generic Headers,  , Particular Headers, Header Files
@subsection Generic Header Checks

以下のマクロは、特定のヘッダファイル用マクロが定義されていない
ヘッダファイルを検査するためのものです。
ヘッダファイルがあるかないかだけでなく、中身もチェックしたい場合、
自力で検査マクロを記述しないといけません(@pxref{Writing Tests}参照)。

@defmac AC_CHECK_HEADER (@var{header-file}, @r{[}@var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex CHECK_HEADER
システムヘッダファイル@var{header-file}があったら
@var{action-if-found}を実行します。
なければ@var{action-if-not-found}を実行します。
単にヘッダファイルがあったときにCプリプロセッサシンボルを定義したいだけなら、
@code{AC_CHECK_HEADERS}を使った方がいいでしょう。
@end defmac

@defmac AC_CHECK_HEADERS (@var{header-file}@dots{} @r{[}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex CHECK_HEADERS
@cvindex HAVE_@var{header}
スペースで区切られた複数の@var{header-file}のうち、
実際システムヘッダファイルが存在するものについて
@code{HAVE_@var{header-file}}(全部大文字)を定義します。
@var{action-if-found}には、
各々のヘッダファイルがみつかったときに実行したいshellスクリプトを記述します。
@var{action-if-found}を@samp{break}にすると、
最初にヘッダファイルが見つかったところでループを抜けることができます。
@var{action-if-not-found}には、
各ヘッダファイルがみつからなかったときに実行されるshellスクリプトを記述します。
@end defmac

@node Structures, Typedefs, Header Files, Existing Tests
@section Structures

以下のマクロは特定の構造体や構造体のメンバを検査します。
ここにない構造体を検査したい場合、
@code{AC_EGREP_CPP} (@pxref{Examining Declarations})や@code{AC_TRY_COMPILE}
(@pxref{Examining Syntax})を使ってください。

@defmac AC_HEADER_STAT
@maindex HEADER_STAT
@maindex STAT_MACROS_BROKEN
@code{S_ISDIR}や@code{S_ISREG}などの、@file{sys/stat.h}で定義されている
マクロが正しく動かない場合(返り値が嘘の場合)、
@code{STAT_MACROS_BROKEN}を定義します。
Tektronix UTekV、Amdahl UTS、それからMotorola System V/88が該当します。
@end defmac

@defmac AC_HEADER_TIME
@maindex HEADER_TIME
@cvindex TIME_WITH_SYS_TIME
@file{time.h}と@file{sys/time.h}の両方をincludeしていいなら、
@code{TIME_WITH_SYS_TIME}を定義します。
古いシステムでは、@file{sys/time.h}が@file{time.h}をincludeしていて、
しかも@file{time.h}に複数回includeされた場合に対する対処がないことがあります。
この場合、両方のヘッダファイルを明示的にincludeしてはいけません。
このマクロは、例えば、@code{struct timeval}や@code{struct timezone}と、
@code{struct tm}を同時に使うプログラムに有効です。
@code{HAVE_SYS_TIME_H}とあわせて使うのがよいでしょう。
@code{HAVE_SYS_TIME_H}は
@code{AC_CHECK_HEADERS(sys/time.h)}マクロを使うと定義されます。

@example
@group
#if TIME_WITH_SYS_TIME
# include <sys/time.h>
# include <time.h>
#else
# if HAVE_SYS_TIME_H
#  include <sys/time.h>
# else
#  include <time.h>
# endif
#endif
@end group
@end example
@end defmac

@defmac AC_STRUCT_ST_BLKSIZE
@maindex STRUCT_ST_BLKSIZE
@cvindex HAVE_ST_BLKSIZE
@code{struct stat}にメンバ@code{st_blksize}が定義されているなら、
@code{HAVE_ST_BLKSIZE}を定義します。
@end defmac

@defmac AC_STRUCT_ST_BLOCKS
@maindex STRUCT_ST_BLOCKS
@cvindex HAVE_ST_BLOCKS
@ovindex LIBOBJS
@code{struct stat}にメンバ@code{st_blocks}が定義されているなら、
@code{HAVE_ST_BLOCKS}を定義します。
もしなければ、@samp{fileblocks.o}を出力変数@code{LIBOBJS}に足します。
@end defmac

@defmac AC_STRUCT_ST_RDEV
@maindex STRUCT_ST_RDEV
@cvindex HAVE_ST_RDEV
@code{struct stat}にメンバ@code{st_rdev}が定義されているなら、
@code{HAVE_ST_RDEV}を定義します。
@end defmac

@defmac AC_STRUCT_TM
@maindex STRUCT_TM
@cvindex TM_IN_SYS_TIME
@file{time.h}で@code{struct tm}が定義されていなければ、
@code{TM_IN_SYS_TIME}を定義します。
@code{TM_IN_SYS_TIME}は、@code{struct tm}の定義が欲しければ
@file{sys/time.h}をincludeせよ、という意味です(訳註: 意訳)。
@end defmac

@defmac AC_STRUCT_TIMEZONE
@maindex STRUCT_TIMEZONE
@cvindex HAVE_TM_ZONE
@cvindex HAVE_TZNAME
現在のtimezoneを知る方法を推測します。
@code{struct tm}にメンバ@code{tm_zone}が定義されているなら、
@code{HAVE_TM_ZONE}を定義します。
グローバル変数@code{tzname}が定義されていたら、@code{HAVE_TZNAME}を定義します。
@end defmac

@node Typedefs, C Compiler Characteristics, Structures, Existing Tests
@section Typedefs

以下のマクロはCのtypedefを検査します。
検査したいtypedef用に特定のマクロがなくて、
しかも特殊な検査をしたいわけでないのなら、
汎用のtypedef検査マクロが使えます。

@menu
* Particular Typedefs::         Special handling to find certain types.
* Generic Typedefs::            How to find other types.
@end menu

@node Particular Typedefs, Generic Typedefs, Typedefs, Typedefs
@subsection Particular Typedef Checks

以下のマクロは、@file{sys/types.h}と@file{stdlib.h}の中のC typedefを
検査します(もしファイルがあれば、ですが)。

@defmac AC_TYPE_GETGROUPS
@maindex TYPE_GETGROUPS
@cvindex GETGROUPS_T
@code{GETGROUPS_T}を、
@code{getgroups}の引数の型(配列の基底型)にあわせて、
@code{gid_t}または@code{int}に定義します。
@end defmac

@defmac AC_TYPE_MODE_T
@maindex TYPE_MODE_T
@cvindex mode_t
@code{mode_t}が定義されていない場合、
Cプリプロセッサマクロ@code{mode_t}を@code{int}に@code{#define}します。
@end defmac

@defmac AC_TYPE_OFF_T
@maindex TYPE_OFF_T
@cvindex off_t
@code{off_t}が定義されていない場合、Cプリプロセッサマクロ@code{off_t}を
@code{long}に@code{#define}します。
@end defmac

@defmac AC_TYPE_PID_T
@maindex TYPE_PID_T
@cvindex pid_t
@code{pid_t}が定義されていない場合、Cプリプロセッサマクロ@code{pid_t}を
@code{int}に@code{#define}します。
@end defmac

@defmac AC_TYPE_SIGNAL
@maindex TYPE_SIGNAL
@cvindex RETSIGTYPE
@file{signal.h}で、関数@code{signal}が
「返り値が@code{void}の関数へのポインタ(つまり、@code{(void (*)())}」を
返す場合、@code{RETSIGTYPE}を@code{void}に定義します。
さもなくば、@code{RETSIGTYPE}を@code{int}に定義します。

シグナルハンドラ関数を定義するときには、
返り値を@code{RETSIGTYPE}にしましょう:

@example
@group
RETSIGTYPE
hup_handler ()
@{
@dots{}
@}
@end group
@end example
@end defmac

@defmac AC_TYPE_SIZE_T
@maindex TYPE_SIZE_T
@cvindex size_t
@code{size_t}が定義されていなければ、Cプリプロセッサマクロ@code{size_t}を
@code{unsigned}と定義します。
@end defmac

@defmac AC_TYPE_UID_T
@maindex TYPE_UID_T
@cvindex uid_t
@cvindex gid_t
@code{uid_t}が定義されていなければ、
Cプリプロセッサマクロ@code{uid_t}を@code{int}に、
@code{gid_t}を@code{int}に定義します。
@end defmac

@node Generic Typedefs,  , Particular Typedefs, Typedefs
@subsection Generic Typedef Checks

このマクロは、
特定のtypedef検査マクロが提供されていないtypedefについて調べるときに
使います。

@defmac AC_CHECK_TYPE (@var{type}, @var{default})
@maindex CHECK_TYPE
@var{type}が@file{sys/types.h}で定義されていない場合、
Cプリプロセッサマクロを使って
C (or C++)のビルトインタイプ@var{default}
(例えば、@samp{short}とか@samp{unsigned}とか)に@code{#define}します。
もしヘッダファイルが存在するなら、
@file{stdlib.h}や@file{stddef.h}についても調べます。
@end defmac

@node C Compiler Characteristics, Fortran 77 Compiler Characteristics, Typedefs, Existing Tests
@section C Compiler Characteristics

以下のマクロはCコンパイラやマシンアーキテクチャの特性を調べます。
以下にない性質を調べたい場合、
@code{AC_TRY_COMPILE} (@pxref{Examining Syntax}) か @code{AC_TRY_RUN}
(@pxref{Run Time})を使ってください。

@defmac AC_C_BIGENDIAN
@maindex C_BIGENDIAN
@cvindex WORDS_BIGENDIAN
16ビット幅の値を上位の8ビット(@samp{2^15}から@samp{2^8}の8ビット)から
先に格納するCPUアーキテクチャの場合、@code{WORDS_BIGENDIAN}を定義します。
例えばMotorolaやSPARCなどのCPUがこれにあたります。
IntelやVAXは違います。
@end defmac

@defmac AC_C_CONST
@maindex C_CONST
@cvindex const
Cコンパイラが@code{const}を完全にサポートしていなければ、
@code{const}を空に@code{#define}します。
世の中には@code{const}をサポートしているのに@code{__STDC__}を定義していない
Cコンパイラや、
逆に@code{const}を完全にはサポートしていないのに@code{__STDC__}を定義している
Cコンパイラがあります。
@code{AC_C_CONST}を使えば、プログラム中では必ずCコンパイラが@code{const}を
サポートしているつもりで、@code{const}を書けば大丈夫です。
Cコンパイラが@code{const}をサポートしていなければ、
@code{const}は@file{Makefile}またはconfiguration header fileで空にされます。
@end defmac

@defmac AC_C_INLINE
@maindex C_INLINE
@cvindex inline
Cコンパイラが@code{inline}をサポートしていればなにもしません。
@code{inline}がサポートされておらず、@code{__inline__}あるいは
@code{__inline}がサポートされていれば、
@code{inline}を@code{__inline__}か@code{__inline}に@code{#define}します。
どちらもサポートされていなければ空にします。
@end defmac

@defmac AC_C_CHAR_UNSIGNED
@maindex C_CHAR_UNSIGNED
@cvindex __CHAR_UNSIGNED__
Cの型@code{char}が符号なし(unsigned)だったら、
@code{__CHAR_UNSIGNED__}を定義します。
ただし、Cコンパイラが既に@code{__CHAR_UNSIGNED__}を
定義していたらなにもしません。
@end defmac

@defmac AC_C_LONG_DOUBLE
@maindex C_LONG_DOUBLE
@cvindex HAVE_LONG_DOUBLE
Cコンパイラが@code{long double}型をサポートしていたら、
@code{HAVE_LONG_DOUBLE}を定義します。
世の中には
@code{__STDC__}を定義していないのに
@code{long double}をサポートしているCコンパイラや、
@code{__STDC__}を定義しているのに
@code{long double}をサポートしていないCコンパイラがあります。
@end defmac

@defmac AC_C_STRINGIZE
@maindex C_STRINGIZE
@cvindex HAVE_STRINGIZE
Cプリプロセッサが文字列化演算子をサポートしているなら
@code{HAVE_STRINGIZE}を定義します。文字列化演算子は@samp{#} で、以下のよ
うなマクロ定義の中で見出せます。

@example
#define x(y) #y
@end example
@end defmac

@defmac AC_CHECK_SIZEOF (@var{type} @r{[}, @var{cross-size}@r{]})
@maindex CHECK_SIZEOF
@code{SIZEOF_@var{uctype}}をC(またはC++の)基底型@var{type}の
バイトサイズにします。
@var{type}は例えば@samp{int}とか@samp{char *}とかです。
コンパイラが@samp{type}を知らない場合、@code{SIZEOF_@var{uctype}}は
0になります。
@var{uctype}は、@var{type}の小文字を大文字に、スペースを下線@samp{_}に、
アスタリスク(@samp{*})を@samp{P}にしたものです。
クロスコンパイルをしている場合、
@var{cross-size}を指定していればそれが使われます。
クロスコンパイルをしている場合に
@var{cross-size}が指定されていないと、
@code{configure}はエラーメッセージを出して終了します。

例えば、DEC Alpha AXPで
@example
AC_CHECK_SIZEOF(int *)
@end example
@noindent
とすると、@code{SIZEOF_INT_P}は8になります。
@end defmac

@defmac AC_INT_16_BITS
@maindex INT_16_BITS
@cvindex INT_16_BITS
Cの型@code{int}が16ビットの場合、@code{INT_16_BITS}を定義します。
このマクロはobsoleteです。
かわりにより汎用的な@samp{AC_CHECK_SIZEOF(int)}を使ってください。
@end defmac

@defmac AC_LONG_64_BITS
@maindex LONG_64_BITS
@cvindex LONG_64_BITS
Cの型@code{long int}が64ビットの場合、@code{LONG_64_BITS}を定義します。
このマクロはobsoleteです。
かわりにより汎用的な@samp{AC_CHECK_SIZEOF(long)}を使ってください。
@end defmac


@node Fortran 77 Compiler Characteristics, System Services, C Compiler Characteristics, Existing Tests
@section Fortran 77 Compiler Characteristics

以下のマクロはFortran 77コンパイラの特性を検査します。ここに列挙されてい
ない特性を検査するには、@code{AC_TRY_COMPILE}(@pxref{Examining Syntax}) 
や @code{AC_TRY_RUN} (@pxref{Run Time}) を使います。まず現在選択されてい
る言語がFortran 77 @code{AC_LANG_FORTRAN77} に設定されていることを確かめ
てください(@pxref{Language Choice})。

@defmac AC_F77_LIBRARY_LDFLAGS
@maindex F77_LIBRARY_LDFLAGS
@ovindex FLIBS
Fortran 77プログラムや共有ライブラリを首尾良くリンクするのに必要な
@dfn{Fortran 77 固有のものやランタイムなライブラリ}のための
リンカフラグ(例えば、@samp{-L}や@samp{-l})を決定します。
出力変数@code{FLIBS}はこれらのフラグに設定されます。

このマクロは例えば、1つのプログラムや共有ライブラリでC++とFortran 77ソー
スコードを混合する必要がある場合に使われることを意図されています。
(@pxref{Mixing Fortran 77 With C and C++, , , automake, GNU Automake})。

例えば、もしC++とFortran 77コンパイラからのオブジェクトファイルが一緒に
リンクされなければならないなら、C++コンパイラ/リンカはリンクのために使わ
れなければなりません(C++特有のものは、リンク時にグローバルコンストラクタ、
インスタンステンプレート、例外処理等を呼び出す必要が生じるためです)。

しかし、Fortran 77イントリンシックとランタイムライブラリも同様にリンクす
る必要がありますが、C++コンパイラ/リンカは、デフォルトでFortran 77ライブ
ラリを加える方法を知りません。そのため、マクロ
@code{AC_F77_LIBRARY_LDFLAGS}は、これらのFortran 77ライブラリを決定する
ため作られました。
@end defmac


@node System Services, UNIX Variants, Fortran 77 Compiler Characteristics, Existing Tests
@section System Services

The following macros check for operating system services or capabilities.

@defmac AC_CYGWIN
@maindex CYGWIN
Cygwin環境のための検査をします。もしCygwin環境ならば、シェル変数
@code{CYGWIN} を@samp{yes}に設定します。もしそうでないなら@code{CYGWIN}
を空文字列に設定します。
@end defmac

@defmac AC_EXEEXT
@maindex EXEEXT
@ovindex EXEEXT
.c、 .o、 .objファイルが取り除かれた後で(訳註: ??)コンパイラの出力の元
になる代用変数@code{EXEEXT}を定義します。典型的にはUNIXなら空文字列に、
Win32やOS/2なら@samp{.exe}に設定します。
@end defmac

@defmac AC_OBJEXT
@maindex OBJEXT
@ovindex OBJEXT
.cファイルが取り除かれた後で(訳註: ??)コンパイラの出力の元になる代用変
数@code{OBJEXT}を定義します。典型的にはUNIXなら@samp{o} に、Win32なら
@samp{obj}に設定します。
@end defmac

@defmac AC_MINGW32
@maindex MINGW32
MingW32コンパイラ環境のための検査をします。もしMingW32コンパイラ環境なら
ばシェル変数@code{MINGW32}を@samp{yes}に設定します。そうでないなら
@code{MINGW32}を空文字列に設定します。
@end defmac

@defmac AC_PATH_X
@maindex PATH_X
X Window Systemのincludeファイルとライブラリがどこにあるか調べます。
@code{configure}の呼び出し時に、ユーザが
@samp{--x-includes=@var{dir}}や@samp{--x-libraries=@var{dir}}を
指定していたら、指定されたディレクトリを使います。
片方または両方とも指定されていなかったら、
決まっていない値を、
簡単な@file{Imakefile}を@code{xmkmf}に食わせ、
生成された@file{Makefile}を調べることで定めます。
もしこれが(@code{xmkmf}がないとかの理由で)失敗したら、
一般的にX Window Systemが置かれるディレクトリを探します。
いずれかの方法で値が決まったら、
shell変数@code{x_includes}と@code{x_libraries}に結果を格納します。
ただし、ディレクトリがコンパイラのデフォルトサーチパスに入っている場合には
値は設定されません。

上記の方法でもディレクトリがわからなかった場合や、
ユーザが@samp{--without-x}を指定していた場合、
@code{no_x}を@samp{yes}に設定します。
@code{no_x}は@samp{yes}でなければ空になります。
@end defmac

@defmac AC_PATH_XTRA
@maindex PATH_XTRA
@ovindex X_CFLAGS
@ovindex X_LIBS
@ovindex X_EXTRA_LIBS
@ovindex X_PRE_LIBS
@code{AC_PATH_X}の拡張版です。
@code{X_CFLAGS}にXが必要とするCコンパイラのフラグを、
@code{X_LIBS}にリンカのフラグを設定します。
Xがない場合には@code{X_CFLAGS}に@samp{-DX_DISPLAY_MISSING}を追加します。

このマクロは、
Xを使うプログラムをコンパイルするときに特別なライブラリが必要なら、
それもチェックして@code{X_EXTRA_LIBS}に追加します。
X11R6特有のライブラリのうち@samp{-lX11}より前に指定しないといけない
ものがあったら、
それを@code{X_PRE_LIBS}に追加します。

@c This is an incomplete kludge.  Make a real way to do it.
@c If you need to check for other X functions or libraries yourself, then
@c after calling this macro, add the contents of @code{X_EXTRA_LIBS} to
@c @code{LIBS} temporarily, like this: (FIXME - add example)
@end defmac

@defmac AC_SYS_INTERPRETER
@maindex SYS_INTERPRETER
このシステムに、
「スクリプトファイルの先頭に@samp{#! /bin/csh}のような行を付け加えることで、
スクリプトを実行するshellを選択する」機能がついているかどうか調べます。
このマクロを使用したあとは、
@code{configure.in}の中に記述するshellスクリプトの中で、
shell変数@code{interpval}を使えます。
このshell変数の値はシステムが@samp{#!}をサポートしていれば@samp{yes}、
していなければ@samp{no}になります。
@end defmac

@defmac AC_SYS_LONG_FILE_NAMES
@maindex SYS_LONG_FILE_NAMES
@cvindex HAVE_LONG_FILE_NAMES
システムが14文字以上のファイル名をサポートしていたら、
@code{HAVE_LONG_FILE_NAMES}を定義します。
@end defmac

@defmac AC_SYS_RESTARTABLE_SYSCALLS
@maindex SYS_RESTARTABLE_SYSCALLS
@cvindex HAVE_RESTARTABLE_SYSCALLS
signalで割り込まれたシステムコールが自動で再開されるなら、
@code{HAVE_RESTARTABLE_SYSCALLS}を定義します。
@end defmac

@node UNIX Variants,  , System Services, Existing Tests
@section UNIX Variants

以下のマクロは、ヘッダファイルやライブラリに癖があるなどの理由で、
特別な取扱が必要なOSについてチェックします。
これらのマクロは無理矢理作った逃げ道です
(訳註: wartだから「目の上のたんこぶ」とか言ってもいいのだけれど、
それでは意味が通じない)。
本来はよりシステマチックに、ライブラリやヘッダファイルの内容および機能や、
OSで提供される環境について調べるべきです。

@defmac AC_AIX
@maindex AIX
@cvindex _ALL_SOURCE
OSがAIXだったら、@code{_ALL_SOURCE}を定義します。
BSDの機能の一部が使えます。
Cコンパイラを実行するマクロより前に使わないといけません。
@end defmac

@defmac AC_DYNIX_SEQ
@maindex DYNIX_SEQ
OSがDynix/PTX (Sequent UNIX)だったら、
@samp{-lseq}を出力変数@code{LIBS}に追加します。
このマクロはobsoleteです。
かわりに@code{AC_FUNC_GETMNTENT}を使いましょう。
@end defmac

@defmac AC_IRIX_SUN
@maindex IRIX_SUN
OSがIRIX (Silicon Graphics UNIX)だったら、
@samp{-lsun}を出力変数@code{LIBS}に追加します。
このマクロはobsoleteです。
@code{getmntent}を使いたいためにこのマクロを使っていたのなら、
@code{AC_FUNC_GETMNTENT}を使いましょう。
NISサポート入りのパスワード/gid系関数を使いたければ、
@samp{AC_CHECK_LIB(sun, getpwnam)}を使いましょう。
@end defmac

@defmac AC_ISC_POSIX
@maindex ISC_POSIX
@cvindex _POSIX_SOURCE
@ovindex CC
OSがPOSIXサポート入りのISC UNIX(POSIXized ISC UNIX)上だったら、
@code{_POSIX_SOURCE}を定義し、@samp{-posix}(GNU Cコンパイラ用)
または@samp{-Xp}(他のCコンパイラ用)を@code{CC}に追加します。
@code{AC_PROG_CC}より後で、しかもCコンパイラを呼び出す他のマクロより先に
呼び出さねばなりません。
@end defmac

@defmac AC_MINIX
@maindex MINIX
@cvindex _MINIX
@cvindex _POSIX_SOURCE
@cvindex _POSIX_1_SOURCE
OSがMinixだったら、@code{_MINIX}と@code{_POSIX_SOURCE}を定義し、
@code{_POSIX_1_SOURCE}を2に定義します。
こうするとPOSIXの機能が使えます。
Cコンパイラを実行するマクロより前に使わないといけません。
@end defmac

@defmac AC_SCO_INTL
@maindex SCO_INTL
@ovindex LIBS
OSがSCO UNIXだったら、@samp{-lintl}を@code{LIBS}に追加します。
このマクロはobsoleteです。
かわりに@code{AC_FUNC_STRFTIME}を使いましょう。
@end defmac

@defmac AC_XENIX_DIR
@maindex XENIX_DIR
@ovindex LIBS
OSがXenixだったら、@samp{-lx}を出力変数@code{LIBS}に追加します。
また、@file{dirent.h}が使われていたら、@samp{-ldir}を出力変数@code{LIBS}に
追加します。
このマクロはobsoleteです。
@code{AC_HEADER_DIRENT}を使いましょう。
@end defmac

@node Writing Tests, Results, Existing Tests, Top
@chapter Writing Tests

あなたの必要としている検査項目が既存のマクロで実現されていない場合、
自分であたらしいマクロを書かねばなりません。
以下のマクロは、マクロの基本部品です
以下のマクロは、他のマクロ内でOS/コンパイラの機能を検査したり、
結果を出力したりするのに使われています。

この章では、推奨されるマクロの書き方、
それから既存のマクロがどうして現在あるように記述されているのかについて
述べています。
既存のマクロがどのように書かれているのか見ることで、
どうやってAutoconfのマクロを記述すべきか学べるでしょう。
Autoconfのテストでなにかがうまくいかなかったら、
マクロがなにを仮定しているのか理解するのに
この章の内容が役立つかもしれません。
マクロが仮定していることを理解すれば、
マクロの問題点をどう解くべきなのかを知るにも役立つでしょう
(訳註: 相当意訳)。

以下のマクロは、Cコンパイラの出力を調べます。
以下のマクロは結果をキャッシュしません(@pxref{Caching Results})。
なぜなら、これらのマクロからは検査している内容がわからないし
キャッシュ変数名も決められないからです。
Cコンパイラの特定の機能を調べるマクロは、結果をキャッシュしますし、
なにを調べているのかメッセージも出力されます。

複数のソフトウェアパッケージで利用できる検査を書いた場合、
新しいマクロを定義するのがよいでしょう。
どうやるかは@xref{Writing Macros}参照。

@menu
* Examining Declarations::      Detecting header files and declarations.
* Examining Syntax::            Detecting language syntax features.
* Examining Libraries::         Detecting functions and global variables.
* Run Time::                    Testing for run-time features.
* Portable Shell::              Shell script portability pitfalls.
* Testing Values and Files::    Checking strings and files.
* Multiple Cases::              Tests for several possible values.
* Language Choice::             Selecting which language to use for testing.
@end menu

@node Examining Declarations, Examining Syntax, Writing Tests, Writing Tests
@section Examining Declarations

@code{AC_TRY_CPP}は特定のヘッダファイルが存在するか調べるためにあります。
ヘッダファイルひとつづつについて調べることもできますし、
ひとつの目的のために調べるのなら複数のヘッダファイルをまとめて
調べることもできます。

@defmac AC_TRY_CPP (@var{includes}, @r{[}@var{action-if-true} @r{[}, @var{action-if-false}@r{]]})
@maindex TRY_CPP
@var{includes}には
CまたはC++の@code{#include}文(訳註: ほんとは文じゃないね)と
定義文(訳註: @samp{#define}とか)を記述します。
他の文を記述しても構いませんが、多分意味ないでしょう。
@var{includes}のところにはshell変数、
backquote、backslashによる置換が働きます
(訳註: 置換を避けたければ@samp{[}と@samp{]}で囲め、ということです)。
プリプロセッサが処理中にエラーメッセージを出さなければ、
shellコマンド@var{action-if-true}が実行されます。
エラーがあれば@var{action-if-false}が実行されます。

このマクロは@code{CPPFLAGS}を使いますが、@code{CFLAGS}は使いません。
@samp{-g}とか@samp{-O}は多くのCプリプロセッサで無効だからです。
@end defmac

次のマクロはヘッダファイルに特定の定義(typedef、構造体、構造体メンバ、
関数プロトタイプ)が入っているかどうか調べます。
ヘッダファイルを直接@code{grep}せずに、@code{AC_EGREP_HEADER}を使いましょう。
システムによっては、調べたいシンボルが、あなたが@code{grep}している
ヘッダファイルから@samp{#include}されている他のヘッダファイルで
定義されているかもしれません。

@defmac AC_EGREP_HEADER (@var{pattern}, @var{header-file}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]})
@maindex EGREP_HEADER
@var{header-file}をCプリプロセッサに通した結果が@var{pattern}と
マッチすれば、@var{action-if-found}を実行します。
マッチしなければ、@var{action-if-not-found}を実行します。
@var{pattern}は@code{egrep}の正規表現です。
@end defmac

ヘッダファイルで定義されたり、Cプリプロセッサで前もって定義されている
Cプリプロセッサシンボルを調べる場合、
@code{AC_EGREP_CPP}を使いましょう。
以下に例題があります:

@example
AC_EGREP_CPP(yes,
[#ifdef _AIX
  yes
#endif
], is_aix=yes, is_aix=no)
@end example

@defmac AC_EGREP_CPP (@var{pattern}, @var{program}, @r{[}@var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex EGREP_CPP
@var{program}はCまたはC++のプログラムテキストです。
@var{program}のところにはshell変数、
backquote、backslashによる置換が働きます。
@var{program}をプリプロセッサに通した結果が@var{pattern}と
マッチすれば、@var{action-if-found}を実行します。
マッチしなければ、@var{action-if-not-found}を実行します。
@var{pattern}は@code{egrep}の正規表現です。

このマクロは、もしまだ呼ばれていないなら、
@code{AC_PROG_CPP}または@code{AC_PROG_CXXCPP}を呼び出します。
どちらを呼ぶかはどちらの言語を選んでいるかに依存します
(@pxref{Language Choice})。
@end defmac

@node Examining Syntax, Examining Libraries, Examining Declarations, Writing Tests
@section Examining Syntax

「特定のキーワードを認識するかどうか」など、
C、C++ や Fortran 77コンパイラの文法的な機能を調べるためには、
@code{AC_TRY_COMPILE}を使ってそのキーワードや機能を使う小さなプログラムを
コンパイルしてみましょう。
@code{AC_TRY_COMPILE}を使うと、特定のシステムにしかない
構造体や構造体メンバを調べることもできます。

@defmac AC_TRY_COMPILE (@var{includes}, @var{function-body}, @r{[}@var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex TRY_COMPILE
このマクロは、

関数の中身が@var{function-body}の記述からなるようなテスト用のC、C++、
Fortran 77プログラム(現在選択されている言語に依存 @pxref{Language
Choice})を書き出し、それがコンパイラでコンパイルできるかどうか調べます。

CとC++のため、@var{includes}は@var{function-body}のコードが必要とする、
あらゆる@code{#include}です(現在選択されている言語がFortran 77の場合は無
視されます)。このマクロは、現在選択されている言語がCやC++の場合、
@code{CFLAGS}や@code{CXXFLAGS}も使用し、コンパイル時には@code{CPPFLAGS} 
も使用します。Fortran 77が現在選択されている言語の場合、コンパイル時に
@code{FFLAGS}を使用します。

もしコンパイルできたなら、shellコマンド@var{action-if-found}を実行します。
もしできなかったら@var{action-if-not-found}を実行します。

このマクロはリンクを行おうとはしません(コンパイルしかしません)。
テストのためにリンクもしたい場合、@code{AC_TRY_LINK}を使ってください
(@pxref{Examining Libraries})。
@end defmac

@node Examining Libraries, Run Time, Examining Syntax, Writing Tests
@section Examining Libraries

ライブラリ、関数、またはグローバル変数を調べるために、
Autoconfの生成する@code{configure}スクリプトは、小さなプログラムを
コンパイルしてリンクしてみます。
Metaconfigは(デフォルトでは)Cライブラリに対し@code{nm}や@code{ar}を
実行することで提供されている関数を調べますが、
AutoconfはMetaconfigとは違います。
実際に関数をリンクしてみる方が判定方法として確実です。
なぜなら、@code{nm}や@code{ar}のさまざまなオプションや出力形式、
それから標準ライブラリの置き場所に関する差異を取り扱わなくて済みます。
クロスコンパイルできるかどうかも調べられます。
それに、必要なら関数の実行時の挙動を調べることもできます。
そのかわりに、実際関数をリンクしてみるのは、
ライブラリを一度調べればいい@code{nm}式よりも遅いです。

ごく少数のシステムでは、リンク時に発見できない関数があってもリンカが
「失敗」とのexitステータスを変えしません。
このようなシステムでは、Autoconfで生成されたスクリプトが使えません。
ただし、このようなシステムの一部では、特定のコマンドラインオプションを
与えるとリンカが正しくexitステータスを返すようになります。
Autoconfは現在この問題を自動的に解決していません。
ユーザがこの問題にであった場合、環境変数@code{LDFLAGS}にリンカが必要とする
オプションを設定して渡してやることで解決できるでしょう
(例えばMIPS RISC/OSの場合@samp{-Wl,-dn})。

関数とグローバル変数について調べるためには、@code{AC_TRY_LINK}を使って
テストプログラムをコンパイルしてみます。
このマクロはライブラリの検査(@pxref{Libraries})のために@code{AC_CHECK_LIB}の内部でも使われています。
このためには、@code{LIB}に調べたいライブラリ名を一時的に追加し、
テストプログラムをリンクしてみます。

@defmac AC_TRY_LINK (@var{includes}, @var{function-body}, @r{[}@var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex TRY_LINK
このマクロは、
現在選択されている言語(@pxref{Language Choice})によって、関数の中身が
@var{function-body}の記述からなるようなテスト用のCプログラムを書き出しま
す。

CやC++では、@var{include}は@var{function-body}のコードで必要となる任意の
@code{#include}文です(現在選択されている言語がFortran 77の場合は無< 視さ
れます)。もし現在選択されている言語がCやC++ならば、このマクロは
@code{CFLAGS}や@code{CXXFLAGS}も使用し、コンパイル時には、
@code{CPPFLAGS} も使用します。もしFortran 77が現在選択されている言語なら
ば、コンパイル時に@code{FFLAGS}を使用します。しかし、@code{LDFLAGS}と
@code{LIBS}は、全ての場合でリンク時に使います。

もし成功したなら、shellコマンド@var{action-if-found}を実行します。
もしできなかったら@var{action-if-not-found}を実行します。
@end defmac

@defmac AC_TRY_LINK_FUNC (@var{function}, @r{[}@var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex TRY_LINK_FUNC
現在の言語に依存して(@pxref{Language Choice})、本体がプロトタイプからな
り、@var{function}の呼び出しを含むプログラムの、コンパイルとリンクが可能
かどうかを知るために、テストプログラムを作ります。

もし成功したなら、shellコマンド@var{action-if-found}を実行します。
もしできなかったら@var{action-if-not-found}を実行します。
@end defmac

@defmac AC_TRY_LINK_FUNC (@var{function}, @r{[}@var{action-if-found} @r{[}, @var{action-if-not-found}@r{]]})
@maindex TRY_LINK_FUNC
@var{function}をリンクする、小さなプログラムのコンパイルとリンクを試みま
す。もしファイルのコンパイルとリンクが成功したならば、シェルコマンドの
@var{action-if-found}を実行し、それ以外では@var{action-if-not-found}を実
行します。
@end defmac

@defmac AC_COMPILE_CHECK (@var{echo-text}, @var{includes}, @var{function-body}, @var{action-if-found} @r{[}, @var{action-if-not-found}@r{]})
@maindex COMPILE_CHECK
これは@code{AC_TRY_LINK}に類似した、obsoleteなマクロです。
@code{AC_COMPILE_CHECK}は、@var{echo-text}が空でなければ、テストの前に
@samp{checking for @var{echo-text}}と標準出力に表示します。
テストの進行状況や結果を表示するには、
@code{AC_MSG_CHECKING}と@code{AC_MSG_RESULT}を使いましょう
(@pxref{Printing Messages})。
@end defmac

@node Run Time, Portable Shell, Examining Libraries, Writing Tests
@section Checking Run Time Behavior

システムの機能に癖やバグがある場合など、
システムが実行時にどう振舞うのか知らないといけないことがあります。
可能なら、コンパイル時でなしにパッケージの実行時に検査しましょう。
例えば、マシンのendianをプログラムの初期化時に調べることは可能です。

実行時のふるまいをどうしてもパッケージのコンパイル前に調べたい場合、
テストプログラムを書き、@code{AC_TRY_RUN}を使ってコンパイルして
実行し、結果を調べることができます。
可能な限りこの種のテストプログラムを使うことは避けましょう。
あなたのパッケージをクロスコンパイルできなくなります。

@menu
* Test Programs::               Running test programs.
* Guidelines::                  General rules for writing test programs.
* Test Functions::              Avoiding pitfalls in test programs.
@end menu

@node Test Programs, Guidelines, Run Time, Run Time
@subsection Running Test Programs

システムが実行時にどう振舞うのかをコンパイル時に調べるためには、
以下のマクロを使いましょう。

@defmac AC_TRY_RUN (@var{program}, @r{[}@var{action-if-true} @r{[}, @var{action-if-false} @r{[}, @var{action-if-cross-compiling}@r{]]]})
@maindex TRY_RUN
@var{program}にはCプログラムコードを指定します。
@var{program}に対してはshell変数やbackquoteによる置換が働きます。
@var{program}のコンパイルとリンクが成功し、
実行したときにexitステータス0が返ったら、
shellコマンド@var{action-if-true}を実行します。
さもなくば、@var{action-if-false}を実行します。
このとき、プログラムのexitステータスはshell変数@samp{$?}に入っています。
このマクロは
@code{CFLAGS}、@code{CXXFLAGS}、@code{CPPFLAGS}、@code{LDFLAGS}、それから
@code{LIBS}を利用します。

(クロスコンパイルしている等の理由で)現在使っているCコンパイラが、
@code{configure}を実行しているシステムで動かないコードを出力する場合には、
テストプログラムは実行されません。
省略可能なshellコマンド@var{action-if-cross-compiling}が指定された場合、
かわりにshellコマンドが実行されます。
@var{action-if-cross-compiling}が指定されていない場合には@code{configure}は
エラーメッセージを出力し終了します。
@end defmac

実行時の振舞いを調べられないクロスコンパイル時のために、
悲観的なデフォルト値を用意しておきましょう。
これは、
@code{AC_TRY_RUN}の最後の引数(@var{action-if-cross-compiling})を
与えることで達成できます。
@code{autoconf}は@code{configure}スクリプトを生成する際、
@var{action-if-cross-compiling}の指定のない@code{AC_TRY_RUN}があるたび
警告を出します。
警告を無視しても構いませんが、その場合ユーザはあなたのパッケージを
クロスコンパイルできなくなります。
Autoconfと一緒に配布されているマクロには、
このような警告を出すマクロがごく少数あります。

クロスコンパイルのためにパッケージを設定する場合、
正規化されたシステム名(@pxref{Manual Configuration})によって
@var{action-if-cross-compiling}で決める値を変えることができます。
または、各ターゲットシステムにあわせた正しい値を書いた
キャッシュファイルを置いておくこともできます(@pxref{Caching Results})。

@code{AC_TRY_RUN}は、Autoconf標準添付のマクロを含めて
他のマクロ内部から呼び出されることがあります。
このような場合に、クロスコンパイル時のためのデフォルト値を設定するためには、
@code{AC_TRY_RUN}より前に@code{AC_PROG_CC}を呼んでおくとよいでしょう。
@code{AC_PROG_CC}を呼んだあと、shell変数@code{cross_compile}が
@samp{yes}だったら、@code{AC_TRY_RUN}を呼ばず、
かわりの方法を使って設定結果の値を決めるのです。

@defmac AC_C_CROSS
@maindex C_CROSS
このマクロはobsoleteです。
何もしません。
@end defmac

@node Guidelines, Test Functions, Test Programs, Run Time
@subsection Guidelines for Test Programs

テストプログラムは標準出力になにも書き出してはいけません。
テストが成功したら0を、成功しなかったら0以外を返して@code{exit}すべきです。
これはテストの成功と、core dumpや他の理由によるテスト失敗とを
明確に区別するためです。
セグメンテーションフォールトやその他が起きたときにはexit statusは
0以外になります。
テストプログラムは関数@code{main}からの@code{return}でなしに
@code{exit}で終了すべきです。
一部のシステム(少なくとも古いSun)では関数@code{main}の返り値は無視されます。

テストプログラムは@code{#if}や@code{#ifdef}を使って、
既に実行された他のテストで定義されたプリプロセッサマクロを参照できます。
例えば、@code{AC_HEADER_STDC}を呼び出したら、
以後@file{configure.in}の中で記述するテストプログラムでANSI Cヘッダファイルを
@code{#include}することができます:

@example
@group
#if STDC_HEADERS
# include <stdlib.h>
#endif
@end group
@end example

テストプログラムがデータファイルを使ったり作ったりしないといけない場合、
@file{conftest}で始まるファイル名、例えば@file{conftestdata}を使いましょう。
@code{configure}スクリプトは、外部のテストプログラムが終了したときや
スクリプトが中断されたときに、@samp{rm -rf conftest*}を実行して
データファイルを消去します。

@node Test Functions,  , Guidelines, Run Time
@subsection Test Functions

テストプログラム中の関数定義をするときは、
C処理系の場合とC++処理系の場合とを条件分けして定義しなければなりません。
実際のところは、テストプログラム中で引数をとる関数を
使うことはめったにありません。

@example
#ifdef __cplusplus
foo(int i)
#else
foo(i) int i;
#endif
@end example

プロトタイプ宣言についても同様に条件分けしなければなりません。
C++処理系はC linkageの関数プロトタイプの前に@samp{extern "C"}が必要だからです
(訳註: ちょと補足)。
@samp{extern "C"}が入っていないようなヘッダファイルを
@code{#include}しないように注意してください。

@example
#ifdef __cplusplus
extern "C" void *malloc(size_t);
#else
char *malloc();
#endif
@end example

テストプログラム中で、(単に関数があるかないか調べるために)
不正な引数を使って関数を呼び出す場合、
間違って関数が呼び出されないように注意してプログラムを記述してください。
これは、目的の関数を、絶対呼び出されない関数@code{foo}の中から
呼び出すよう記述することで実現できます。
@code{exit}の後で目的の関数を呼び出すのではテストになりません。
GCCバージョン2は関数@code{exit}のあと処理が戻らないことを知っていて、
@code{exit}と同じブロックの以後の部分をコンパイルしない最適化を
するからです。

ヘッダファイルを@code{#include}して、その中でプロトタイプ宣言されている
関数を呼び出す場合、
プロトタイプ宣言違反でコンパイルエラーが発生しないよう、
(引数が単に0であっても)引数の個数は定義どおりにしてください。
GCCバージョン2では、インライン展開される一部の関数(@code{memcpy}とか)について
コンパイラ内部でプロトタイプ宣言を持っています。
このような関数の有無をチェックする場合、
正しい個数の引数を渡すか、@code{char}などに返り値を変えて再定義してください
(訳註: 返り値の宣言変えて意味あるのか?)。

@node Portable Shell, Testing Values and Files, Run Time, Writing Tests
@section Portable Shell Programming

自分でテストマクロを記述する場合、
shellスクリプトの移植性を高く保つためにいくつかの記法を使わないように
しないといけません。
Bourne shellと(BashやKorn shell等の)上位互換のshellは
長年発達してきましたが、トラブルを避けるため、
1977年ごろのUNIX version 7以降に追加された機能は使わないようにしてください。
shellスクリプト内関数、alias、character classの反転
(訳註: 「negated character classes」)、それから
必ずしも全てのBourne shell互換shellに入っていない機能は使うべきではありません。
最小公約数的なスクリプトを書くように心がけてください。
一部のshellでは@code{unset}すら使えません!
スクリプトインタプリタを指定するための@code{#!}の後には、
以下のようにスペースをつけてください:
@example
#! /usr/bin/perl
@end example
パス名の前のスペースがないと、
4.2BSD互換のシステム(Sequent DYNIXとか)では行は無視されます。
@samp{#! /}を4バイトのmagic nubmerとして解釈しているためです。

@code{configure}スクリプトからは、ごく少数の外部プログラムしか
呼び出してはいけません。
呼び出していいプログラムのリストは
@xref{Utilities in Makefiles, , Utilities in
Makefiles, standards, GNU Coding Standards}にあります。
この制限により、プログラム間の依存関係を最小限にとどめ、
ユーザがパッケージをインストールするために
前もって用意しないといけないプログラムを最小限に抑えることができます。

呼び出していい外部プログラムのリストに載っているプログラムについても、
最低限の共通な機能だけを使いましょう(訳註: すごく意訳)。
例えば、@code{ln}が@samp{-f}をサポートしているとか
@code{cat}にコマンドラインオプションがあるとか仮定してはいけません。
@code{sed}スクリプト内には、コメントや8文字以上のラベルがあってはいけません。
@samp{grep -s}で出力を抑制しようとしてはいけません。
System Vでは@samp{grep -s}は出力を抑制せず、エラーメッセージだけ
抑制するからです。
かわりに、@code{grep}の標準出力と標準エラー出力の両方を@file{/dev/null}に
リダイレクトしましょう
(標準エラー出力もリダイレクトするのは、エラー発生時に出力を出さないように
するためです)。
@code{grep}のexitステータスで、matchする文字列がみつかったかどうか
確認しましょう。

@node Testing Values and Files, Multiple Cases, Portable Shell, Writing Tests
@section Testing Values and Files

@code{configure}スクリプトは多くのファイルや文字列の特性を検査する必要が
あります。ここではそれら検査を行うときに用心するいくつかの移植性の問題を
あげます。

@code{test}プログラムは多くのファイルや文字列をテストする手段です。それ
はしばしば別の名前@samp{[}で実行されます。しかしAutoconfコードの中でその
名前を使うことはそれが@code{m4}のクォート文字の1つであるので災いを招きま
す。

@code{test}を使った多重検査が必要なら、@code{test}プログラムの演算子
@samp{-a}と@samp{-o}の代わりに、シェル演算子@samp{&&}と@samp{||}で組み合
わせてください。System V では@samp{-a}と@samp{-o}の優先順位が単項演算子
に関連して間違っています。したがってPOSIXはそれらを記していません。
だからそれらを使うことは移植性を損ないます。
もしあなたが@samp{&&}と@samp{||}を同じ文で組み合わせるなら、それらが
同じ優先順位を持つことを覚えておいてください。

@code{configure}スクリプトがクロスコンパイルをサポートできるようにするに
は、ターゲットシステムの代わりにホストシステムの特性を検査するべきではあ
りません。しかし、時々あなたはいくつかの恣意的なファイルが存在するかどう
かを検査する必要を見つけるかも知れません。そうするには@samp{test -f} や
@samp{test -r}を使います。@samp{test -x}を使っては行けません。なぜなら
4.3BSDそれを持たないので。

別の移植性を損なうシェルプログラミング構文は以下です。
@example
@var{var}=$@{@var{var}:-@var{value}@}
@end example
@noindent
その意味はまだ値が設定されていないときにだけ@var{var}に@var{value}を設定
し、@var{var}がなにか値を持っていれば、空文字列でさえ、そのままにしてお
きます。古いBSDのシェル、Ultrix @code{sh}を含みます、は、コロンを受け付けず、
不平を言って終了します。移植性のある同等なものは以下です。
@example
: $@{@var{var}=@var{value}@}
@end example

@node Multiple Cases, Language Choice, Testing Values and Files, Writing Tests
@section Multiple Cases

Some operations are accomplished in several possible ways, depending on
the UNIX variant.  Checking for them essentially requires a ``case
statement''.  Autoconf does not directly provide one; however, it is
easy to simulate by using a shell variable to keep track of whether a
way to perform the operation has been found yet.

UNIXの種類に依存して、いくつかの処理は可能な方法で達成されます。本質的に
それを調べるためには、``case文''が必要です。Autoconfは直接それを供給しま
せん。しかし、実行する処理が見つかったかどうかの追跡を記録するため、シェ
ル変数を使って簡単にシミュレーションができます。

ここに、調べる必要があるもののまだ残っているcaseの追跡を記録するため、シェ
ル変数@code{fstype}を使用する例があります。

@example
@group
AC_MSG_CHECKING(how to get filesystem type)
fstype=no
# The order of these tests is important.
AC_TRY_CPP([#include <sys/statvfs.h>
#include <sys/fstyp.h>], AC_DEFINE(FSTYPE_STATVFS) fstype=SVR4)
if test $fstype = no; then
AC_TRY_CPP([#include <sys/statfs.h>
#include <sys/fstyp.h>], AC_DEFINE(FSTYPE_USG_STATFS) fstype=SVR3)
fi
if test $fstype = no; then
AC_TRY_CPP([#include <sys/statfs.h>
#include <sys/vmount.h>], AC_DEFINE(FSTYPE_AIX_STATFS) fstype=AIX)
fi
# (more cases omitted here)
AC_MSG_RESULT($fstype)
@end group
@end example

@node Language Choice,  , Multiple Cases, Writing Tests
@section Language Choice

CとC++の両方を使うパッケージは、両方のコンパイラの特徴をテストする必要が
あります。Autoconfが生成した@code{configure}スクリプトは、デフォルトでC
の特徴を調べます。以下のマクロは@file{configure.in}のテストで、使ってい
る言語のコンパイラを決定します。

@defmac AC_LANG_C
@maindex LANG_C
@code{CC}と@code{CPP}を使うコンパイルテストを行い、拡張子が@file{.c}のテ
ストプログラムを使います。もし実行されたならば、@code{AC_PROG_CC}が求め
た値をシェル変数@code{cross_compiling}に、それ以外では空に設定します。
@end defmac

@defmac AC_LANG_CPLUSPLUS
@maindex LANG_CPLUSPLUS
@code{CXX}と@code{CXXCPP}を使うコンパイルテストを行い、拡張子が@file{.C} 
のテストプログラムを使います。もし実行されたならば、@code{AC_PROG_CC} が
求めた値をシェル変数@code{cross_compiling}に、それ以外では空に設定します。
@end defmac

@defmac AC_LANG_FORTRAN77
@maindex LANG_FORTRAN77
Do compilation tests using @code{F77} and use extension @file{.f} for
test programs.  Set the shell variable @code{cross_compiling} to the
value computed by @code{AC_PROG_F77} if it has been run, empty
otherwise.

@code{F77}を使うコンパイルテストを行い、拡張子が@file{.f}のテストプログ
ラムを使います。もし実行されたならば、@code{AC_PROG_CC}が求めた値をシェ
ル変数@code{cross_compiling}に、それ以外では空に設定します。
@end defmac

@defmac AC_LANG_SAVE
@maindex LANG_SAVE
(@code{AC_LANG_C}、@code{AC_LANG_CPLUSPLUS}や@code{AC_LANG_FORTRAN77}が
設定するように)現在の言語をスタックに覚えさせます。現在の言語を変更しま
せん。このマクロと@code{AC_LANG_RESTORE}は、特定の言語を一時的に切替える
必要があるマクロで使ってください。
@end defmac

@defmac AC_LANG_RESTORE
@maindex LANG_RESTORE
@code{AC_LANG_SAVE}が設定するように、スタックのトップに保存されている言
語を選択し、スタックから削除します。このマクロは、@code{AC_LANG_SAVE}が
最後に呼ばれた時、最も最近実行された@code{AC_LANG_C}、
@code{AC_LANG_CPLUSPLUS}や@code{AC_LANG_FORTRAN77}と同じです。

このマクロを@code{AC_LANG_SAVE}より多くの回数、呼び出さないでください。
@end defmac

@defmac AC_REQUIRE_CPP
@maindex REQUIRE_CPP
現在、テストに使われるプリプロセッサの存在を保証します。
@code{AC_PROG_CPP}や@code{AC_PROG_CXXCPP}の引数で、現在の言語に依存して、
@code{AC_REQUIRE}(@pxref{Prerequisite Macros})を呼び出してください。
@end defmac

@node Results, Writing Macros, Writing Tests, Top
@chapter Results of Tests

一度@code{configure}が特徴の存在を定義した場合、どのようにしてその情報を
記録するのでしょう。それは4種類あり、それらは、Cプリプロセッサシンボルの
定義、出力ファイルで変数をセット、@code{configure}実行時のキャッシュファ
イルに結果を保存、テスト結果をユーザーに知らせるメッセージの出力です。

@menu
* Defining Symbols::            Defining C preprocessor symbols.
* Setting Output Variables::    Replacing variables in output files.
* Caching Results::             Speeding up subsequent @code{configure} runs.
* Printing Messages::           Notifying users of progress or problems.
@end menu

@node Defining Symbols, Setting Output Variables, Results, Results
@section Defining C Preprocessor Symbols

特徴テストの応答をもたらす普通の行動は、テストの結果を示すCプリプロセッ
サシンボルを定義することです。それは@code{AC_DEFINE}や
@code{AC_DEFINE_UNQUOTED}と呼ばれるもので行います。

デフォルトで、@code{AC_OUTPUT}はマクロが定義したシンボルを出力変数
@code{DEFS}に置き、それぞれのシンボルで、それは
@samp{-D@var{symbol}=@var{value}}を含みます。Autoconf バージョン1と異な
り、@code{configure}が実行中に定義する変数@code{DEFS}はありません。
AutoconfマクロがあるCプリプロセッサシンボルを既に定義しているかどうか調
べるため、以下の例のように適切なキャッシュ変数の値をテストしてください。

@example
AC_CHECK_FUNC(vprintf, AC_DEFINE(HAVE_VPRINTF))
if test "$ac_cv_func_vprintf" != yes; then
AC_CHECK_FUNC(_doprnt, AC_DEFINE(HAVE_DOPRNT))
fi
@end example

@code{AC_CONFIG_HEADER}が呼び出される場合、@code{DEFS}を作る代わりにテン
プレートファイルに@code{#define}文で正しい値を代入したヘッダファイルを
@code{AC_OUTPUT}で作ってください。この種類の出力の詳細は、
@xref{Configuration Headers}.

@defmac AC_DEFINE (@var{variable} @r{[}, @var{value} @r{[}, @var{description}@r{]}@r{]})
@maindex DEFINE
Cプリプロセッサ変数@var{variable}を定義します。@var{value}が与えられる場
合は、@var{variable}にその値を(逐語的に)セットし、それ以外では1にセット
します。@var{value}は改行リテラルを含むべきではなく、
@code{AC_CONFIG_HEADER}を使わない場合は@code{make}が処理してしまうので、
@samp{#}文字を含めるべきではありません。シェル変数(@code{m4}の引用符文字
@samp{[}や@samp{]}を含む定義値が必要なもの)を使うために、代わりに
@code{AC_DEFINE_UNQUOTED}を使ってください。@var{description}は、
@code{AC_CONFIG_HEADER}を使う場合のみ役に立ちます。この場合、
@var{description}は、生成された@file{config.h.in}にマクロ定義前のコメン
トとして置かれます。マクロを@file{acconfig.h}に記述する必要はありません。
次の例は、Cプリプロセッサ変数@code{EQUATION}を文字定数 @samp{"$a > $b"}
と定義します。

@example
AC_DEFINE(EQUATION, "$a > $b")
@end example
@end defmac

@defmac AC_DEFINE_UNQUOTED (@var{variable} @r{[}, @var{value} @r{[}, @var{description}@r{]}@r{]})
@maindex DEFINE_UNQUOTED
@code{AC_DEFINE}に似ていますが、3つのシェル拡張は、@var{variable}と
@var{value}で一度だけ実行されるもので、変数の拡張(@samp{$})、コマンドの
代入(@samp{`})と、バックスラッシュエスケープ(@samp{\})です。値のシングル
とダブルクオートの文字列は特別な意味を持ちません。@var{variable}や
@var{value}がシェル変数の時は、@code{AC_DEFINE}の代わりにこのマクロを使っ
てください。以下が例です。

@example
AC_DEFINE_UNQUOTED(config_machfile, "$@{machfile@}")
AC_DEFINE_UNQUOTED(GETGROUPS_T, $ac_cv_type_getgroups)
AC_DEFINE_UNQUOTED($@{ac_tr_hdr@})
@end example
@end defmac

Bourneシェルの構文の特異性のため、@code{AC_DEFINE}や
@code{AC_DEFINE_UNQUOTED}の他のマクロやシェルコードからの呼び出しをるた
め、セミコロンを使わないでください。それは、@code{configure}スクリプトの
結果、構文エラーの原因となります。以下のようにします。

@example
AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4) LIBS="$LIBS -lelf")
@end example

@noindent
あるいはこのようにします。

@example
AC_CHECK_HEADER(elf.h,
  AC_DEFINE(SVR4)
  LIBS="$LIBS -lelf")
@end example

@noindent
この代わりです。

@example
AC_CHECK_HEADER(elf.h, AC_DEFINE(SVR4); LIBS="$LIBS -lelf")
@end example

@node Setting Output Variables, Caching Results, Defining Symbols, Results
@section Setting Output Variables

テストの結果を記録する一つの方法は、@dfn{出力変数}を設定することで、そ
れは、@code{configure}が出力したファイルの中で、値が代入されたシェル変数
です。以下の2つのマクロが新しい出力変数を作ります。利用可能な出力変数
のリストは、@xref{Preset Output Variables}.

@defmac AC_SUBST (@var{variable})
@maindex SUBST
シェル変数から出力変数を作ります。@code{AC_OUTPUT}は変数@var{variable} 
を出力ファイルに代入します(通常、一つ以上の@file{Makefile}です)。これは、
@code{AC_OUTPUT}が呼び出されたとき、@code{AC_OUTPUT}がシェル変数
@var{variable}の値を持つ入力ファイルの@samp{@@@var{variable}@@}のインス
タンスを置換することを意味します。@var{variable}の値は改行を含むべきでは
ありません。
@end defmac

@defmac AC_SUBST_FILE (@var{variable})
@maindex SUBST_FILE
シェル変数から出力ファイルを作るもう一つの方法です。出力ファイルに、シェ
ル変数@var{variable}で名付けられたファイルの内容を@code{AC_OUTPUT}に挿入
させます(代入ではありません)。これは、@code{AC_OUTPUT}が呼び出されたとき、
@code{AC_OUTPUT}が、シェル変数@var{variable}の値を持つ入力ファイルの内容
を(@file{Makefile.in}のような)出力ファイルの@samp{@@@var{variable}@@}の
インスタンスを置換することを意味します。挿入するファイルがない場合、変数
を@file{/dev/null}にセットしてください。

このマクロは、@file{Makefile}に特別な依存を含むフラグを挿入したり、特定
のホストやターゲットのための@code{make}ディレクティブを@file{Makefile} 
に挿入するとき役に立ちます。例えば、@file{configure.in}に以下を含ませま
す。

@example
AC_SUBST_FILE(host_frag)dnl
host_frag=$srcdir/conf/sun4.mh
@end example

@noindent
そして@file{Makefile.in}に以下を含ませます。

@example
@@host_frag@@
@end example
@end defmac

@node Caching Results, Printing Messages, Setting Output Variables, Results
@section Caching Results

様々な@code{configure}スクリプトで、同じ特徴を繰り返し調べる(あるは何度
も一つのスクリプトを実行する)ことを避けるため、@code{configure}は多くの
調査結果を@dfn{cache file}に保存します。@code{configure}スクリプト実行時
にキャッシュファイルを見つけた場合、前の実行結果をそれから読みだし、これ
らの再実行を避けます。結果として、@code{configure}は毎回調査を実行するよ
り早くなります。


@defmac AC_CACHE_VAL (@var{cache-id}, @var{commands-to-set-it})
@maindex CACHE_VAL
@var{cache-id}で識別した調査結果が利用可能だということを保証します。調査
結果が読み込まれたキャッシュファイルにあり、@code{configure}に
@samp{--quiet}や@samp{--silent}オプションが与えられていない場合、結果が
キャッシュされていることを示すメッセージを出力します。それ以外ではシェル
コマンド@var{commands-to-set-it}を実行します。これらのコマンドは設定され
た変数@var{cache-id}以外に副作用をしません。特に、そこで@code{AC_DEFINE}
を呼び出すべきではありません。@code{AC_CACHE_VAL}の呼び出しに続くコード
はキャッシュ値に基づきそれを行います。同様に、例えば
@code{AC_MSG_CHECKING}のメッセージを出力しません。@code{AC_CACHE_VAL}を
呼び出す前に行うので、調査結果がキャッシュから得られるかシェルコマンド実
行による定義からかにかかわらず、メッセージは出力されます。シェルコマンド
を値を決定するために実行する場合、値は@code{configure}が出力ファイルを作
る直前に、キャッシュファイルに保存されます。@var{cache-id}変数の名前の選
び方は、@xref{Cache Variable Names}.
@end defmac

@defmac AC_CACHE_CHECK (@var{message}, @var{cache-id}, @var{commands})
@maindex CACHE_CHECK
メッセージ出力に注意が必要な@code{AC_CACHE_VAL}のラッパーです。このマク
ロは、これらのマクロを使う最も普通の方法のための便利な略記法を提供します。
@var{message}のために@code{AC_MSG_CHECKING}を呼び出すと、@var{cache-id} 
と@var{commands}引数を伴う@code{AC_CACHE_VAL}と、@var{cache-id}を伴う
@code{AC_MSG_RESULT}を呼び出します。
@end defmac

@defmac AC_CACHE_LOAD
@maindex CACHE_LOAD
存在するキャッシュファイルから値をロードする、または、キャッシュファイル
がない場合、新しいキャッシュファイルを作ります。自動的に@code{AC_INIT} 
から呼び出されます。
@end defmac

@defmac AC_CACHE_SAVE
@maindex CACHE_SAVE
キャッシュファイルに全てのキャッシュ値を書き込みます。自動的に
@code{AC_OUTPUT}から呼び出されますが、@file{configure.in}のキーポイント
で@code{AC_CACHE_SAVE}を呼び出すため非常に役に立ちます。すぐにコンフィグ
レーションスクリプトが中断する場合、そのようなチェックポイントでキャッシュ
してください。
@end defmac

@menu
* Cache Variable Names::        Shell variables used in caches.
* Cache Files::                 Files @code{configure} uses for caching.
@end menu

@node Cache Variable Names, Cache Files, Caching Results, Caching Results
@subsection Cache Variable Names

キャッシュ変数名は以下のフォーマットにするべきです:

@example
@var{package-prefix}_cv_@var{value-type}_@var{specific-value}@r{[}_@var{additional-options}@r{]}
@end example

@noindent
たとえば、@samp{ac_cv_header_stat_broken}とか、
@samp{ac_cv_prog_gcc_traditional}などのようになります。
変数名の各部分の意味は以下のとおり:

@table @asis
@item @var{package-prefix}
パッケージまたは組織名の略称です; 小文字な点は違いますが、
ローカルに使用しているAutoconfのマクロ名のはじめのprefixと同じです。
Autoconf標準配布に入っているマクロのキャッシュ変数では、
@samp{ac}を使っています。

@item @code{_cv_}
このshell変数がキャッシュであることを示します。

@item @var{value-type}
キャッシュの値の種類です。合理的な名前づけシステムにするためについています。
Autoconfの使う種類名は@ref{Macro Names}に挙げられています。

@item @var{specific-value}
このテストが適応するキャッシュ値のクラスのメンバーです。例えば、関数
(@samp{alloca})、プログラム(@samp{gcc})や、出力変数(@samp{INSTALL})です。

@item @var{additional-options}
このテストが適応する特定のメンバーの特定の動作です。例えば、
@samp{broken}や@samp{set}です。名前のこの部分は適応されない場合は削除さ
れます。
@end table

キャッシュ変数に割り当てられた値は改行を含めてはいけません。通常、値は真
偽値(@samp{yes}や@samp{no})、あるいはファイルや関数の名前なので、重要な
制限ではありません。

@node Cache Files,  , Cache Variable Names, Caching Results
@subsection Cache Files

キャッシュファイルは、あるシステム上で実行されたconfigureのテスト結果を
蓄えるshellスクリプトです。これにより、configureスクリプト間、
または複数回のconfigureの実行の間でテスト結果を共有できます。
異なるシステム上ではキャッシュファイルは役にたちません。
もしキャッシュファイルの内容がなんらかの理由で不正になった場合、
ユーザはキャッシュファイルを削除したり編集したりできます。

デフォルトでは、configureは@file{./config.cache}をキャッシュファイルとして
使います。もしなければ新規に作成されます。@code{configure}は
キャッシュファイルの切替えのため、@samp{--cache-file=@var{file}}という
オプションを受け付けます; @code{configure}がサブディレクトリにある
@code{configure}スクリプトを呼び出す際には、このオプションを使って
スクリプト間でキャッシュを共有します。
@code{AC_CONFIG_SUBDIRS}マクロを使ってサブディレクトリの設定を
する方法については、@xref{Subdirectories}を参照してください。

@samp{--cache-file=/dev/null}とすることで、@code{configure}のデバッグのために
キャッシュを無効にできます。@file{config.status}は@samp{--recheck}
オプションが指定された場合を除いてキャッシュファイルを参照しません。
@file{config.status}に@samp{--recheck}には、@code{configure}が
再実行されます。デバッグ期間が長くなりそうな場合には、以下のように
キャッシュ関連マクロを@code{configure.in}の先頭で再定義することで、
@code{configure}スクリプトがキャッシュ読み込み/書き出しをしないように
できます。

@example
define([AC_CACHE_LOAD], )dnl
define([AC_CACHE_SAVE], )dnl
AC_INIT(@r{whatever})
@r{ ... rest of configure.in ...}
@end example

特定のシステム用のキャッシュファイルを配布しようとするのはよくないことです。
あまりにもエラーが発生しやすく、管理コストがあまりに高すぎます。
自動判別できないOS機能については、正規化されたシステムタイプ名を得て
リンクするファイルを選ぶ方法を使いましょう(@pxref{Manual Configuration}
参照)。この方法は標準化されています。

あるシステム向けのキャッシュファイルは、@code{configure}スクリプトを
実行するごとに内容が追加されていきます; 初期状態では空です。
@code{configure}を実行すると、@code{configure}は新しいテスト結果と
キャッシュファイルの内容をマージします。サイト向け初期化スクリプトの中で、
デフォルトで利用されるものでない、サイト単位のキャッシュファイルを
指定することができます。サイト単位のキャッシュファイルは、
同じCコンパイラが利用されている限り、透過的に働きます
(@pxref{Site Defaults}参照)。

configureスクリプトやconfigure.inから呼び出されるマクロがコンフィグレー
ションプロセスを中断する場合、数回のキーポイントでのキャッシュのチェック
ポイントは役に立ちます。そうすると、(希望通り)以前にエラーを引き起こした
部分を修正したコンフィグレーションスクリプトを再実行する時間を、大幅に削
除します。

@example
@r{ ... AC_INIT, etc. ...}
dnl checks for programs
AC_PROG_CC
AC_PROG_GCC_TRADITIONAL
@r{ ... more program checks ...}
AC_CACHE_SAVE

dnl checks for libraries
AC_CHECK_LIB(nsl, gethostbyname)
AC_CHECK_LIB(socket, connect)
@r{ ... more lib checks ...}
AC_CACHE_SAVE

dnl Might abort...
AM_PATH_GTK(1.0.2, , exit 1)
AM_PATH_GTKMM(0.9.5, , exit 1)
@end example

@node Printing Messages,  , Caching Results, Results
@section Printing Messages

@code{configure}スクリプトは、@code{configure}を実行しているユーザに
各種の情報を知らせる必要があります。以下のマクロは各種の状況に適した方法で
メッセージを出力します。以下の全てのマクロの引数は、shell用に
ダブルクォートで囲まれます。このため、shellは変数とbackquoteの置換を
行います。カンマを含むメッセージは、@code{m4}のquote文字である角括弧で
メッセージを囲めば出力できます。

@example
AC_MSG_RESULT([never mind, I found the BASIC compiler])
@end example

これらのマクロはshellコマンドの@code{echo}のwarpperです。
@code{configure}スクリプトでは、ほとんどの場合
ユーザにメッセージを出力するのに@code{echo}を直接使う必要はありません。
ここで挙げたマクロを使えば、メッセージの出力時期と出力されかたを
簡単に変えることができます。メッセージ出力マクロの定義を変えれば、
全ての呼び出し側マクロの出力を変えられます。

@defmac AC_MSG_CHECKING (@var{feature-description})
@maindex MSG_CHECKING
@code{configure}が、ある特定のOS機能をチェックしていることをユーザに
知らせます。このマクロは@samp{checking }ではじまり、@samp{...}で終る、
改行なしのメッセージを出力します。このマクロの後には@code{AC_MSG_RESULT}を
呼び出し、チェック結果と改行を出力する必要があります。
@var{feature-description}はたとえば
@samp{whether the Fortran compiler accepts C++ comments}とか、
@samp{for c89}とかがよいでしょう。

このマクロは@code{configure}が@samp{--quiet}オプション、または
@samp{--silent}オプションつきで実行された場合、なにも出力しません。
@end defmac

@defmac AC_MSG_RESULT (@var{result-description})
@maindex MSG_RESULT
ユーザにテスト結果を知らせます。@var{result-description}は
ほとんど常に、キャッシュ変数の値で、たいてい@samp{yes}か@samp{no}か
ファイル名になります。このマクロは@code{AC_MSG_CHECKING}に続いて
呼び出される必要があります。また、@var{result-description}に
指定するメッセージは@code{AC_MSG_CHECKING}の出力したメッセージを
終結させるさせるものでなければなりません。

このマクロは@code{configure}が@samp{--quiet}オプション、または
@samp{--silent}オプションつきで実行された場合、なにも出力しません。
@end defmac

@defmac AC_MSG_ERROR (@var{error-description})
@maindex MSG_ERROR
ユーザに@code{configure}が中断してしまうようなエラーに関して知らせます。
このマクロは標準エラー出力にエラーメッセージを出力し、
@code{configure}を終了します。exit statusは0でない値になります。
@var{error-description}はたとえば@samp{invalid value $HOME for \$HOME}
などのようなテキストがいいでしょう。
@end defmac

@defmac AC_MSG_WARN (@var{problem-description})
@maindex MSG_WARN
@code{configure}のユーザに問題になり得る点を知らせます。
このマクロは標準エラー出力にメッセージを出力します;
@code{configure}は以後も実行を続けます。
ので、@code{AC_MSG_WARN}を呼び出すマクロは、
警告する内容に関して、デフォルトの(代用の)ふるまいを
提供するべきです。@var{problem-description}はたとえば
@samp{ln -s seems to make hard links}のようなテキストがいいでしょう。
@end defmac

以下のふたつのマクロはobsoleteです。
@code{AC_MSG_CHECKING}や@code{AC_MSG_RESULT}を使いましょう。

@defmac AC_CHECKING (@var{feature-description})
@maindex CHECKING
このマクロは@code{AC_MSG_CHECKING}と似ていますが、@code{AC_CHECKING}は
@var{feature-description}のあとに改行を出力します。
このマクロは主に、複数並んだOS機能チェックの全体としての目的を
出力するのに使えます。たとえば:

@example
AC_CHECKING(if stack overflow is detectable)
@end example
@end defmac

@defmac AC_VERBOSE (@var{result-description})
@maindex VERBOSE
このマクロは@code{AC_MSG_RESULT}と似ています。
ただし、@code{AC_VERBOSE}は@code{AC_MSG_CHECKING}ではなく、
@code{AC_CHECKING}に続いて呼び出される、という点だけが違います。
メッセージはtabに続いて出力されます。
このマクロはobsoleteです。
@end defmac

@node Writing Macros, Manual Configuration, Results, Top
@chapter Writing Macros

複数のソフトウェアパッケージに適用できるOS機能のテストマクロを記述
する場合、新しいマクロとして定義するのが最もよい方法です。
以下ではAutoconfマクロを記述するための手順とガイドラインを示します。

@menu
* Macro Definitions::           Basic format of an Autoconf macro.
* Macro Names::                 What to call your new macros.
* Quoting::                     Protecting macros from unwanted expansion.
* Dependencies Between Macros::  What to do when macros depend on other macros.
@end menu

@node Macro Definitions, Macro Names, Writing Macros, Writing Macros
@section Macro Definitions

@maindex DEFUN
Autoconfのマクロは@code{AC_DEFUN}マクロを使って定義されます。
これは@code{m4}の@code{define}マクロと類似しています。
@code{AC_DEFUN}はマクロを定義する際に、マクロの呼び出し順を
制約するためのコードを加えます(@pxref{Prerequisite Macros}参照)。

Autoconfマクロの定義は以下のようになります:

@example
AC_DEFUN(@var{macro-name}, [@var{macro-body}])
@end example

@noindent
角括弧はオプショナルという意味ではありません; 角括弧はマクロ展開の
問題を避けるため、実際に字面の上でもマクロ定義に記述される必要があります
(@pxref{Quoting}参照)。マクロに渡される引数は、@samp{$1}や@samp{$2}として
参照できます。

@code{m4}プログラム内にコメントを記述するためには、@code{m4}組み込みの
@code{dnl}を使ってください; これは@code{m4}に次の改行までのテキストを
無視させます。@file{acsite.m4}と@file{aclocal.m4}の中のマクロ定義の間には
@code{dnl}は必要ありません。@code{AC_INIT}が呼び出されるまでの出力は
無視されるからです。

@code{m4}マクロを書く詳細は、@xref{Definitions, , How to define new
macros, m4.info, GNU m4}.

@node Macro Names, Quoting, Macro Definitions, Writing Macros
@section Macro Names

Autoconfマクロの名前は、他の文字列との衝突を避けるため、
全て大文字で、@samp{AC_}で始まっています。内部で使われるshell変数は
なるべく全部小文字で、@samp{ac_}で始まっています。
既存の/将来のAutoconfマクロと衝突しないために、
自分で定義するマクロの名前およびshell変数の名前には、
先頭に別の文字列を使うべきです。例えばあなたのイニシャル、組織名や
ソフトウェアパッケージの名前の略称などが考えられます。

Autoconfマクロの名前は、ほとんどの場合構造化された名前づけ規則に
したがっています。名前はチェックされるOSの機能を示しています。
マクロ名は下線で区切られたいくつかの単語からなり、各単語は
一般的なものから特殊なものへと並んでいます。マクロに対する
キャッシュ変数の名前もおなじ規則を使っています(より詳しくは
@pxref{Cache Variable Names}参照)。

@samp{AC_}の次にある単語は、調べる対象のOS機能のカテゴリを示しています。
ここに、書く可能性の高いマクロの種類のテストマクロを指定するため、
Autoconfが使うカテゴリがあります。それらはキャッシュ変数でも全て小文字で
使われます。適用可能なものを使ってください。無ければ独自のカテゴリを考え
出してください。

@table @code
@item C
C言語組み込みの特徴。
@item DECL
ヘッダファイルでのC変数の宣言。
@item FUNC
ライブラリの関数。
@item GROUP
ファイルのUNIXグループオーナー。
@item HEADER
ヘッダファイル。
@item LIB
Cライブラリ。
@item PATH
プログラムを含むファイルのフルパス名。
@item PROG
プログラムのベース名。
@item STRUCT
ヘッダファイルのC構造体の定義。
@item SYS
OSの特徴。
@item TYPE
C組み込みや宣言タイプ。
@item VAR
ライブラリのC変数。
@end table

カテゴリ名の次には、テスト対象のOS機能の名前が来ます。
それ以降の単語はそれぞれOSの機能の持つ特定の意味を表しています。
例えば、@code{AC_FUNC_UTIME_NULL}は@code{utime}関数の引数に
@code{NULL}を与えたときのふるまいをチェックします。

あるマクロの内部サブルーチンとして動作するマクロには、
呼び元マクロ名のあとに、マクロが行うことがらを意味する
ひとつ以上の単語をつけた名前をつけるのがよいです。
たとえば、@code{AC_PATH_X}は@code{AC_PATH_X_XMKMF}と
@code{AC_PATH_X_DIRECT}を内部で呼び出すマクロとして使います。

@node Quoting, Dependencies Between Macros, Macro Names, Writing Macros
@section Quoting

他のマクロに呼び出されるマクロは@code{m4}によって複数回評価されます;
通常の文字列がマクロや@code{m4}組み込み命令(たとえば@samp{define}や
@samp{$1})と勘違いされて評価されないように、各評価ごとにもう1重
quoteする必要があるかもしれません。また、カンマを含むマクロの
引数についてはquoteする必要があります。なぜなら、カンマは各引数を
区切るのに使われるからです。改行を含むマクロの引数を与える場合や、
他のマクロを呼び出す場合にはquoteする方がいいでしょう。

Autoconfは、@code{m4}のquote文字を、デフォルトの@samp{`}と@samp{'}から
@samp{[}と@samp{]}に変更しています。これは多くのマクロで
@samp{`}と@samp{'}は対応せずに使われているからです。しかしながら、
ときどき角カッコをマクロ内で使用する必要が出る場合があります
(Cプログラムソースや正規表現など)。そのような場合、@code{m4}の
組み込み命令@code{changequote}を使って一時的にquote文字を@samp{<<}と
@samp{>>}に切替えます(quoteを全く必要としない場合、quote文字に空文字を
指定することでquoteの機能を殺すこともできます)。
以下、例題です:

@example
AC_TRY_LINK(
changequote(<<, >>)dnl
<<#include <time.h>
#ifndef tzname /* For SGI.  */
extern char *tzname[]; /* RS6000 and others reject char **tzname.  */
#endif>>,
changequote([, ])dnl
[atoi(*tzname);], ac_cv_var_tzname=yes, ac_cv_var_tzname=no)
@end example

@code{configure}を新しく書いたマクロを使って生成する場合、
マクロ内にquoteを増やす必要があるかないか注意深く確認しましょう。
もしひとつ異常の単語が@code{m4}の出力から落ちていたら、
quoteする必要があります。疑わしいときはとりあえずquoteしましょう。

しかし、quoteしすぎてしまう場合もあります。このような場合、
出力された@code{configure}スクリプトは展開されないままのマクロを
含んでいます。@code{autoconf}はこのような場合を検出するために、内部で
@samp{grep AC_ configure}を実行します。

@node Dependencies Between Macros,  , Quoting, Writing Macros
@section Dependencies Between Macros

Autoconfマクロの一部は、正常な動作のために他のマクロが先に呼ばれていることを
仮定しています。Autoconfは特定のマクロを必要な場合にだけ呼び出したり、
正常に動作しない可能性のある順でマクロが呼び出された場合に
警告したりする方法を提供しています。

@menu
* Prerequisite Macros::         Ensuring required information.
* Suggested Ordering::          Warning about possible ordering problems.
* Obsolete Macros::             Warning about old ways of doing things.
@end menu

@node Prerequisite Macros, Suggested Ordering, Dependencies Between Macros, Dependencies Between Macros
@subsection Prerequisite Macros

一部のマクロは、他のマクロで求められた値を必要とすることがあります。
例えば、@code{AC_DECL_YYTEXT}は@code{flex}や@code{lex}の出力
結果を調べます。このため、shell変数@code{LEX}を設定するために
@code{AC_PROG_LEX}マクロが先に呼ばれている必要があります。

@code{AC_REQUIRE}マクロを使う事で、ユーザにマクロ間の依存関係を
管理させずに済みます。つまり、自動化できます。@code{AC_REQUIRE}を
使うと、あるマクロを必要な場合にだけ、かつ1度だけ呼び出すことができます。

@defmac AC_REQUIRE (@var{macro-name})
@maindex REQUIRE
もし@var{macro-name}という名前の@code{m4}マクロが
まだ呼び出されていなかったら、そのマクロを
(引数なしで)呼び出します。@var{macro-name}を
角カッコでquoteするのを忘れないでください。
@var{macro-name}に指定されるマクロは
@code{AC_DEFUN}で前もって定義されているか、
@code{AC_PROVIDE}の呼び出しを含んでいるかする
必要があります。これは@var{macro-name}が
呼び出されたことを検出するため必要です。
@end defmac

@code{AC_DEFUN}を使うかわりに、@code{define}を使ってマクロを定義し、
中で@code{AC_PROVIDE}を呼び出すこともできます。この技法は
メッセージのネストを防ぐ事ができないので、obsoleteです。

@defmac AC_PROVIDE (@var{this-macro-name})
@maindex PROVIDE
マクロ@var{this-macro-name}が呼び出されたことを
記録します。@var{this-macro-name}は@code{AC_PROVIDE}
マクロを呼び出すマクロの名前でなければなりません
@code{m4}の組み込み変数@code{$0}を使うと簡単に
マクロの名前を得る事ができます。たとえばこんな風:

@example
AC_PROVIDE([$0])
@end example
@end defmac

@node Suggested Ordering, Obsolete Macros, Prerequisite Macros, Dependencies Between Macros
@subsection Suggested Ordering

あるふたつのマクロについて、両方が呼び出される場合には片方が先に
呼び出されなければならないが、どちらも他方が呼び出されることを
必須としない場合があります。たとえば、Cコンパイラのふるまいを
変えるマクロはCコンパイラを呼び出すマクロ以前に呼び出される
必要があります。このような依存関係の多くはこの文書に記されています。

Autoconfはこのような場合のために@code{AC_BEFORE}マクロを提供しています。
これは、依存関係があるマクロが@file{configure.in}中に逆順で現れた
場合に、ユーザに警告します。警告メッセージは@code{configure}を実行する
ときではなく、@code{configure.in}から@code{configure}を生成するときに
出力されます。
例えば、@code{AC_PROG_CPP}マクロは、Cコンパイラに@samp{-E}
オプションをつけたときにCプリプロセッサを実行してくれるかを
調べます。このため、このマクロは利用されるCコンパイラを変更するような
マクロ、たとえば@code{AC_PROG_CC}などより後に呼び出される必要があります。
このため、@code{AC_PROG_CC}は以下の文を含んでいます:

@example
AC_BEFORE([$0], [AC_PROG_CPP])dnl
@end example

@noindent
この文を使うと、@code{AC_PROG_CC}が呼ばれた時点で@code{AC_PROG_CPP}が
既に呼ばれていた場合、ユーザに警告がでます。

@defmac AC_BEFORE (@var{this-macro-name}, @var{called-macro-name})
@maindex BEFORE
マクロ@var{called-macro-name}が既に呼び出されていた
場合、@code{m4}が標準エラー出力に警告メッセージを
出力するようにします。@var{this-macro-name}は
マクロ@code{AC_BEFORE}を呼び出すマクロの名前である
必要があります。@var{called-macro-name}に
指定されるマクロは@code{AC_DEFUN}で前もって
定義されているか、@code{AC_PROVIDE}の呼び出しを
含んでいるかする必要があります。これは
@var{called-macro-name}が呼び出されたことを
検出するため必要です。
@end defmac

@node Obsolete Macros,  , Suggested Ordering, Dependencies Between Macros
@subsection Obsolete Macros

自動設定および移植性向上のための技法は数年かけて徐々に進化しています。
しばしば、ある問題を解決するためのよりよい方法が開発されたり、
やっつけ仕事が系統だてて整理されたりします。このような変化は
Autoconfの多くの部分で置きました。この結果、一部のマクロは
@dfn{obsolete}とされるようになりました; それらのマクロは
動作はしますが、最適なやりかたではなくなりました。
Autoconfは@code{AC_OBSOLETE}マクロを用意しています。
このマクロは、@code{configure}スクリプトを作っているユーザが
obsoleteなマクロを使用した場合に警告し、あたらしいマクロに
移行するよう勧めます。使用例はこんなかんじ:

@example
AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl
@end example

@defmac AC_OBSOLETE (@var{this-macro-name} @r{[}, @var{suggestion}@r{]})
@maindex OBSOLETE
@code{m4}から標準エラー出力へ、マクロ
@var{this-macro-name}はobsoleteだ、という
メッセージを出力させます。また、マクロが
使用されたファイル名と行番号も
出力されます。@var{this-macro-name}は
@code{AC_OBSOLETE}を呼び出しているマクロの
名前である必要があります。もし@var{suggestion}が
指定されていたら、警告メッセージの末尾に
指定された文字列が出力されます;
例えば、@var{this-macro-name}のかわりに
使うべきマクロ名などがいいでしょう。
@end defmac

@node Manual Configuration, Site Configuration, Writing Macros, Top
@chapter Manual Configuration

一部のOS機能は、テストプログラムを実行しても自動的に判定できません。
たとえば、オブジェクトファイルのフォーマットや、コンパイラや
リンカに渡さねばならない特殊なオプションなどがそうです。
@code{uname}の出力結果を調べたり、特定のシステムにしかない
ライブラリを調べるなどのアドホックな手段を使って、
このようなOSの機能をチェックすることができます。
Autoconfは推測することのできないOS機能の判定のために、
統一された方法を提供しています。

@menu
* Specifying Names::            Specifying the system type.
* Canonicalizing::              Getting the canonical system type.
* System Type Variables::       Variables containing the system type.
* Using System Type::           What to do with the system type.
@end menu

@node Specifying Names, Canonicalizing, Manual Configuration, Manual Configuration
@section Specifying the System Type

他のGNU @code{configure}スクリプトと同様、
Autoconfによって生成された@code{configure}
スクリプトは正規化されたシステムタイプ名によって
動作を決定することができます。
システムタイプ名は以下のフォーマットになっています:

@example
@var{cpu}-@var{company}-@var{system}
@end example

@code{configure}は通常、@code{configure}の動作している
システムタイプ名を判定することができます。このために、
@code{configure}は@code{config.guess}というスクリプトを実行します。
このスクリプトは@code{uname}コマンドや、Cプリプロセッサが
あらかじめ定義しているシンボルを使ってシステムタイプ名を
割り出します。

あるいは、ユーザは@code{configure}のコマンドライン引数に
システムタイプ名を指定することができます。
クロスコンパイル時にはこれは必ず必要です。
最も複雑な場合、3つのシステムタイプ名が関係します。
これらを指定するためのオプションは以下のとおり:

@table @code
@item --build=@var{build-type}
パッケージを自動設定し、コンパイルするマシンのシステムタイプ名
(ほとんどの場合必要ないです);

@item --host=@var{host-type}
パッケージが実行されるシステムタイプ名;

@item --target=@var{target-type}
パッケージ中のコンパイラ関連ツールがコード生成を行う場合、
生成するコード種別のシステムタイプ名。
@end table

@noindent
ユーザが(オプション名なしで)システムタイプ名を@code{configure}の
引数として与えた場合、その値がhost/target/buildのシステムタイプ名の
デフォルト値として使われます。@samp{--build}などのオプションを指定
しなかった場合、この値が使われます。targetとbuildのシステムタイプ名は、
targetまたはbuildを指定せずにhostを指定した場合、
hostのシステムタイプ名と同一になります。
クロスコンパイルを行う場合、クロスコンパイル用ツール、特にCコンパイラの
名前を、@code{configure}のコマンドラインに指定する必要があります。
たとえば以下のように:

@example
CC=m68k-coff-gcc configure --target=m68k-coff
@end example

@code{configure}は多くのシステムタイプについて、短い別名も認識します。
たとえば、@samp{decstation}を@samp{mips-dec-ultrix4.2}のかわりに
コマンドラインに指定することができます。@code{configure}は
システムタイプ名の正規化のため、@code{config.sub}というスクリプトを
実行します。

@node Canonicalizing, System Type Variables, Specifying Names, Manual Configuration
@section Getting the Canonical System Type

以下のマクロを使うと、@code{configure}スクリプトの中でシステムタイプを
知ることができます。これらのマクロは@code{config.guess}というshell
スクリプトを実行します。これにより、ユーザが指定しなかった、host/
target/buildシステムタイプ名などの情報を得ます。また、@code{config.sub}を
実行することでユーザの指定したシステムタイプの別名を正規化します。
以下のマクロを利用する場合、これら2つのshellスクリプトをソースコードと
ともに配布する必要があります。@code{configure}がこれらの
スクリプトを探すディレクトリを指定するためのマクロ、
@code{AC_CONFIG_AUX_DIR}については@xref{Output}参照。
以下のマクロを利用しなかった場合、@code{configure}は
指定された@samp{--host}、@samp{--target}および@samp{--build}の
オプションを無視します。

@defmac AC_CANONICAL_SYSTEM
@maindex CANONICAL_SYSTEM
システムタイプを判定し、正規化されたシステムタイプ名を
出力変数に設定します。設定される変数については
@xref{System Type Variables}を参照。
@end defmac

@defmac AC_CANONICAL_HOST
@maindex CANONICAL_HOST
@code{AC_CANONICAL_SYSTEM}の一部、ホストタイプに関する
部分だけを実行します。プログラムがコンパイラ関連の
ツールでなければ、このマクロのやることだけでことが足ります。
@end defmac

@defmac AC_VALIDATE_CACHED_SYSTEM_TUPLE (@var{cmd})
@maindex VALIDATE_CACHED_SYSTEM_TUPLE
キャッシュファイルが、現在のホスト、ターゲットとビルドシステムに一致しな
い場合、@var{cmd}を実行する、または、デフォルトエラーメッセージを出力し
ます。

@end defmac

@node System Type Variables, Using System Type, Canonicalizing, Manual Configuration
@section System Type Variables

@code{AC_CANONICAL_SYSTEM}を呼び出すと、以下の出力変数に
システムタイプの情報が設定されます。@code{AC_CANONICAL_HOST}の
実行語は、変数@code{host}だけが設定されます。

@table @code
@ovindex build
@ovindex host
@ovindex target
@item @code{build}, @code{host}, @code{target}
正規化されたシステム名;

@item @code{build_alias}, @code{host_alias}, @code{target_alias}
@ovindex build_alias
@ovindex host_alias
@ovindex target_alias
ユーザが指定したシステム名、または@code{config.guess}が
使われた場合には正規化されたシステム名;

@item @code{build_cpu}, @code{build_vendor}, @code{build_os}
@itemx @code{host_cpu}, @code{host_vendor}, @code{host_os}
@itemx @code{target_cpu}, @code{target_vendor}, @code{target_os}
@ovindex build_cpu
@ovindex host_cpu
@ovindex target_cpu
@ovindex build_vendor
@ovindex host_vendor
@ovindex target_vendor
@ovindex build_os
@ovindex host_os
@ovindex target_os
正規化された名前の特定の部分だけが(便利のために)設定されます。
@end table

@node Using System Type,  , System Type Variables, Manual Configuration
@section Using the System Type

正規化されたシステムタイプをどう使いますか?  たいていは、システム依存の
Cファイルを選択するために、@file{configure.in}の中のひとつまたは
複数の@code{case}文で使います。そのようなファイルにはシステム名を
もとにした名前をつけておきます。その後、
@file{host.h}や@file{target.c}などの汎用的な名前で
そのファイルへの(シンボリック)リンクを作ります。
@code{case}文のパターンには以下のように、shellのワイルドカードが使えます。
ので、複数の場合をまとめて扱えます:

@example
case "$target" in
i386-*-mach* | i386-*-gnu*) obj_format=aout emulation=mach bfd_gas=yes ;;
i960-*-bout) obj_format=bout ;;
esac
@end example

@defmac AC_LINK_FILES (@var{source}@dots{}, @var{dest}@dots{})
@maindex LINK_FILES
@code{AC_OUTPUT}の際に、既存のファイル@var{source}に対する
@var{dest}という名前のリンクを作ります。リンクの種類は可能なら
シンボリックリンク、さもなくばハードリンクになります。
@var{dest}と@var{source}に指定されるファイル名は
ソースコードのトップレベルから、またはビルドディレクトリからの
相対表記でなければなりません。
このマクロは複数回呼んでも構いません。

例えば、以下を使うと:

@example
AC_LINK_FILES(config/$@{machine@}.h config/$@{obj_format@}.h, host.h object.h)
@end example

@noindent
現在のディレクトリに@file{host.h}という
@file{@var{srcdir}/config/$@{machine@}.h}へのリンクと、
@file{object.h}という@file{@var{srcdir}/config/$@{obj_format@}.h}への
リンクを作成します。
@end defmac

ホストのシステムタイプを使って、クロスコンパイル用のツールを
みつけることができます。@code{AC_CHECK_TOOL}マクロがそのために
する内容については、@xref{Generic Programs}参照。

@node Site Configuration, Invoking configure, Manual Configuration, Top
@chapter Site Configuration

@code{configure}スクリプトでは、パッケージがインストールされる場面ごとに
設定の一部を変えるための機能を備えています(訳註: 意訳)。
外部プログラムパッケージの置かれている場所を指定したり、
オプションの機能を含めたり外したり、プログラムを
デフォルトの名前以外でインストールしたり、
@code{configure}のオプションの既定値を定めたりするための方法が
用意されています。

@menu
* External Software::           Working with other optional software.
* Package Options::             Selecting optional features.
* Site Details::                Configuring site details.
* Transforming Names::          Changing program names when installing.
* Site Defaults::               Giving @code{configure} local defaults.
@end menu

@node External Software, Package Options, Site Configuration, Site Configuration
@section Working With External Software

ソフトウェアパッケージが他のソフトウェアパッケージを必要としたり、
あるいは特定の場合だけ利用したりすることがあります。
ユーザは@code{configure}を呼び出す際のコマンドラインオプションにより、
どのソフトウェアパッケージを利用するかを指定できます。
オプションは以下のいずれかの形式をしています:

@example
--with-@var{package}@r{[}=@var{arg}@r{]}
--without-@var{package}
@end example

例えば、@samp{--with-gnu-ld}は他のリンカでなく、GNUリンカを
利用することを指示します。
@samp{--with-x}はX Window Systemを利用することを指示します。

ユーザは、パッケージ名の後に@samp{=}に続いて引数を渡すことができます。
パッケージ名の後ろに@samp{no}を与えると、デフォルトで利用される
パッケージを利用させなくすることがえきます。
@samp{yes}でも@samp{no}でもない引数は、
より細かく外部パッケージを指定するため、
外部パッケージのパッケージ名やバージョン番号を指定するのに使えるでしょう。
引数が与えられなかった場合、@samp{yes}が与えられたのとおなじことになります。
@samp{--without-@var{package}}は
@samp{--with-@var{package}=no}とおなじです。

@code{configure}スクリプトは、サポートされていないパッケージについて
@samp{--with-@var{package}}が指定されてもエラーを出しません。
複数のソフトウェアパッケージをトップレベルの@code{configure}
スクリプトでまとめて設定する場合のためにこのような動作になっています。
これにより、各ソフトウェアパッケージが異なるオプションを要求している場合でも、
余計なエラー出力なしで設定できます。
残念な副作用として、オプションの綴ミスはチェックされません。

@code{configure}スクリプトを
呼び出したユーザがどんなオプションを指定したか知るためには、
各外部ソフトウェアパッケージについて、
@file{configure.in}中で@code{AC_ARG_WITH}を呼び出す必要があります。
各パッケージがデフォルトで利用されるかされないか、またどんな引数が有効かは
@file{configure.in}を書くあなたまかせです。

@defmac AC_ARG_WITH (@var{package}, @var{help-string} @r{[}, @var{action-if-given} @r{[}, @var{action-if-not-given}@r{]]})
@maindex ARG_WITH
@code{configure}スクリプトにユーザが
@samp{--with-@var{package}}や
@samp{--without-@var{package}}のような
コマンドラインオプションを与えた場合、
shellコマンド@var{action-if-given}を実行します。
もしどちらも与えられなかった場合、
@var{action-if-not-given}を実行します。
@var{package}は外部ソフトウェアパッケージの名前を示します。
@var{package}は英数字とマイナス記号だけでできている必要があります。

コマンドラインオプションの引数は、
shellコマンド@var{action-if-given}の中から
shell変数@code{withval}として参照できます。
@code{withval}の値はshell変数@code{with_@var{package}}
(パッケージ名中の@samp{-}は@samp{_}に変換されます)の
値とおなじですので、どちらを使っても構いません。

@var{help-string}はオプションの概説です。
例えば以下のようにします:
@example
  --with-readline         support fancy command line editing
@end example
@noindent
@var{help-string}は必要なら2行以上にわたっても構いません。
@samp{configure --help}を実行したとき、桁が揃うようにしてください。
@var{help-string}中にはtab文字は使わないでください。
行の先頭にスペースを含めるためには、@samp{[}と@samp{]}でくくる
必要があるでしょう。
@end defmac

@defmac AC_WITH (@var{package}, @var{action-if-given} @r{[}, @var{action-if-not-given}@r{]})
@maindex WITH
これは、@code{AC_ARG_WITH}の古いバージョンです。
@var{help-string}が使えません。
@end defmac

@node Package Options, Site Details, External Software, Site Configuration
@section Choosing Package Options

ソフトウェアパッケージに
コンパイル時に使うかどうか選べる機能拡張がある場合、
ユーザは@code{configure}のコマンドラインにオプションを指定することで
有効/無効を切り替えられます。
このオプションは以下の形式をとります:

@example
--enable-@var{feature}@r{[}=@var{arg}@r{]}
--disable-@var{feature}
@end example

このオプションを使えば、
ユーザはコンパイル/インストールする機能拡張を選べます。
@samp{--enable-@var{feature}}は、パッケージのある機能のふるまいを変えたり、
機能をさしかえたりするのに使ってはいけません。
プログラムの一部をコンパイルするかしないか選択するためだけに使うべきです。

ユーザは機能名の後に、@samp{=}に続けて引数を記述できます。
引数に@samp{no}をつけると、その機能は「コンパイルされません」。
引数つきのオプションは例えば「@samp{--enable-debug=stabs}」みたいになります。
引数がついていない場合、引数@samp{yes}がつけられたのと同等になります。
@samp{--disable-@var{feature}}は@samp{--enable-@var{feature}=no}と同等です。

@code{configure}スクリプトは、
サポートしていない@samp{--enable-@var{feature}}オプションが指定されても
エラーを出しません。
この機能は複数のパッケージを含むソースコードツリーの設定をするとき便利です。
各パッケージがサポートするオプションが違っていても、
トップレベルの@code{configure}を呼び出すだけで
(オプションに関するエラーメッセージなしで)
全パッケージの設定ができます(訳註: このへん意訳)。
不幸な副作用としては、オプションの綴ミスをしても警告がでません。
この問題に関して、いまのところよりよい方法は提案されていません。

各オプションについて、
@file{configure.in}でマクロ@code{AC_ARG_ENABLE}を呼び出し、
各オプションが指定されたかどうか調べねばなりません。
各オプションがデフォルトで有効/無効かどうか、
どんな引数が有効かは@file{configure.in}の作者の自由です。

@defmac AC_ARG_ENABLE (@var{feature}, @var{help-string} @r{[}, @var{action-if-given} @r{[}, @var{action-if-not-given}@r{]]})
@maindex ARG_ENABLE
ユーザが@code{configure}の引数に
@samp{--enable-@var{feature}}または@samp{--disable-@var{feature}}の
オプションを指定した場合、
shellコマンド@var{action-if-given}を実行します。
どちらも指定されていなければ@var{action-if-not-given}を実行します。
@var{feature}はパッケージの機能名です。
@var{feature}は英数字とハイフンの組み合わせでないといけません。

@var{action-if-given}の中では、
オプションに@samp{=}に続き引数が指定されていたら、
shell変数@code{enableval}に値が格納されています。
実際には、@code{enableval}と@code{enable_@var{feature}}と同じ値になっています
(@code{enable_@var{feature}}の@var{feature}部分は、もとの@var{feature}の
ハイフンを下線(@samp{_})にしたもの)。
必要ならどちらを参照しても構いません。
@var{help-string}は@code{AC_ARG_WITH}(@pxref{External Software})で使われる
@var{help-string}と同じです。
@end defmac

@defmac AC_ENABLE (@var{feature}, @var{action-if-given} @r{[}, @var{action-if-not-given}@r{]})
@maindex ENABLE
このマクロはobsoleteです。
@code{AC_ARG_ENABLE}から@var{help-string}のサポートを外したようなものです。
@end defmac

@node Site Details, Transforming Names, Package Options, Site Configuration
@section Configuring Site Details

一部のソフトウェアパッケージは、インストールするサイト依存の情報を
必要とします。
例えば、ある種のサービスにはホスト名が必要です。
コンタクト先として会社名やemailアドレスを使うこともあります。
Metaconfigで生成された設定スクリプトは対話的にこのような情報を
問い合わせます。
Autoconfで生成された設定スクリプトは対話的ではないので、
Autoconfで生成された設定スクリプトではどうやればいいのだろう、と思うでしょう。

このようなサイト依存の設定情報は、プログラムが編集したものではなく、
@emph{ユーザだけ}によって編集されたファイルに格納されている必要があります。
ファイルを置く位置は@code{prefix}変数をもとにしたパス、または
ユーザのホームディレクトリなどの標準的な場所にします。
ファイルを置く位置を環境変数で設定してもよいでしょう。
プログラムはコンパイル時でなく実行時に、そのファイルを調べます。
実行時の設定はユーザにとってより便利で、設定時に情報を取得するよりも設定
の過程がより単純です。データファイルを置く場所についてのより多くの情報の
ために @xref{Directory Variables, , Variables for Installation
Directories, standards, GNU Coding Standards}を参照してください。

@node Transforming Names, Site Defaults, Site Details, Site Configuration
@section Transforming Program Names When Installing

Autoconfはプログラムをインストールするときにそれらの名前の変更をサポート
します。これらの変換を使うには@file{configure.in}がマクロ
@code{AC_ARG_PROGRAM}を呼ばなければなりません。

@defmac AC_ARG_PROGRAM
@maindex ARG_PROGRAM
@ovindex program_transform_name
出力変数@code{program_transform_name}の中にインストールされるプログラム
の名前を変更するための@code{sed}コマンドを置きます。

もし後述するオプションのいくつかが@code{configure}に与えられれば、プログ
ラムの名前はそれに応じて変換されます。そうでなければ、もし
@code{AC_CANONICAL_SYSTEM}が呼ばれるか、@samp{--target}の値がホストタイ
プ(@samp{--host}で指定されるか@code{config.sub}によってデフォルト設定さ
れます) と違っていれば、ダッシュが後に続いたターゲットタイプ名を前置詞と
して使います。そうでなければプログラム名は変換されません。
@end defmac

@menu
* Transformation Options::      @code{configure} options to transform names.
* Transformation Examples::     Sample uses of transforming names.
* Transformation Rules::        @file{Makefile} uses of transforming names.
@end menu

@node Transformation Options, Transformation Examples, Transforming Names, Transforming Names
@subsection Transformation Options

以下のコマンドラインオプションを@code{configure}に渡すことによって名前の
変換を指定することができます。

@table @code
@item --program-prefix=@var{prefix}
(プログラムの)名前の前に@var{prefix}を付けます。

@item --program-suffix=@var{suffix}
(プログラムの)名前の後に@var{suffix}を付けます。

@item --program-transform-name=@var{expression}
(プログラムの)名前に対して@code{sed}の置換演算@var{expression}を行います。
@end table

@node Transformation Examples, Transformation Rules, Transformation Options, Transforming Names
@subsection Transformation Examples

これらの変換はクロスコンパイル開発環境の一部になり得るプログラムで役に立
ちます。例えば、Sun 4で@file{--target=i960-vxworks}つきでconfigureされた
クロスアセンブラは、Sun 4のnativeアセンブラと混同され得る@file{as} より
もむしろ@file{i960-vxworks-as} として普通インストールされます。

あなたのシステムにインストールされたGNUプログラムが同じ名前を持った他の
プログラムを隠したくないならあなたはプログラムの名前を@file{g}付きで始め
るように強制できます。例えば、あなたがGNU @code{diff}を
@samp{--program-prefix=g} つきでconfigureするなら、あなたが@samp{make
install}を実行するときにそれは@file{/usr/local/bin/gdiff}としてインストー
ルされます。

より洗練された例として、あなたはすでに@samp{g}がついた@code{gdb}やGNUプ
ログラムではない@code{less}、@code{lesskey}を除いて、ソースツリーにある
プログラム名のほとんどに@samp{g}を付けるように
@example
--program-transform-name='s/^/g/; s/^gg/g/; s/^gless/less/'
@end example
@noindent
を使うことができます。(この特徴を使うため、セットアップされたプログラム
を含むソースツリーを持っていることが前提です。)

あるプログラムの複数のバージョンを同時にインストールする1つの方法は、(プ
ログラムの)一方または両方の名前にバージョン番号を付けることです。例えば、
あなたがAutoconfバージョン1をちょっとの間保持したいなら、あなたは
@file{/usr/local/bin/autoconf2}や@file{/usr/local/bin/autoheader2}などを
インストールするためにAutoconfバージョン2を@samp{--program-suffix=2}を使っ
てconfigureすることができます。

@node Transformation Rules,  , Transformation Examples, Transforming Names
@subsection Transformation Rules

これは@file{Makefile.in}の中で変数@code{program_transform_name}を使う方
法です。

@example
transform=@@program_transform_name@@
install: all
        $(INSTALL_PROGRAM) myprog $(bindir)/`echo myprog|sed '$(transform)'`

uninstall:
        rm -f $(bindir)/`echo myprog|sed '$(transform)'`
@end example

@noindent
もしインストールするプログラムが1つ以上あるなら、あなたはループの中でそ
れを行います。

@example
PROGRAMS=cp ls rm
install:
        for p in $(PROGRAMS); do \
          $(INSTALL_PROGRAM) $$p $(bindir)/`echo $$p|sed '$(transform)'`; \
        done

uninstall:
        for p in $(PROGRAMS); do \
          rm -f $(bindir)/`echo $$p|sed '$(transform)'`; \
        done
@end example

ドキュメントファイル(Texinfoや@code{man})に対して(名前の)変換を行うかど
うかは、手の込んだ疑問(tricky question)です。名前変換に関するいくつかの
理由のために完全な回答はなさそうです。ドキュメントは、特定のアーキテクチャ
に対して普通特別ではありません。そしてTexinfoファイルはシステムドキュメ
ントと衝突しません。しかしそれらは同じファイルの以前のバージョンと衝突す
るかも知れませんし、@code{man}ページはときどきシステムドキュメントと衝突
します。折衷案として、おそらく最も良いのは@code{man}に対しては名前変換を
行い、Texinfoマニュアルには行わないことです。

@node Site Defaults,  , Transforming Names, Site Configuration
@section Setting Site Defaults

Autoconfが生成する@code{configure}スクリプトは何らかの設定値のためにあな
たのサイトにデフォルト値を与えることを許します。あなたはサイトやシステム
全体の初期化ファイルを作ることでこれを行います。

@evindex CONFIG_SITE
もし環境変数@code{CONFIG_SITE}が設定されていれば、@code{configure}はその
値を読み込むシェルスクリプトの名前として使用します。そうでなければシェル
スクリプト@file{@var{prefix}/share/config.site}をそれが存在すれば読み込
み、@file{@var{prefix}/etc/config.site}をそれが存在すれば読み込みます。
したがって、マシン特有のファイルの設定がマシン独自の設定に、それが衝突す
る場合置き換わります。

サイトファイルは恣意的なシェルスクリプトであり得ますが、
but only certain kinds of
code are really appropriate to be in them.@code{configure}は
サイトファイルを読んだ後でキャッシュファイルを読むので、
サイトファイルは、
そのシステムで実行される@code{configure}スクリプトのすべてで共有されるデ
フォルトのキャッシュファイルを定義することができます。もしサイトファイル
でデフォルトキャッシュファイルを設定するならそのサイトファイルの中で出力変数
@code{CC}も設定するのは良い考えです。なぜなら、キャッシュファイルは特定
のコンパイラに対してだけ正当であるのに、多くのシステムはいくつかの(訳註: 
コンパイラを?)使うことができるからです。

あなたはサイトファイルの中で@code{configure}コマンドラインオプションで設
定された値を検査したり上書きしたりできます。オプションはそのオプションと
同じ名前を持つシェル変数をダッシュをアンダースコアに変えて設定します。例
外は、@samp{--without-}と@samp{--disable-}オプションは対応する
@samp{--with-}や@samp{--enable-}オプションとその値@samp{no}を与えること
と同じであることです。したがって、@samp{--cache-file=localcache}は変数
@code{cache_file}に値@samp{localcache}を設定します。
@samp{--enable-warnings=no} や@samp{--disable-warnings}は変数
@code{enable_warnings}に値@samp{no}を設定します。@samp{--prefix=/usr}は
変数@code{prefix}に値@samp{/usr}を設定します。などなど。

サイトファイルは@code{CFLAGS}のような他の出力変数のためのデフォルト値を
設定する良い場所でもあります。あなたが普段、繰り返しコマンドラインで行っ
ている何らかのノンデフォルト値を与えることを必要とするならば。もしあなた
が@var{prefix}や@var{exec_prefix}(wherever you locate the site file)にノ
ンデフォルト値を使うなら、あなたはそれらをサイトファイルに設定することが
できます if you specify it with the @code{CONFIG_SITE}
environment variable.

あなたはいくつかのキャッシュ変数をサイトファイル自身の中で設定することが
できます。これを行うことはあなたがクロスコンパイルを行うならば役に立ちま
す。テストプログラムの実行に必要な特徴を検査するのは不可能なので。
@file{@var{prefix}/etc/config.site}にそのシステムのために正しく値を設定
することによってあなたは``キャッシュを装填''することができます。あなたが
設定することを必要とするキャッシュ変数の名前を見つけるにはaffected
@code{configure}スクリプトやそのマクロのためのAutoconf @code{m4} ソース
コードの中にある、名前に@samp{_cv_}が付いたシェル変数を探します。

キャッシュファイルはサイトファイルの中で設定する変数を上書きしないように
注意しています。同様に、サイトファイルの中にあるコマンドラインオプション
を上書きするべきではありません。あなたのコードは@code{prefix}や
@code{cache_file}のような変数がそれらのデフォルト値(@code{configure}の上
位付近にある)を持つようにそれを変更する前に検査するべきです。

ここにサンプルファイル@file{/usr/share/local/gnu/share/config.site}があ
ります。コマンド@samp{configure --prefix=/usr/share/local/gnu}はこのファ
イルを読み込みます(もし@code{CONFIG_SITE}が違うファイルに設定されてなけ
れば)。

@example
# config.site for configure
#
# Change some defaults.
test "$prefix" = NONE && prefix=/usr/share/local/gnu
test "$exec_prefix" = NONE && exec_prefix=/usr/local/gnu
test "$sharedstatedir" = '$@{prefix@}/com' && sharedstatedir=/var
test "$localstatedir" = '$@{prefix@}/var' && localstatedir=/var
#
# Give Autoconf 2.x generated configure scripts a shared default
# cache file for feature test results, architecture-specific.
if test "$cache_file" = ./config.cache; then
  cache_file="$prefix/var/config.cache"
  # A cache file is only valid for one C compiler.
  CC=gcc
fi
@end example

@node Invoking configure, Invoking config.status, Site Configuration, Top
@chapter Running @code{configure} Scripts

以下では、@code{configure}スクリプトを使ったパッケージをどうやって
自動設定するかを述べます。以下のテキストは、パッケージに添付する
@file{INSTALL}ファイルとしても使えます。配布可能なプレーンテキスト版の
@file{INSTALL}はAutoconfパッケージに含まれています。

@menu
* Basic Installation::          Instructions for typical cases.
* Compilers and Options::       Selecting compilers and optimization.
* Multiple Architectures::      Compiling for multiple architectures at once.
* Installation Names::          Installing in different directories.
* Optional Features::           Selecting optional features.
* System Type::                 Specifying the system type.
* Sharing Defaults::            Setting site-wide defaults for @code{configure}.
* Operation Controls::          Changing how @code{configure} runs.
@end menu

@include install-ja.texi

@node Invoking config.status, Questions, Invoking configure, Top
@chapter Recreating a Configuration

@code{configure}スクリプトは@file{config.status}という名前のファイルを
つくります。このファイルには、前回パッケージが作成されたときに
どういう設定のためのオプションが指定されたのかが記述されています。
このファイルはshellスクリプトで、実行されると、再度おなじ設定を
することができます。

@file{config.status}に@samp{--recheck}オプションをつけて実行することで、
@file{config.status}自体を更新することができます。
このオプションは@code{configure}自体を変更したときに有効です。
そのような場合、テストの結果は前回と今回で異なっている可能性がありますから。
@samp{--recheck}オプションをつけて@file{config.status}を実行した場合、
前回つけたのとおなじ引数、それから@samp{--no-create}オプションと
@samp{--no-recursion}オプションをつけて@code{configure}が実行されます。
これらのオプションは、@file{config.status}が実行されるのを防ぎ、
@file{Makefile}や他のファイルが更新されないようにし、
サブディレクトリの@code{configure}が実行されないようにします。
(このため、@file{Makefile}の中から@file{config.status}が
呼べるようになっています。例題は@pxref{Automatic Remaking}参照)

@file{config.status}は@samp{--help}と@samp{--version}のふたつの
オプションも受け付けます。
@samp{--help}をつけると、@file{config.status}のオプションの
概説を出力します。@samp{--version}をつけると、Autoconfの
バージョンと、@code{config.status}を作るときに使われた
@code{configure}のオプションを出力します。

@file{config.status}は、いくつかの環境変数を参照して動作を変更します:

@defvar CONFIG_SHELL
@evindex CONFIG_SHELL
@samp{--recheck}をつけたとき@code{configure}を実行する際に、
使うべきshellを指定します。Bourne shell互換である必要があります。
デフォルトは@file{/bin/sh}です。
@end defvar

@defvar CONFIG_STATUS
@evindex CONFIG_STATUS
設定を記録するためのshellスクリプトの名前です。
デフォルト値は@file{./config.status}です。この環境変数は
あるパッケージが他のパッケージの一部を使っていて、
それらが別々に管理されているため@code{configure}スクリプトを
統合できない場合などに役立ちます。
@end defvar

以下の環境変数を使うことで、別々に配布されるパッケージが
@code{configure}で求めたテスト結果を共有することができます。
あるパッケージが他のパッケージ(たとえば共有ライブラリ)の必要とする
OS機能のsupersetを要求している場合に役立ちます。
以下の環境変数を使うと、@file{config.status}に@file{configure.in}で
指定された以外のファイルを生成させることができます。
このため、生成されたファイルを他のパッケージから使うことができるのです。

@defvar CONFIG_FILES
@evindex CONFIG_FILES
@samp{@@@var{variable}@@}の置換を行うべきファイル名。
デフォルトは@file{configure.in}で@code{AC_OUTPUT}に与えられた引数です。
@end defvar

@defvar CONFIG_HEADERS
@evindex CONFIG_HEADERS
Cの@code{#define}ディレクティブの置換を行うべきファイル名。
デフォルトは@code{AC_CONFIG_HEADER}に与えられた引数です。
@code{AC_CONFIG_HEADER}マクロが使われていない場合、
@file{config.status}はこれを無視します。
@end defvar

上記の環境変数を使うことで、一部のファイルだけを再生成するような
@file{Makefile}のルールを記述することができます。
例えば、@pxref{Automatic Remaking}で挙げたルールでは、
@file{configure.in}が新しくなったときには@file{config.status}が
2回呼ばれます。もしこれが気に入らない場合、各ファイルをひとつづつ
更新するようなルールを記述することができます(訳註: かなり意訳):

@example
@group
config.h: stamp-h
stamp-h: config.h.in config.status
        CONFIG_FILES= CONFIG_HEADERS=config.h ./config.status
        echo > stamp-h

Makefile: Makefile.in config.status
        CONFIG_FILES=Makefile CONFIG_HEADERS= ./config.status
@end group
@end example

@noindent
(@file{configure.in}が@code{AC_CONFIG_HEADER}マクロを使っていない場合、
@code{make}ルール内で@code{CONFIG_HEADERS}を指定する必要はありません)

@node Questions, Upgrading, Invoking config.status, Top
@chapter Questions About Autoconf

Autoconfに関しては、いくつかの質問が頻繁に出ます。
それらのいくつかにお答えしましょう。

@menu
* Distributing::                Distributing @code{configure} scripts.
* Why GNU m4::                  Why not use the standard @code{m4}?
* Bootstrapping::               Autoconf and GNU @code{m4} require each other?
* Why Not Imake::               Why GNU uses @code{configure} instead of Imake.
@end menu

@node Distributing, Why GNU m4, Questions, Questions
@section Distributing @code{configure} Scripts

@display
Autoconfが生成した@code{configure}スクリプトには配布制限はありますか?
@code{configure}スクリプトを使うプログラムに影響は?
@end display

Autoconfによって生成された設定スクリプトの配布に関しては、
なにも制限がありません。Autoconfバージョン1では、
生成された設定スクリプトもGPLによって保護されていました。
現在でも我々はソフトウェアの作者にGPLのような配布条件で
配布を行うことを推奨しますが、Autoconfを使うからといってそれが
必須なわけではありません。

@code{configure}に使われる可能性のあるファイルのうち、
@file{config.h.in}はあなたが指定した@file{configure.in}の
著作権表示に従います。@file{config.h.in}は@file{configure.in}と、
パブリックドメインのファイル@file{acconfig.h}から生成されるからです。
@file{config.sub}と@file{config.guess}は、Autoconfに生成された
@code{configure}スクリプトとともに使う場合にはあなたの
パッケージの配布条件に従います。これはGPLの例外です。
@file{install-sh}はXコンソーシアムによるもので、
著作権は放棄されています。

@node Why GNU m4, Bootstrapping, Distributing, Questions
@section Why Require GNU @code{m4}?

@display
なんでAutoconfはGNU @code{m4}を必要とするんですか?
@end display

多くの@code{m4}の実装では、マクロの大きさや数に決め打ちの制限があって、
Autoconfはそれをオーバしてしまいます。また、いくつかの組み込みマクロが
不足している場合があり、それらのマクロなしではAutoconfのような
洗練されたアプリケーションは記述しづらくなります。たとえばこんな
マクロがない場合があります:

@example
builtin
indir
patsubst
__file__
__line__
@end example

ソフトウェアの管理者はAutoconfだけを使えばよいし、GNU @code{m4}は
設定やインストールが簡単です。このため、GNU @code{m4}がインストール
されていないといけない、というのは妥当と思われます。
GNUやGNU以外のフリーソフトウェアの管理者にはGNUユーティリティの
多くをインストールしている人がたくさんいます。なぜなら
彼らはGNUユーティリティが気に入っているからです。

@node Bootstrapping, Why Not Imake, Why GNU m4, Questions
@section How Can I Bootstrap?

@display
AutoconfがGNU @code{m4}を必要としていて、GNU @code{m4}パッケージがAutoconfで
生成された@code{configure}スクリプトを含んでいたら、どこから仕事をはじめたら
いいんですか? 鶏と卵問題になりませんか?
@end display

それは誤解です。
確かに、GNU @code{m4}パッケージはAutoconfで生成された
@code{configure}スクリプトを含んでいます。
しかし、@code{configure}スクリプトを実行したり
GNU @code{m4}パッケージをインストールしたりするのに
Autoconfは必要ありません。
Autoconfは@code{m4}パッケージに含まれる@code{configure}スクリプトを
変更したい場合にだけ必要です。
ふつう、そのような変更はごく少数のひと(主に@code{m4}パッケージの
メインテナ)しか行いません。

@node Why Not Imake,  , Bootstrapping, Questions
@section Why Not Imake?

@display
なんで@code{configure}スクリプトでなしにImakeを使わないのですか?
@end display

幾人かのひとがこの質問の答えを書いてくれましたので、
それを翻案して載せたいと思います。

以下の答えはRichard Pixleyの答えをもとにしています:

Autoconfで生成されたスクリプトは、
しばしばパッケージを一度も動かしたことのないマシンでも動作します。
つまり、Autoconfスクリプトは新しいシステムのための設定を類推することが
できるのです。
Imakeではこれはできません。

Imakeはホスト依存の情報を得るのに共用のデータベースを使います。
X11の配布はツールの集合でできているので、中央集権的にデータベースを
管理することには意味があります。

しかし、GNUのツールはそのように配布されていません。
各々のGNUツールには個別のmaintainerがいます。
maintainerは世界中に散らばっています。
共用のデータベースを使うと、「データベースの管理」という悪夢が待っています。
Autoconfは共用のデータベースのように見えるかもしれませんが、実際には違います。
Autoconfスクリプトは各ホストへの依存性を記述するのではなく、
プログラムの要求事項を記述しているのです。

GNUツール群を固有のツールの集合としてみるなら、
X11の場合と問題は似ているかもしれません。
でも、GNUの開発ツールはクロス開発にも使えます。
しかも、どんなホストとターゲットの組み合わせについても使えますし、
全ての組み合わせは同時におなじマシンにインストールできます。
さらに、ホスト独立なファイルをマシン間で共有するようにもできます。
Imakeはこの問題に対して解を与えていません。

Imakeのtemplateはある種の標準化です。
GNUのcoding standardは同じ問題について、
Imakeの課する制約をいれることなく解決を与えています。

以下はPer Bothnerによるさらなる解説です:

Imakeの利点として、巨大なMakefileを@code{cpp}の@samp{#include}と
マクロ機構を使って簡単に生成できる、ということがあります。
しかし、@code{cpp}はプログラマブルではありません。
@code{cpp}では限られた条件文しか書けませんし、ループは記述できません。
@code{cpp}では実行環境を調べることもできません。

以上の問題点は全て、@code{cpp}でなしに@code{sh}を使うことで解決できます。
shellは完全にプログラマブルです。マクロの置換、他のshellスクリプトの
実行(や取り込み)もできますし、実行環境を調べることもできます。

Paul Eggertがさらに詳細を述べています:

Autoconfを使う場合には、パッケージのインストールをするひとは
「Imake自体がきちんとインストールされて正しく動作する」ことを仮定しなくて
済みます。
Imakeに慣れたひとには、これはたいした利点とは思えないかもしれません。
しかし、多くのホストではImakeはインストールされていなかったり、
標準インストールの状態ではうまく動作しなかったりします。
そして、パッケージのインストールにImakeを使うと、
Imakeはパッケージをホストにインストールする際の障害になります。
例えば、Imake templateと設定ファイルがホストに正しく
インストールされていないことがあります。
Imakeを使ったインストール手順では、
全てのソースファイルが巨大なdirectory treeに格納されていると
仮定していることがあります。
Imakeの設定ファイルは単一のコンパイラを仮定していて、
それがパッケージをインストールするのに使いたいコンパイラと
違うかもしれません。
パッケージの仮定しているImakeのバージョンと、
実際ホストにインストールされているImakeのバージョンが異なるかもしれません。
Autoconfを使う場合、このような問題は稀です。
パッケージに、独立して動く自動設定処理プログラムが付属しているからです。

Imakeを使っていると、@code{make}とCプリプロセッサの予期していない
動作に悩まされることがよくあります。
CプリプロセッサはCのプログラムを処理するために設計されたもので、
@file{Makefile}を処理するためのものではありません。
Autoconfを使うなら簡単です。
Autoconfはバックエンドに汎用プリプロセッサ@code{m4}を使っています。
@code{m4}を使うのは、
パッケージの作者が@code{configure}スクリプトを作成するときです。
つまり、インストールをするときにはプリプロセッサは必要ありません
(訳註: この行激しく意訳)。

最後にMark Eichinが言うには:

Imakeには拡張性がありません。
Imakeに新しい機能を加えようとすると、
独自のproject templateを作成しなければなりません。
しかも、そのtemplateには既存のtemplateの大部分をコピーして含めねば
なりません。
つまり、洗練された開発プロジェクトでは、
ベンダが提供するtemplateは必要なところをカバーしてくれないので
意味がありません
(開発プロジェクトがX11向けなら話は別ですが)。

逆の見方をすると:

Imakeにはひとつだけ、@code{configure}に対して有利な点があります。多くの
場合、@file{Imakefile}は@file{Makefile.in}よりもずっと短く、冗長性があり
ません。これを改善する方法はあります。Kerberos V5では、ツリーじゅうの
@file{Makefile}の先頭と末尾の部分を@file{post.in}と@file{pre.in}として共
通化し、@file{Makefile.in}から@file{Makefile}を生成するときにこれらを読
み込むようにしました。これは、多くの共通のものが、普通@code{configure}セッ
トアップにあるものさえ、繰りさえされることを意味します。

@node Upgrading, History, Questions, Top
@chapter Upgrading From Version 1

Autoconfバージョン2はバージョン1とほぼ互換です。
しかし、いくつかの点についてよりよいやり方が導入されていますし、
バージョン1の汚かった点がいくつか除かれています。
このため、あなたの@file{configure.in}の洗練度に依存しますが、
手作業で@file{configure.in}を一部書き換える必要があるかもしれません。
この章ではバージョン2への移行のために注意すべき点を挙げます。
移行すると、生成される@code{configure}スクリプトはバージョン2の
新機能によりよりよくなるでしょう。
変更点はAutoconfの配布キットに含まれる@file{NEWS}というファイルに
まとめられています。

まず、バージョン1.1かそれ以降のGNU @code{m4}がインストール
されていることを確認してください。できればバージョン1.3かそれ
以降のものが望ましいです。バージョン1.1以前のものには、Autoconfが
動作しなくなるようなバグがあります。バージョン1.3またはそれ以降は
1.3以前のバージョンより大幅に早く動作します。
バージョン1.3およびそれ以降では、diversionの実装がより効率的になり、
内部状態をファイルに保存することができるため高速に再呼び出しが可能です。

@menu
* Changed File Names::          Files you might rename.
* Changed Makefiles::           New things to put in @file{Makefile.in}.
* Changed Macros::              Macro calls you might replace.
* Invoking autoupdate::         Replacing old macro names in @code{configure.in}.
* Changed Results::             Changes in how to check test results.
* Changed Macro Writing::       Better ways to write your own macros.
@end menu

@node Changed File Names, Changed Makefiles, Upgrading, Upgrading
@section Changed File Names

もし、(特定のパッケージのソースディレクトリに置いてあるのではなくて)
Autoconfと一緒に@file{aclocal.m4}がインストールされていたら
ファイル名を@file{acsite.m4}に変更する必要があります。
@xref{Invoking autoconf}

@file{install.sh}をパッケージと一緒に配布する場合、
ファイル名を@file{install-sh}にしてください。
これは、@code{make}の組み込みルールが勝手に@file{install}
というファイルを生成してしまうのを防ぐためです。
@code{AC_PROG_INSTALL}は両方のファイル名を調べますが、
新しい名前を使う方が望ましいです。

@file{config.h.top}または@file{config.h.bot}を使っている場合、
そのまま使い続けることができます。可能なら@file{acconfig.h}に
取り込んだ方がファイルがごみごみしなくていいでしょう。
@xref{Invoking autoheader}

@node Changed Makefiles, Changed Macros, Changed File Names, Upgrading
@section Changed Makefiles

@file{Makefile.in}に@samp{@@CFLAGS@@}、@samp{@@CPPFLAGS@@}
それから@samp{@@LDFLAGS@@}を追加してください。
追加すると、@code{configure}が実行されたときの環境がそれらの
変数の値に反映されます。これは必ず必要なわけではありませんが、
ユーザの利便のためになります。

@file{Makefile}以外で、@code{AC_OUTPUT}で出力されるファイルのもとの
ファイルには、コメント中に@samp{@@configure_input@@}を追加してください。
追加すると、「このファイルは@code{configure}に生成された」という
コメントが出力ファイルに入ります。
@code{AC_OUTPUT}中で、あらゆる形式のコメントを自動選択するのは
無理になりました。

@file{config.log}と@file{config.cache}を、@file{Makefile}の
@code{distclean}ターゲットで消去されるファイルのリストに含めてください。

以下のような定義を@file{Makefile.in}にしていたら:

@example
prefix = /usr/local
exec_prefix = $@{prefix@}
@end example

@noindent
以下のように書き換える必要があります:

@example
prefix = @@prefix@@
exec_prefix = @@exec_prefix@@
@end example

@noindent
@samp{@@}が前後についていない変数を書き換えるふるまいは
削除されました。

@node Changed Macros, Invoking autoupdate, Changed Makefiles, Upgrading
@section Changed Macros

多くのマクロがAutoconfバージョン2で改名されました。
古い名前を使うこともできますが、新しいものの方がわかりやすく、
ドキュメントとの対応もとれていて探しやすいです。
新しい名前と古い名前の対応表は@xref{Old Macro Names}を参照してください。
@code{autoupdate}を使うと、古いマクロ名を含む@file{configure.in}を
新しいマクロ名を使うように変換できます。@xref{Invoking autoupdate}参照。

いくつかのマクロはよりうまく働く類似のマクロで置き換えられましたが、
呼び出し方法が互換でないものがあります。
@code{autoconf}を呼び出した際にobsoleteなマクロを呼び出している
旨警告が表示された場合、警告を無視することもできます。
しかし、警告に従って書き換えを行った方が生成される
@code{configure}スクリプトはうまく動作します。
特に、テストの結果を表示するメカニズムが変更されています。
@code{echo}や(@code{AC_COMPILE_CHECK}経由での)@code{AC_VERBOSE}などを
使っている場合には、@code{AC_MSG_CHECKING}と@code{AC_MSG_RESULT}に
移行した方が@code{configure}の出力がうまく見えます。
@xref{Printing Messages}を参照のこと。
これらのマクロはキャッシュとともに使うと最もうまく動きます。
@xref{Caching Results}参照。

@node Invoking autoupdate, Changed Results, Changed Macros, Upgrading
@section Using @code{autoupdate} to Modernize @code{configure}

@code{autoupdate}はAutoconfマクロを古い名前で呼び出している
@file{configure.in}を、現在のマクロ名で呼び出すように変換する
プログラムです。
Autoconfのバージョン2では、多くのマクロが統一的でわかりやすい
命名規則に従うよう改名されました。
新しい命名規則については@xref{Macro Names}を参照。
古い名前を使うこともできますが、新しいものに移行した使った方が
@file{configure.in}が読みやすいですし、現在のAutoconfのドキュメントとの
対応もとれていて探しやすいです。
(新しい名前と古い名前の対応表は@xref{Old Macro Names}を参照)

@evindex SIMPLE_BACKUP_SUFFIX
引数なしで呼ばれた場合、@code{autoupdate}は@file{configure.in}を
更新します。その際、もとのファイルはファイル名に@file{~}
(または環境変数@code{SIMPLE_BACKUP_SUFFIX}の内容)を追加したファイル名で
保存されます。@code{autoupdate}に引数を与えた場合、
@file{configure.in}のかわりにそのファイルを読み込んで標準出力に
結果を書き出します。

@noindent
@code{autoupdate}は以下のオプションを受け付けます:

@table @code
@item --help
@itemx -h
コマンドラインオプションの説明を出力して終了します。

@item --macrodir=@var{dir}
@itemx -m @var{dir}
@evindex AC_MACRODIR
デフォルトのディレクトリではなしに、
ディレクトリ@var{dir}に格納されている
Autoconfマクロファイルを参照します。
ディレクトリ名を
環境変数@code{AC_MACRODIR}に
設定しても変えられます。
オプションは環境変数より優先されます。

@item --version
@code{autoupdate}のバージョン番号を表示して終了します。
@end table

@node Changed Results, Changed Macro Writing, Invoking autoupdate, Upgrading
@section Changed Results

shell変数@code{DEFS}の値を調べることで以前のテスト結果を参照
している場合、テスト結果のキャッシュをしているshell変数を
調べるように変更する必要があります。
@code{DEFS}は出力ファイル生成時に設定されるようになったので、
@code{configure}実行中には存在しないようになりました。
バージョン1からの変更は、shell変数@code{DEFS}の
設定のたび、つまり@code{AC_DEFINE}を呼ぶたびに
正しく内容をquoteするのが面倒で非効率的であったことによります。
@xref{Cache Variable Names}参照。

例えば、Autoconfバージョン1用の@file{configure.in}の一部が
このようだったとすると:

@example
AC_HAVE_FUNCS(syslog)
case "$DEFS" in
*-DHAVE_SYSLOG*) ;;
*) # syslog is not in the default libraries.  See if it's in some other.
  saved_LIBS="$LIBS"
  for lib in bsd socket inet; do
    AC_CHECKING(for syslog in -l$lib)
    LIBS="$saved_LIBS -l$lib"
    AC_HAVE_FUNCS(syslog)
    case "$DEFS" in
    *-DHAVE_SYSLOG*) break ;;
    *) ;;
    esac
    LIBS="$saved_LIBS"
  done ;;
esac
@end example

バージョン2用はこのようになります:

@example
AC_CHECK_FUNCS(syslog)
if test $ac_cv_func_syslog = no; then
  # syslog is not in the default libraries.  See if it's in some other.
  for lib in bsd socket inet; do
    AC_CHECK_LIB($lib, syslog, [AC_DEFINE(HAVE_SYSLOG)
      LIBS="$LIBS $lib"; break])
  done
fi
@end example

@code{AC_DEFINE_UNQUOTED}のバグを回避するためにダブルクォートの
前にbackslashを入れていた場合、それらを取り除く必要があります。
@code{AC_DEFINE_UNQUOTED}は現在想定されるとおりに動き、
backquote以外のquoteを特別扱いしません。
@xref{Setting Output Variables}参照。

Autoconfマクロによって設定されるshell変数で真偽値をとるものは、
「真」の場合@samp{yes}に設定されるようになりました。
マクロの多くは「偽」の場合@samp{no}を使いますが、
バックワードコンパチビリティのために空文字列を使うものもあります。
shell変数が1とか@samp{t}とかに設定されることを仮定している場合、
スクリプトを変更する必要があります。

@node Changed Macro Writing,  , Changed Results, Upgrading
@section Changed Macro Writing

自分でマクロを定義する場合、@code{define}のかわりに@code{AC_DEFUN}
を使わねばならないようになりました。@code{AC_DEFUN}は自動的に
@code{AC_PROVIDE}を呼び出します。
これにより、@code{AC_REQUIRE}に呼ばれたマクロが他のマクロを邪魔
しないようなり、@samp{checking@dots{}}というメッセージがダブって
表示されるのを防止できます。古い方法でマクロを定義しても
実害はありませんが、不便ですしかっこわるいです。
@xref{Macro Definitions}参照。

マクロを定義するために、Autoconfについてきたマクロの定義を
読んでらっしゃるのではないかと思います。新しいバージョンの
マクロ定義を読むのはいいことだと思います。書き方が
わかりやすくなっていますし、新しい機能も活用しています。

ドキュメントに書かれていないAutoconfの内部構造(マクロ、変数や
実装上の抜け道)を使ってトリッキーなことをしている場合、バージョンの
違いによる変化に影響されていないかをチェックしてください。
もしかしたら、ずるをしないでもバージョン2で用意されているやりかたで
同じ事ができるかもしれません。できないかもしれませんけど。

自分で記述したテストを高速にするために、キャッシュを使いましょう。
あなたの記述したテストが、汎用的なマクロとして一般化できるかどうか
考えましょう。

@node History, Old Macro Names, Upgrading, Top
@chapter History of Autoconf

以下のことを不思議に思うかもしれません。なぜAutoconfは元々書かれたのです
か? どのようにして現在の形式になったのですか? (なぜそれはゴリラによく似て
いるのですか?)不思議に思っていない場合、この章は有用な情報を含んでいない
ので省略した方がましです。不思議に思って@emph{いる}場合、軽くながして
ください@dots{}

@menu
* Genesis::                     Prehistory and naming of @code{configure}.
* Exodus::                      The plagues of @code{m4} and Perl.
* Leviticus::                   The priestly code of portability arrives.
* Numbers::                     Growth and contributors.
* Deuteronomy::                 Approaching the promises of easy configuration.
@end menu

@node Genesis, Exodus, History, History
@section Genesis

1991年6月、私はFree Software Foundationのため、GNUユーティリティーの多く
を保守していました。それらが、より多くのプラットホームに移植され、より多
くのプログラムが加えられたので、ユーザーは、@file{Makefile}で、多くの
@samp{-D}オプション(およそ20)を選択する必要があり、厄介になりました。
特に私のために、---私は、異なるシステムで、それぞれの新しいいリリースを
テストする必要がありました。そして、私はfileutilsパッケージのため、正し
いセッティングを見つけるため、小さなシェルスクリプトを書き、fileutils
2.0の一部としてリリースしました。その@code{configure}は、翌月、いくつか
の他のGNUユーティリティパッケージのための、@code{configure}スクリプトを
作るため、(手作業で)改造すると良く働きました。Brian Berlinerも、私のスク
リプトを、CVSリビジョンコントロールシステム用に改造しました。

その夏の後、私はRichard StallmanとRichard Pixleyが、GNUコンパイラツール
で使う、類似のスクリプトを開発していたことを知りました。それで、私は
@code{configure}スクリプトを、発展するインタフェースをサポートするため、
改造しました。テンプレートとして、@file{Makefile.in}という名前のファイル
を使い、(多くあるなかの)最初のオプション@samp{+srcdir}を追加し、
@file{config.status}ファイルを作りました。

@node Exodus, Leviticus, Genesis, History
@section Exodus

ユーザーからのフィードバックを得るにつれ、私は、スクリプトのそれぞれの良
く似た変更に対し、検索と置換、カットアンドペーストにEmacsを使い、多くの
改良点を組み入れました。私が、GNUユーティリティパッケージに、
@code{configure}スクリプトを使うため改造するにつれ、手作業でのアップグレー
ドは、非現実的になりました。GNUグラフィックユーティリティの管理者Rich
Murpheyは、@code{configure}スクリプトは素晴らしいというメールを送ってく
れ、私がそれらを生成するツールを持っているなら送って欲しいという依頼があ
りました。ダメだと思いましたが、そうするべきだと思いました!。それで、私
はそれらを生成する仕事を始めました。手書きの@code{configure}スクリプトの
奴隷から、Autoconfで簡単に始める裕福で簡単な旅が始まりました。

Cygnus @code{configure}は、そのころには開発されていて、表ベースで動いて
いました。それは、主に推測しにくい(オブジェクトファイルの、フォーマット
の詳細としての)特徴の、小さな数字を使って、システムタイプを不連続な数字
で、主に扱われることになっています。Brian Foxが、Bashのために開発してい
た、自動的なコンフィグレーションシステムは、類似のアプローチをとります。
一般的に使うため、それぞれのオペレーティングシステムが持つ、それぞれ異な
る特徴の、最新のデータベースを管理しようとすることは、望みがないように思
われました。それは、その場その場で---特に、人々がローカルでハックしたり、
ベンダーがインストールしたパッチを持つ、ハイブリッドなシステムで、おおま
かな特徴を調べるために、容易で信頼性が高いです。

私は Cygnus @code{configure}に類似のアーキテクチャを使おうと考え、それは
実行時には、@file{configure.in}の部品を読み込む、一つの @code{configure}
スクリプトです。しかし、全てのパッケージで、全ての特徴を配布する必要は望
まなかったので、プロセッサーによって、それぞれの @file{configure.in}から、
異なる@code{configure}を作らせる処理にしました。そのアプローチは、多くの
制御と柔軟性をもたらしました。

私は、Larry Wall、Harlan Stennと、Raphael Manfrediによる、Metaconfigを使っ
てみようとしましたが、いくつかの理由でやめました。それが生成する
@code{Configure}スクリプトは、対話的で、それが非常に不都合だと分かりまし
た。私は、それが行う(ライブラリ関数のような)特徴の調べ方が、好きでありま
せんでした。さらに、まだ管理されているかどうか分かりませんでした。
@code{Configure}スクリプトは、(System V R4とNeXTのような)近代的なシステ
ムでは働かないように思えました。特徴の有無の反応で、できることがあまり柔
軟ではありませんでした。学ぶことが難しいと思いました。そして、必要以上に、
あまりに大きく複雑でした(私は、そのとき、Autoconfが結局どれくらい成長す
るのか、理解していませんでした)。

私は、@code{configure}スクリプトの私のスタイルを生成するため、Perlを使う
ことを考えましたが、@code{m4}が、簡単なテキスト代入の仕事により適してい
て、出力が暗黙なので、より小さい方法になると思い、決定しました。さらに、
みんな既にそれを持っています。(最初は、私はGNUが拡張した@code{m4}に依存
しませんでした。)また、Maryland大学の私の友達は、@code{tvtwm}を含む、い
くつかのプログラムのフロントエンドとして、@code{m4}を、最近位置付けてい
て、私は新しい言語への挑戦に興味が湧きました。

@node Leviticus, Numbers, Exodus, History
@section Leviticus

私の@code{configure}スクリプトは、ユーザーの対話的な干渉無しで、システム
の能力を自動的に決定するので、それを生成するプログラムを、Autoconfigと呼
ぶことに決定しました。しかし、バージョンナンバーを付けると、UNIXファイル
システムではあまりに長い名前なので、短くしてAutoconfとしました。

1991年秋、私は、@code{m4}マクロの手書きのスクリプトの部品をまとめ、調査
時に使う特徴を加えたり、テクニックを上達させることを続けるにつれて、私に
フィードバックを与えてもらうため、移植性の聖杯にちなんだ探求者たちのグルー
プ(つまり、アルファテスター)を、呼びました。テスターの間で著明な人は、以
下の通りです。
@ifinfo
Franc,ois
@end ifinfo
@tex
Fran\c cois
@end tex
Pinardは、@code{m4}を実行するためと、未解決のマクロの呼び出しを調べるた
めの、@file{autoconf}シェルスクリプトの作り方の、アイディアを持ってきま
した。Richard Pixleyは、インクルードファイルやシンボルを探すため、より正
確な結果を求めて、ファイルシステムを探す代わりに、コンパイラの実行を提案
しました。Karl Berryは、Autoconfに、コンフィグレーション@TeX{}を与え、ド
キュメントに、マクロインデクッスを加えました。そして、Ian Taylorは、
@samp{-D}オプションを@file{Makefile}に置く代わりとして、Cヘッダファイル
を作るためのサポートを加え、UUCPパッケージでAutoconfが使えるようになりま
した。アルファテスターは、リリースからリリースで、変化するAutoconfマクロ
の、名前と呼び出し方法に対し、何度も何度も、ファイルを機嫌良く調整してく
れました。彼らは皆、多くの特定の調査、偉大なアイディアそして、バグフィク
スを提供してくれました。

@node Numbers, Deuteronomy, Leviticus, History
@section Numbers

1992年7月、何カ月ものアルファテストの後で、私は Autoconf 1.0をリリースし、
それを使って多くのGNUパッケージを改造しました。私は、それらに対する、あ
まりに肯定的な反応に驚きました。私が追跡記録できる以上の多くの人々が、そ
れを使い始め、それは、GNUプロジェクトの一部ではない(TCL、FSPとKerberos
V5のような)ソフトウェアで働かせている人も含みます。Autoconfは、
@code{configure}を使っている多くの人が、彼らが遭遇した問題を報告してくれ
るので、急速に改善され続けました。

Autoconfは、@code{m4}実行の良い耐久テストだということが分かりました。
UNIX @code{m4}は、Autoconfが定義する、マクロの長さでコアダンプを吐き始め、
いくつかのバグが、GNU @code{m4}でも同様に明らかになりました。結局、私達
はGNU @code{m4}のみが持つ特徴が必要だと認識しました。4.3BSD @code{m4}は、
特に組み込みマクロのセットが足りず、System Vバージョンはましですが、私達
が必要とするもの全てを、いまだに供給してくれません。

人々が、Autoconfをより強い圧力下(そして、私が予想していなかった利用)の下
で利用するにつれ、更なる開発が発生しました。Karl BerryはX11に対する調査
を加えました。david zuhnはC++サポートを寄付してくれました。
@ifinfo
Franc,ois
@end ifinfo
@tex
Fran\c cois
@end tex
Pinardは、無効な引数を診断させるようにしました。Jim Blandyは勇敢にも、後
の改良のためのワークグランドとなるよう、GNU Emacsのコンフィグレーション
に強要しました。Roland McGrathは、GNU Cライブラリのコンフィグレーション
に使い、Cヘッダテンプレートファイルを自動的に作る、@code{autoheader}スク
リプトを書き、@code{configure}に、@samp{--verbose}オプションを加えました。
Noah Friedmanは、@samp{--macrodir}オプションと @code{AC_MACRODIR}環境変
数を加えました。(彼は、``ソフトウェアパッケージを、Autoconfを使うものに
改造してください''と言うことを意味する @dfn{autoconfiscate}という言葉も
作り出しました。)RolandとNoahは、 @code{AC_DEFINE}での引用の保護を改善し、
特に私が1993年の2月から6月まで移植性の問題にうんざりしているとき、多くの
バグを直しました。

@node Deuteronomy,  , Numbers, History
@section Deuteronomy

長い間望まれていた、主な特徴のリストが蓄積され、様々な人々のパッチの、数
年間の効果は、残りのcruftを残したままでした。1994年4月のCygnus Supportの
ための仕事中に、私はautoconfの主な修正を始めました。私は、Autoconfが欠け
ていて、david zuhnとKen Raeburnの助けで、Cygnus @code{configure}が関連し
た部分がほとんどですが、Cygnus @code{configure}の特徴のほとんどを加えま
した。これらの特徴は、@file{config.sub}、@file{config.guess}、
@samp{--host}と、@samp{--target}を使うサポート、ファイルをリンクさせるこ
と、サブディレクトリで@code{configure}を実行することを含みます。これらの
特徴に加え、Autoconfを使うように、KenはGNU @code{as}を対応し、Rob Savoye
はDejaGNUを対応しました。

私は、他の人々の要求に答え、より多くの特徴を加えました。多くの人々は、
@code{configure}スクリプトが、実行時の調査結果を共有できるよう求め、それ
は、(特に、Cygnusのような、大きなソースツリーのコンフィグレーション時に)
イライラする程遅かったためです。Mike Haertelは、サイト特定の初期化スクリ
プトを加えることを提案しました。MS-DOSでアンパックが必要なものを配布して
いる人々は、生成されるファイル名が、@file{config.h.in}のように二つのドッ
トを含むので、ファイル名の@file{.in}拡張子に優先するよう求めました。Jim
Averaは、@code{AC_DEFINE}と@code{AC_SUBST}の引用を使う問題の、拡張試験を
行い、彼の洞察は重要な改良につながりました。Richard Stallmanは、Emacsの
@code{configure}スクリプトをデバッグする人々を助けるため、
@file{/dev/null}の代わりに@file{config.log}に、コンパイラ出力を送るよう
頼みました。

私は、プログラム品質に不満があり、他の変更をしました。私は、メッセージで、
あまり曖昧でない調査結果が見えるようにし、常に結果を出力するようにしまし
た。私はマクロの名前を組織化し、コーディングスタイルの矛盾をきれいにしま
した。私は、Autoconfを使う、ソースコードパッケージの改造を助けるため開発
した、追加のユーティリティを加えました。
@ifinfo
Franc,ois
@end ifinfo
@tex
Fran\c cois
@end tex
Pinardの助けで、私は、マクロを、お互いのメッセージが中断しないようにしま
した。(その特徴は、GNU @code{m4}のパフォーマンスのボトルネックを明らかに
し、彼はすぐに修正しました!)私は、人々が解決を望むドキュメント周りの問題
を再編成しました。そして、私は、経験から、Autoconfを変更したとき、明らか
に退化する傾向が分かっているので、テストスイートを始めました。

再び、貴重なフィードバックをくれたアルファテスターです。特に、
@ifinfo
Franc,ois
@end ifinfo
@tex
Fran\c cois
@end tex
Pinard、Jim Meyering、Karl Berry、Rob Savoye、Ken Raeburnと、Mark Eichin 
です。

最終的に、バージョン2.0が用意できました。そしてたくさんの喜びがありまし
た。(そして私は再び自由な時間を持ちます。私は考えます。これは正当な権利
だ。)

@node Old Macro Names, Environment Variable Index, History, Top
@chapter Old Macro Names

Autoconfのバージョン2では、多くのマクロが統一的でわかりやすい
命名規則に従うよう改名されました。

以下は、改名されたマクロの古い名前と現在の名前のリストです。
バックワードコンパチビリティのために@code{autoconf}は
古い名前を受け付けますが、古い名前はobsoleteです。
新しい命名規則については@xref{Macro Names}参照。

@table @code
@item AC_ALLOCA
@maindex ALLOCA
@code{AC_FUNC_ALLOCA}
@item AC_ARG_ARRAY
@maindex ARG_ARRAY
あまり役立たないので削除
@item AC_CHAR_UNSIGNED
@maindex CHAR_UNSIGNED
@code{AC_C_CHAR_UNSIGNED}
@item AC_CONST
@maindex CONST
@code{AC_C_CONST}
@item AC_CROSS_CHECK
@maindex CROSS_CHECK
@code{AC_C_CROSS}
@item AC_ERROR
@maindex ERROR
@code{AC_MSG_ERROR}
@item AC_FIND_X
@maindex FIND_X
@code{AC_PATH_X}
@item AC_FIND_XTRA
@maindex FIND_XTRA
@code{AC_PATH_XTRA}
@item AC_FUNC_CHECK
@maindex FUNC_CHECK
@code{AC_CHECK_FUNC}
@item AC_GCC_TRADITIONAL
@maindex GCC_TRADITIONAL
@code{AC_PROG_GCC_TRADITIONAL}
@item AC_GETGROUPS_T
@maindex GETGROUPS_T
@code{AC_TYPE_GETGROUPS}
@item AC_GETLOADAVG
@maindex GETLOADAVG
@code{AC_FUNC_GETLOADAVG}
@item AC_HAVE_FUNCS
@maindex HAVE_FUNCS
@code{AC_CHECK_FUNCS}
@item AC_HAVE_HEADERS
@maindex HAVE_HEADERS
@code{AC_CHECK_HEADERS}
@item AC_HAVE_POUNDBANG
@maindex HAVE_POUNDBANG
@code{AC_SYS_INTERPRETER} (呼び出し方法変更)
@item AC_HEADER_CHECK
@maindex HEADER_CHECK
@code{AC_CHECK_HEADER}
@item AC_HEADER_EGREP
@maindex HEADER_EGREP
@code{AC_EGREP_HEADER}
@item AC_INLINE
@maindex INLINE
@code{AC_C_INLINE}
@item AC_LN_S
@maindex LN_S
@code{AC_PROG_LN_S}
@item AC_LONG_DOUBLE
@maindex LONG_DOUBLE
@code{AC_C_LONG_DOUBLE}
@item AC_LONG_FILE_NAMES
@maindex LONG_FILE_NAMES
@code{AC_SYS_LONG_FILE_NAMES}
@item AC_MAJOR_HEADER
@maindex MAJOR_HEADER
@code{AC_HEADER_MAJOR}
@item AC_MINUS_C_MINUS_O
@maindex MINUS_C_MINUS_O
@code{AC_PROG_CC_C_O}
@item AC_MMAP
@maindex MMAP
@code{AC_FUNC_MMAP}
@item AC_MODE_T
@maindex MODE_T
@code{AC_TYPE_MODE_T}
@item AC_OFF_T
@maindex OFF_T
@code{AC_TYPE_OFF_T}
@item AC_PID_T
@maindex PID_T
@code{AC_TYPE_PID_T}
@item AC_PREFIX
@maindex PREFIX
@code{AC_PREFIX_PROGRAM}
@item AC_PROGRAMS_CHECK
@maindex PROGRAMS_CHECK
@code{AC_CHECK_PROGS}
@item AC_PROGRAMS_PATH
@maindex PROGRAMS_PATH
@code{AC_PATH_PROGS}
@item AC_PROGRAM_CHECK
@maindex PROGRAM_CHECK
@code{AC_CHECK_PROG}
@item AC_PROGRAM_EGREP
@maindex PROGRAM_EGREP
@code{AC_EGREP_CPP}
@item AC_PROGRAM_PATH
@maindex PROGRAM_PATH
@code{AC_PATH_PROG}
@item AC_REMOTE_TAPE
@maindex REMOTE_TAPE
あまり役立たないので削除
@item AC_RESTARTABLE_SYSCALLS
@maindex RESTARTABLE_SYSCALLS
@code{AC_SYS_RESTARTABLE_SYSCALLS}
@item AC_RETSIGTYPE
@maindex RETSIGTYPE
@code{AC_TYPE_SIGNAL}
@item AC_RSH
@maindex RSH
あまり役立たないので削除
@item AC_SETVBUF_REVERSED
@maindex SETVBUF_REVERSED
@code{AC_FUNC_SETVBUF_REVERSED}
@item AC_SET_MAKE
@maindex SET_MAKE
@code{AC_PROG_MAKE_SET}
@item AC_SIZEOF_TYPE
@maindex SIZEOF_TYPE
@code{AC_CHECK_SIZEOF}
@item AC_SIZE_T
@maindex SIZE_T
@code{AC_TYPE_SIZE_T}
@item AC_STAT_MACROS_BROKEN
@maindex STAT_MACROS_BROKEN
@code{AC_HEADER_STAT}
@item AC_STDC_HEADERS
@maindex STDC_HEADERS
@code{AC_HEADER_STDC}
@item AC_STRCOLL
@maindex STRCOLL
@code{AC_FUNC_STRCOLL}
@item AC_ST_BLKSIZE
@maindex ST_BLKSIZE
@code{AC_STRUCT_ST_BLKSIZE}
@item AC_ST_BLOCKS
@maindex ST_BLOCKS
@code{AC_STRUCT_ST_BLOCKS}
@item AC_ST_RDEV
@maindex ST_RDEV
@code{AC_STRUCT_ST_RDEV}
@item AC_SYS_SIGLIST_DECLARED
@maindex SYS_SIGLIST_DECLARED
@code{AC_DECL_SYS_SIGLIST}
@item AC_TEST_CPP
@maindex TEST_CPP
@code{AC_TRY_CPP}
@item AC_TEST_PROGRAM
@maindex TEST_PROGRAM
@code{AC_TRY_RUN}
@item AC_TIMEZONE
@maindex TIMEZONE
@code{AC_STRUCT_TIMEZONE}
@item AC_TIME_WITH_SYS_TIME
@maindex TIME_WITH_SYS_TIME
@code{AC_HEADER_TIME}
@item AC_UID_T
@maindex UID_T
@code{AC_TYPE_UID_T}
@item AC_UTIME_NULL
@maindex UTIME_NULL
@code{AC_FUNC_UTIME_NULL}
@item AC_VFORK
@maindex VFORK
@code{AC_FUNC_VFORK}
@item AC_VPRINTF
@maindex VPRINTF
@code{AC_FUNC_VPRINTF}
@item AC_WAIT3
@maindex WAIT3
@code{AC_FUNC_WAIT3}
@item AC_WARN
@maindex WARN
@code{AC_MSG_WARN}
@item AC_WORDS_BIGENDIAN
@maindex WORDS_BIGENDIAN
@code{AC_C_BIGENDIAN}
@item AC_YYTEXT_POINTER
@maindex YYTEXT_POINTER
@code{AC_DECL_YYTEXT}
@end table

@node Environment Variable Index, Output Variable Index, Old Macro Names, Top
@unnumbered Environment Variable Index

以下は、Autoconfが参照する環境変数の名前を、アルファベット順に
並べたリストです。

@printindex ev

@node Output Variable Index, Preprocessor Symbol Index, Environment Variable Index, Top
@unnumbered Output Variable Index

以下はAutoconfが(@file{Makefile}などの)出力ファイルを作成する際に、
置換を行う変数名のアルファベット順リストです。
置換動作に関しては@xref{Setting Output Variables}を参照。

@printindex ov

@node Preprocessor Symbol Index, Macro Index, Output Variable Index, Top
@unnumbered Preprocessor Symbol Index

以下は、Autoconfマクロが定義するCプリプロセッサシンボルの
アルファベット順リストです。
Autoconfを利用する場合、Cソースコード中の@code{#if}ディレクティブで
以下のシンボルを使う必要があります。

@printindex cv

@node Macro Index,  , Preprocessor Symbol Index, Top
@unnumbered Macro Index

以下は、Autoconfマクロのアルファベット順リストです。
リストを使いやすくするため、マクロ名先頭の@samp{AC_}は除いてあります。

@printindex ma

@contents
@bye

FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>