\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.12
@set VERSION 2.12
@set UPDATED November 1996

@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 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
@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 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)
@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::                       初期化と出力。
* Existing Tests::              特定の機能を調べるマクロ。
* Writing Tests::               新しい機能検査を書く方法。
* Results::                     機能検査の結果からすること。
* Writing Macros::              Autoconfに新しいマクロを追加する。
* Manual Configuration::        推測できない機能を選択する。
* Site Configuration::          @code{configure}のためのローカルのデフォルト。
* Invoking configure::          Autoconfの出力の使い方。
* Invoking config.status::      設定の再生成。
* Questions::                   Autoconfに関する質問と答。
* Upgrading::                   バージョン1からのアップグレードのこつ。
* History::                     Autoconfの歴史。
* Old Macro Names::             過去との互換性のためのマクロ。
* Environment Variable Index::  使用される環境変数の索引。
* Output Variable Index::       出力ファイルで設定される変数の索引。
* Preprocessor Symbol Index::   定義されるCプリプロセッサシンボルの索引。
* Macro Index::                 Autoconfマクロの索引。

 --- The Detailed Node Listing ---

@code{configure}スクリプトの作成

* Writing configure.in::        Autoconf入力ファイルに何を入れるか。
* Invoking autoscan::           半自動@file{configure.in}作成。
* Invoking ifnames::            ソースコードの条件の一覧表示。
* Invoking autoconf::           設定スクリプトを作成する方法。
* Invoking autoreconf::         複数の@code{configure}スクリプトを再生成する。

初期化と出力ファイル

* Input::                       Autoconfがファイルを見つける場所。
* Output::                      出力ファイルの作成。
* Makefile Substitutions::      @file{Makefile}で出力変数を使う。
* Configuration Headers::       設定ヘッダファイルの作成。
* Subdirectories::              独立したパッケージを一緒に設定する。
* Default Prefix::              デフォルトのインストールプレフィクスを変
                                  更する。
* Versions::                    @code{configure}のバージョン番号。

Makefileでの置換

* Preset Output Variables::     常に設定される出力変数。
* Build Directories::           複数の並行コンパイルをサポートする。
* Automatic Remaking::          設定のためのMakfileのルール。

設定ヘッダファイル

* Header Templates::            設定ヘッダのための入力。
* Invoking autoheader::         設定テンプレートの作成方法。

既存のテスト

* Alternative Programs::        代わりのプログラムの選択。
* Libraries::                   存在しないかもしれないライブラリのアーカイブ。
* Library Functions::           存在いないかもしれないCライブラリの関数。
* Header Files::                存在しないかもしれないヘッダファイル。
* Structures::                  存在しないかもしれない構造体やそのメンバ。
* Typedefs::                    存在しないかもしれない@code{typedef}。
* Compiler Characteristics::    Cコンパイラやマシンアーキテクチャの特性。
* System Services::             オペレーティングシステムのサービス。
* UNIX Variants::               特定のUNIXの変種に関するkludge。

代わりにプログラム

* Particular Programs::         特定のプログラムを見つけるための特別な扱い。
* Generic Programs::            他のプログラムを見つける方法。

ライブラリの関数

* Particular Functions::        特定の関数を見つけるための特別な扱い。
* Generic Functions::           他の関数を見つける方法。

ヘッダファイル

* Particular Headers::          特定のヘッダを見つけるための特別な扱い。
* Generic Headers::             他のヘッダを見つける方法。

Typedef

* Particular Typedefs::         特定の型を見つけるための特別な扱い。
* Generic Typedefs::            他の型を見つける方法。

テストを書く

* Examining Declarations::      ヘッダファイルと宣言の検査。
* Examining Syntax::            言語構文機能の検査。
* Examining Libraries::         関数とグローバル変数の検査。
* Run Time::                    実行時の機能のテスト。
* Portable Shell::              シェルスクリプトの移植性の落し穴。
* Testing Values and Files::    文字列とファイルの調査。
* Multiple Cases::              複数の可能性のある変数のテスト。
* Language Choice::             テストに使う言語の選択。

実行時の振舞いを調べる

* Test Programs::               テストプログラムの実行。
* Guidelines::                  テストプログラムを書く一般的な規則。
* Test Functions::              テストプログラムでの落し穴を避ける。

テストの結果

* Defining Symbols::            Cプリプロセッサシンボルの定義。
* Setting Output Variables::    出力ファイルでの変数置換。
* Caching Results::             後の@code{configure}の実行を速くする。
* Printing Messages::           進行状況や問題をユーザに知らせる。

結果のキャッシュ

* 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 menu

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

@display
A physicist, an engineer, and a computer scientist were
discussing the nature of God.  Surely a Physicist, said the
physicist, because early in the Creation, God made Light; and you
know, Maxwell's equations, the dual nature of electro-magnetic
waves, the relativist consequences@dots{} An Engineer!, said the
engineer, because before making Light, God split the Chaos into
Land and Water; it takes a hell of an engineer to handle that big
amount of mud, and orderly separation of solids from
liquids@dots{} The computer scientist shouted: And the Chaos,
where do you think it was coming from, hmm?

---Anonymous
@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})に
よるものです。
訳し間違いがあっても、犬も食いません。
疑問点があったら、「必ず原文を参照する」ようにしてください。
再配布などについては原文に従います。

この版は林芳樹 (@email{t90553@@mail.ecc.u-tokyo.ac.jp}) によって変更され
ています。この版の最新版はgnujdocプロジェクトのCVSリポジトリから取得でき
ます。詳しくは@uref{http://duff.kuicr.kyoto-u.ac.jp}を参照してください。

@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::        Autoconf入力ファイルに何を入れるか。
* Invoking autoscan::           半自動@file{configure.in}作成。
* Invoking ifnames::            ソースコードの条件の一覧表示。
* Invoking autoconf::           設定スクリプトを作成する方法。
* Invoking autoreconf::         複数の@code{configure}スクリプトを再生成する。
@end menu

@node Writing configure.in, Invoking autoscan, , 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::                       Autoconfがファイルを見つける場所。
* Output::                      出力ファイルの作成。
* Makefile Substitutions::      @file{Makefile}で出力変数を使う。
* Configuration Headers::       設定ヘッダファイルの作成。
* Subdirectories::              独立したパッケージを一緒に設定する。
* Default Prefix::              デフォルトのインストールプレフィクスを変
                                  更する。
* Versions::                    @code{configure}のバージョン番号。
@end menu

@node Input, Output, , 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-ja, The
GNU Coding Standards}.

@menu
* Preset Output Variables::     常に設定される出力変数。
* Build Directories::           複数の並行コンパイルをサポートする。
* Automatic Remaking::          設定のためのMakfileのルール。
@end menu

@node Preset Output Variables, Build Directories, , 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 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}や設定ヘッダファイルのような、
使っても使わなくてもいいファイルが全て含まれています。
@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}ディレクティブを使って、	
設定ヘッダファイルを他のどのヘッダファイルよりも前に
読み込む必要があります。
一番最初に読み込むのは、定義の一貫性を保つためです(例えば、@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::            設定ヘッダのための入力。
* Invoking autoheader::         設定テンプレートの作成方法。
@end menu

@node Header Templates, Invoking autoheader, , 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}に指定された
プレフィクスをそのままにします。
例えば、@code{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::        代わりのプログラムの選択。
* Libraries::                   存在しないかもしれないライブラリのアーカイブ。
* Library Functions::           存在いないかもしれないCライブラリの関数。
* Header Files::                存在しないかもしれないヘッダファイル。
* Structures::                  存在しないかもしれない構造体やそのメンバ。
* Typedefs::                    存在しないかもしれない@code{typedef}。
* Compiler Characteristics::    Cコンパイラやマシンアーキテクチャの特性。
* System Services::             オペレーティングシステムのサービス。
* UNIX Variants::               特定のUNIXの変種に関するkludge。
@end menu

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

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

@menu
* Particular Programs::         特定のプログラムを見つけるための特別な扱い。
* Generic Programs::            他のプログラムを見つける方法。
@end menu

@node Particular Programs, Generic 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
コンパイラがコマンドラインオプション
@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_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
現在の@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}を@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 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_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ライブラリファイル(および中身)が
存在するかどうかを調べます。

@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
@var{function}に指定されたCの関数が存在するか
どうかを調べます。
チェックはテスト用の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}と@var{action-if-not-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

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

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

@menu
* Particular Functions::        特定の関数を見つけるための特別な扱い。
* Generic Functions::           他の関数を見つける方法。
@end menu

@node Particular Functions, Generic 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.  */
#ifdef __GNUC__
# define alloca __builtin_alloca
#else
# 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_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::          特定のヘッダを見つけるための特別な扱い。
* Generic Headers::             他のヘッダを見つける方法。
@end menu

@node Particular Headers, Generic Headers, , 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, Compiler Characteristics, Structures, Existing Tests
@section Typedefs

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

@menu
* Particular Typedefs::         特定の型を見つけるための特別な扱い。
* Generic Typedefs::            他の型を見つける方法。
@end menu

@node Particular Typedefs, Generic 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 Compiler Characteristics, System Services, Typedefs, Existing Tests
@section 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}または設定ヘッダファイルで空にされます。
@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_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 System Services, UNIX Variants, Compiler Characteristics, Existing Tests
@section System Services

以下のマクロはOSのサービスや能力を調べます。

@defmac AC_SYS_INTERPRETER
@maindex SYS_INTERPRETER
このシステムに、
「スクリプトファイルの先頭に@samp{#! /bin/csh}のような行を付け加えることで、
スクリプトを実行するshellを選択する」機能がついているかどうか調べます。
このマクロを使用したあとは、
@code{configure.in}の中に記述するshellスクリプトの中で、
shell変数@code{ac_cv_sys_interpreter}を使えます。
このshell変数の値はシステムが@samp{#!}をサポートしていれば@samp{yes}、
していなければ@samp{no}になります。
@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:
@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::      ヘッダファイルと宣言の検査。
* Examining Syntax::            言語構文機能の検査。
* Examining Libraries::         関数とグローバル変数の検査。
* Run Time::                    実行時の機能のテスト。
* Portable Shell::              シェルスクリプトの移植性の落し穴。
* Testing Values and Files::    文字列とファイルの調査。
* Multiple Cases::              複数の可能性のある変数のテスト。
* Language Choice::             テストに使う言語の選択。
@end menu

@node Examining Declarations, Examining Syntax, , 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++コンパイラの文法的な機能を調べるためには、
@code{AC_TRY_COMPILE}を使ってそのキーワードや機能を使う小さなプログラムを
コンパイルしてみましょう。
@code{AC_TRY_COMPILE}を使うと、特定のシステムにしかない
構造体や構造体メンバを調べることもできます。
systems.

@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}、@code{#include}文が@var{include}の
記述からなるようなテスト用のCプログラムを書き出し、
それがコンパイラでコンパイルできるかどうか調べます。
もしコンパイルできたなら、shellコマンド@var{action-if-found}を実行します。
もしできなかったら@var{action-if-not-found}を実行します。
このマクロはコンパイルをするときに
@code{CFLAGS}、@code{CXXFLAGS}、それから@code{CPPFLAGS}の値を使います。
このマクロはリンクを行おうとはしません(コンパイルしかしません)。
テストのためにリンクもしたい場合、@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}を使って
テストプログラムをコンパイルしてみます。
このマクロは(@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
このマクロは、
関数の中身が@var{function-body}、@code{#include}文が@var{include}の
記述からなるようなテスト用のCプログラムを書き出し、
それがコンパイラでコンパイルでき、かつリンクできるかどうか調べます。
もし成功したなら、shellコマンド@var{action-if-found}を実行します。
もしできなかったら@var{action-if-not-found}を実行します。
このマクロは@code{CFLAGS}、@code{CXXFLAGS}、@code{CPPFLAGS}、
@code{LDFLAGS}、それから@code{LIBS}の値を使います。
@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::               テストプログラムの実行。
* Guidelines::                  テストプログラムを書く一般的な規則。
* Test Functions::              テストプログラムでの落し穴を避ける。
@end menu

@node Test Programs, Guidelines, , 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{[}で起動されることがあります。しかし、それは@code{m4}
のクォート文字なので、Autoconfのコードでそれを使うと問題を巻き起します。

@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}を使ってください。4.3BSDには存在しないので、@samp{test -x}
は使わないでください。

別の移植できないシェルプログラム構造は
@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

演算の中には、UNIXの異種に依存して、複数の方法で達成できるものがあります。
それらを調べることは、本質的には ``case 文'' を要求します。Autoconfは直
接にはそれを提供しません。しかし、演算を実行する方法がもう見つかったかど
うか、と同調するシェル変数を使うことで簡単にsimulateすることができます。

これはシェル変数@code{fstype}を使って、残りの場合を調べる必要があるかど
うかを覚えておく例です。

@example
@group
AC_MSG_CHECKING(how to get filesystem type)
fstype=no
# これらのテストの順番は重要です。
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
# (残りの分岐はここでは省略されています。)
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{cross_compiling}を、もし
@code{AC_PROG_CC}が実行されている場合は、それにより計算された値に設定し、
そうでない場合は空に設定します。
@end defmac

@defmac AC_LANG_CPLUSPLUS
@maindex LANG_CPLUSPLUS
コンパイルテストを@code{CXX}と@code{CXXCPP}を使って行い、テストプログラ
ムの拡張子には@file{.C}を使います。シェル変数@code{cross_compiling}をも
し@code{AC_PROG_CXX}が実行されていれば、それにより計算された値に設定し、
そうない場合は空に設定します。
@end defmac

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

@defmac AC_LANG_RESTORE
@maindex LANG_RESTORE
スタックの一番上に保存されている言語を@code{AC_LANG_SAVE}で設定されてい
るように選択します。このマクロは@code{AC_LANG_C}か
@code{AC_LANG_CPLUSPLUS}のどちらか、@code{AC_LANG_SAVE}が最後に呼ばれた
時点に一番近いところで実行されたものと等価です。

このマクロを@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::            Cプリプロセッサシンボルの定義。
* Setting Output Variables::    出力ファイルでの変数置換。
* Caching Results::             後の@code{configure}の実行を速くする。
* Printing Messages::           進行状況や問題をユーザに知らせる。
@end menu

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

機能テストに対応してとられる普通の動作は、テストの結果を示すCプリプロセッ
サシンボルを定義することです。これは@code{AC_DEFINE}や
@code{AC_DEFINE_UNQUOTED}を呼ぶことで行われます。

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

@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{AC_OUTPUT}はテンプレートファイルの@code{#define}文に正しい値を置換
することでヘッダファイルを作成します。このような出力に関する情報は、
@xref{Configuration Headers}.

@defmac AC_DEFINE (@var{variable} @r{[}, @var{value}@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}を使ってください。以下の例は
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{]})
@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}に出力ファイル(普通
はいくつかの@file{Makefile})に変数@var{variable}を置換させるようにします。
これは@code{AC_OUTPUT}は入力ファイルの@samp{@@@var{variable}@@}を
@code{AC_OUTPUT}が呼ばれたときのシェル変数@var{variable}の値を置換すると
いうことです。@var{variable}の値は改行文字を含んでいるべきではありません。
@end defmac

@defmac AC_SUBST_FILE (@var{variable})
@maindex SUBST_FILE
Another way to create an output variable from a shell variable.  Make
@code{AC_OUTPUT} insert (without substitutions) the contents of the file
named by shell variable @var{variable} into output files.  This means
that @code{AC_OUTPUT} will replace instances of
@samp{@@@var{variable}@@} in output files (such as @file{Makefile.in})
with the contents of the file that the shell variable @var{variable}
names when @code{AC_OUTPUT} is called.  Set the variable to
@file{/dev/null} for cases that do not have a file to insert.

This macro is useful for inserting @file{Makefile} fragments containing
special dependencies or other @code{make} directives for particular host
or target types into @file{Makefile}s.  For example, @file{configure.in}
could contain:

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

@noindent
and then a @file{Makefile.in} could contain:

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

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

To avoid checking for the same features repeatedly in various
@code{configure} scripts (or repeated runs of one script),
@code{configure} saves the results of many of its checks in a @dfn{cache
file}.  If, when a @code{configure} script runs, it finds a cache file,
it reads from it the results from previous runs and avoids rerunning
those checks.  As a result, @code{configure} can run much faster than if
it had to perform all of the checks every time.

@defmac AC_CACHE_VAL (@var{cache-id}, @var{commands-to-set-it})
@maindex CACHE_VAL
Ensure that the results of the check identified by @var{cache-id} are
available.  If the results of the check were in the cache file that was
read, and @code{configure} was not given the @samp{--quiet} or
@samp{--silent} option, print a message saying that the result was
cached; otherwise, run the shell commands @var{commands-to-set-it}.
Those commands should have no side effects except for setting the
variable @var{cache-id}.  In particular, they should not call
@code{AC_DEFINE}; the code that follows the call to @code{AC_CACHE_VAL}
should do that, based on the cached value.  Also, they should not print
any messages, for example with @code{AC_MSG_CHECKING}; do that before
calling @code{AC_CACHE_VAL}, so the messages are printed regardless of
whether the results of the check are retrieved from the cache or
determined by running the shell commands.  If the shell commands are run
to determine the value, the value will be saved in the cache file just
before @code{configure} creates its output files.  @xref{Cache
Variable Names}, for how to choose the name of the @var{cache-id} variable.
@end defmac

@defmac AC_CACHE_CHECK (@var{message}, @var{cache-id}, @var{commands})
@maindex CACHE_CHECK
A wrapper for @code{AC_CACHE_VAL} that takes care of printing the
messages.  This macro provides a convenient shorthand for the most
common way to use these macros.  It calls @code{AC_MSG_CHECKING} for
@var{message}, then @code{AC_CACHE_VAL} with the @var{cache-id} and
@var{commands} arguments, and @code{AC_MSG_RESULT} with @var{cache-id}.
@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
@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}

Which member of the class of cache values this test applies to.
For example, which function (@samp{alloca}), program (@samp{gcc}), or
output variable (@samp{INSTALL}).

@item @var{additional-options}
Any particular behavior of the specific member that this test applies to.
For example, @samp{broken} or @samp{set}.  This part of the name may
be omitted if it does not apply.
@end table

The values assigned to cache variables may not contain newlines.
Usually, their values will be boolean (@samp{yes} or @samp{no}) or the
names of files or functions; so this is not an important restriction.

@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}参照)。

@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
@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機能のカテゴリを示しています。
Here are the categories used in Autoconf for
specific test macros, the kind of macro that you are more likely to
write.  They are also used for cache variables, in all-lowercase.  Use
them where applicable; where they're not, invent your own categories.

@table @code
@item C
C language builtin features.
@item DECL
Declarations of C variables in header files.
@item FUNC
Functions in libraries.
@item GROUP
UNIX group owners of files.
@item HEADER
Header files.
@item LIB
C libraries.
@item PATH
The full path names to files, including programs.
@item PROG
The base names of programs.
@item STRUCT
Definitions of C structures in header files.
@item SYS
Operating system features.
@item TYPE
C builtin or declared types.
@item VAR
C variables in libraries.
@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
@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
@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

@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
@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}変数をもとにしたパス、または
ユーザのホームディレクトリなどの標準的な場所にします。
ファイルを置く位置を環境変数で設定してもよいでしょう。
プログラムはコンパイル時でなく実行時に、そのファイルを調べます。

Such site configuration information should be put in a file that is
edited @emph{only by users}, not by programs.  The location of the file
can either be based on the @code{prefix} variable, or be a standard
location such as the user's home directory.  It could even be specified
by an environment variable.  The programs should examine that file at
run time, rather than at compile time.  Run time configuration is more
convenient for users and makes the configuration process simpler than
getting the information while configuring.  @xref{Directory Variables, ,
Variables for Installation Directories, standards, GNU Coding
Standards}, for more information on where to put data files.

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

Autoconf supports changing the names of programs when installing them.
In order to use these transformations, @file{configure.in} must call the
macro @code{AC_ARG_PROGRAM}.

@defmac AC_ARG_PROGRAM
@maindex ARG_PROGRAM
@ovindex program_transform_name
Place in output variable @code{program_transform_name} a sequence of
@code{sed} commands for changing the names of installed programs.

If any of the options described below are given to @code{configure},
program names are transformed accordingly.  Otherwise, if
@code{AC_CANONICAL_SYSTEM} has been called and a @samp{--target} value
is given that differs from the host type (specified with @samp{--host}
or defaulted by @code{config.sub}), the target type followed by a dash
is used as a prefix.  Otherwise, no program name transformation is done.
@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
@subsection Transformation Options

You can specify name transformations by giving @code{configure} these
command line options:

@table @code
@item --program-prefix=@var{prefix}
prepend @var{prefix} to the names;

@item --program-suffix=@var{suffix}
append @var{suffix} to the names;

@item --program-transform-name=@var{expression}
perform @code{sed} substitution @var{expression} on the names.
@end table

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

These transformations are useful with programs that can be part of a
cross-compilation development environment.  For example, a
cross-assembler running on a Sun 4 configured with
@samp{--target=i960-vxworks} is normally installed as
@file{i960-vxworks-as}, rather than @file{as}, which could be confused
with a native Sun 4 assembler.

You can force a program name to begin with @file{g}, if you don't want
GNU programs installed on your system to shadow other programs with the
same name.  For example, if you configure GNU @code{diff} with
@samp{--program-prefix=g}, then when you run @samp{make install} it is
installed as @file{/usr/local/bin/gdiff}.

As a more sophisticated example, you could use
@example
--program-transform-name='s/^/g/; s/^gg/g/; s/^gless/less/'
@end example
@noindent
to prepend @samp{g} to most of the program names in a source tree,
excepting those like @code{gdb} that already have one and those like
@code{less} and @code{lesskey} that aren't GNU programs.  (That is
assuming that you have a source tree containing those programs that is
set up to use this feature.)

One way to install multiple versions of some programs simultaneously is
to append a version number to the name of one or both.  For example, if
you want to keep Autoconf version 1 around for awhile, you can configure
Autoconf version 2 using @samp{--program-suffix=2} to install the
programs as @file{/usr/local/bin/autoconf2},
@file{/usr/local/bin/autoheader2}, etc.

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

Here is how to use the variable @code{program_transform_name} in a
@file{Makefile.in}:

@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
If you have more than one program to install, you can do it in a loop:

@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

Whether to do the transformations on documentation files (Texinfo or
@code{man}) is a tricky question; there seems to be no perfect answer,
due to the several reasons for name transforming.  Documentation is not
usually particular to a specific architecture, and Texinfo files do not
conflict with system documentation.  But they might conflict with
earlier versions of the same files, and @code{man} pages sometimes do
conflict with system documentation.  As a compromise, it is probably
best to do name transformations on @code{man} pages but not on Texinfo
manuals.

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

Autoconf-generated @code{configure} scripts allow your site to provide
default values for some configuration values.  You do this by creating
site- and system-wide initialization files.

@evindex CONFIG_SITE
If the environment variable @code{CONFIG_SITE} is set, @code{configure}
uses its value as the name of a shell script to read.  Otherwise, it
reads the shell script @file{@var{prefix}/share/config.site} if it exists,
then @file{@var{prefix}/etc/config.site} if it exists.  Thus,
settings in machine-specific files override those in machine-independent
ones in case of conflict.

Site files can be arbitrary shell scripts, but only certain kinds of
code are really appropriate to be in them.  Because @code{configure}
reads any cache file after it has read any site files, a site file can
define a default cache file to be shared between all Autoconf-generated
@code{configure} scripts run on that system.  If you set a default cache
file in a site file, it is a good idea to also set the output variable
@code{CC} in that site file, because the cache file is only valid for a
particular compiler, but many systems have several available.

You can examine or override the value set by a command line option to
@code{configure} in a site file; options set shell variables that have
the same names as the options, with any dashes turned into underscores.
The exceptions are that @samp{--without-} and @samp{--disable-} options
are like giving the corresponding @samp{--with-} or @samp{--enable-}
option and the value @samp{no}.  Thus, @samp{--cache-file=localcache}
sets the variable @code{cache_file} to the value @samp{localcache};
@samp{--enable-warnings=no} or @samp{--disable-warnings} sets the variable
@code{enable_warnings} to the value @samp{no}; @samp{--prefix=/usr} sets the
variable @code{prefix} to the value @samp{/usr}; etc.

Site files are also good places to set default values for other output
variables, such as @code{CFLAGS}, if you need to give them non-default
values: anything you would normally do, repetitively, on the command
line.  If you use non-default values for @var{prefix} or
@var{exec_prefix} (wherever you locate the site file), you can set them
in the site file if you specify it with the @code{CONFIG_SITE}
environment variable.

You can set some cache values in the site file itself.  Doing this is
useful if you are cross-compiling, so it is impossible to check features
that require running a test program.  You could ``prime the cache'' by
setting those values correctly for that system in
@file{@var{prefix}/etc/config.site}.  To find out the names of the cache
variables you need to set, look for shell variables with @samp{_cv_} in
their names in the affected @code{configure} scripts, or in the Autoconf
@code{m4} source code for those macros.

The cache file is careful to not override any variables set in the site
files.  Similarly, you should not override command-line options in the
site files.  Your code should check that variables such as @code{prefix}
and @code{cache_file} have their default values (as set near the top of
@code{configure}) before changing them.

Here is a sample file @file{/usr/share/local/gnu/share/config.site}.  The
command @samp{configure --prefix=/usr/share/local/gnu} would read this
file (if @code{CONFIG_SITE} is not set to a different file).

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

You may be wondering, Why was Autoconf originally written?  How did it
get into its present form?  (Why does it look like gorilla spit?)  If
you're not wondering, then this chapter contains no information useful
to you, and you might as well skip it.  If you @emph{are} wondering,
then let there be light@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
@section Genesis

In June 1991 I was maintaining many of the GNU utilities for the Free
Software Foundation.  As they were ported to more platforms and more
programs were added, the number of @samp{-D} options that users had to
select in the @file{Makefile} (around 20) became burdensome.  Especially
for me---I had to test each new release on a bunch of different systems.
So I wrote a little shell script to guess some of the correct settings
for the fileutils package, and released it as part of fileutils 2.0.
That @code{configure} script worked well enough that the next month I
adapted it (by hand) to create similar @code{configure} scripts for
several other GNU utilities packages.  Brian Berliner also adapted one
of my scripts for his CVS revision control system.

Later that summer, I learned that Richard Stallman and Richard Pixley
were developing similar scripts to use in the GNU compiler tools; so I
adapted my @code{configure} scripts to support their evolving interface:
using the file name @file{Makefile.in} as the templates; adding
@samp{+srcdir}, the first option (of many); and creating
@file{config.status} files.

@node Exodus, Leviticus, Genesis, History
@section Exodus

As I got feedback from users, I incorporated many improvements, using
Emacs to search and replace, cut and paste, similar changes in each of
the scripts.  As I adapted more GNU utilities packages to use
@code{configure} scripts, updating them all by hand became impractical.
Rich Murphey, the maintainer of the GNU graphics utilities, sent me mail
saying that the @code{configure} scripts were great, and asking if I had
a tool for generating them that I could send him.  No, I thought, but
I should!  So I started to work out how to generate them.  And the
journey from the slavery of hand-written @code{configure} scripts to the
abundance and ease of Autoconf began.

Cygnus @code{configure}, which was being developed at around that time,
is table driven; it is meant to deal mainly with a discrete number of
system types with a small number of mainly unguessable features (such as
details of the object file format).  The automatic configuration system
that Brian Fox had developed for Bash takes a similar approach.  For
general use, it seems to me a hopeless cause to try to maintain an
up-to-date database of which features each variant of each operating
system has.  It's easier and more reliable to check for most features on
the fly---especially on hybrid systems that people have hacked on
locally or that have patches from vendors installed.

I considered using an architecture similar to that of Cygnus
@code{configure}, where there is a single @code{configure} script that
reads pieces of @file{configure.in} when run.  But I didn't want to have
to distribute all of the feature tests with every package, so I settled
on having a different @code{configure} made from each
@file{configure.in} by a preprocessor.  That approach also offered more
control and flexibility.

I looked briefly into using the Metaconfig package, by Larry Wall,
Harlan Stenn, and Raphael Manfredi, but I decided not to for several
reasons.  The @code{Configure} scripts it produces are interactive,
which I find quite inconvenient; I didn't like the ways it checked for
some features (such as library functions); I didn't know that it was
still being maintained, and the @code{Configure} scripts I had
seen didn't work on many modern systems (such as System V R4 and NeXT);
it wasn't very flexible in what it could do in response to a feature's
presence or absence; I found it confusing to learn; and it was too big
and complex for my needs (I didn't realize then how much Autoconf would
eventually have to grow).

I considered using Perl to generate my style of @code{configure} scripts,
but decided that @code{m4} was better suited to the job of simple
textual substitutions: it gets in the way less, because output is
implicit.  Plus, everyone already has it.  (Initially I didn't rely on
the GNU extensions to @code{m4}.)  Also, some of my friends at the
University of Maryland had recently been putting @code{m4} front ends on
several programs, including @code{tvtwm}, and I was interested in trying
out a new language.

@node Leviticus, Numbers, Exodus, History
@section Leviticus

Since my @code{configure} scripts determine the system's capabilities
automatically, with no interactive user intervention, I decided to call
the program that generates them Autoconfig.  But with a version number
tacked on, that name would be too long for old UNIX file systems, so
I shortened it to Autoconf.

In the fall of 1991 I called together a group of fellow questers after
the Holy Grail of portability (er, that is, alpha testers) to give me
feedback as I encapsulated pieces of my handwritten scripts in @code{m4}
macros and continued to add features and improve the techniques used in
the checks.  Prominent among the testers were
@ifinfo
Franc,ois
@end ifinfo
@tex
Fran\c cois
@end tex
Pinard, who came up with the idea of making an @file{autoconf} shell
script to run @code{m4} and check for unresolved macro calls; Richard
Pixley, who suggested running the compiler instead of searching the file
system to find include files and symbols, for more accurate results;
Karl Berry, who got Autoconf to configure @TeX{} and added the
macro index to the documentation; and Ian Taylor, who added support for
creating a C header file as an alternative to putting @samp{-D} options
in a @file{Makefile}, so he could use Autoconf for his UUCP package.  The
alpha testers cheerfully adjusted their files again and again as the
names and calling conventions of the Autoconf macros changed from
release to release.  They all contributed many specific checks, great
ideas, and bug fixes.

@node Numbers, Deuteronomy, Leviticus, History
@section Numbers

In July 1992, after months of alpha testing, I released Autoconf 1.0,
and converted many GNU packages to use it.  I was surprised by how
positive the reaction to it was.  More people started using it than I
could keep track of, including people working on software that wasn't
part of the GNU Project (such as TCL, FSP, and Kerberos V5).
Autoconf continued to improve rapidly, as many people using the
@code{configure} scripts reported problems they encountered.

Autoconf turned out to be a good torture test for @code{m4}
implementations.  UNIX @code{m4} started to dump core because of the
length of the macros that Autoconf defined, and several bugs showed up
in GNU @code{m4} as well.  Eventually, we realized that we needed to use
some features that only GNU @code{m4} has.  4.3BSD @code{m4}, in
particular, has an impoverished set of builtin macros; the System V
version is better, but still doesn't provide everything we need.

More development occurred as people put Autoconf under more stresses
(and to uses I hadn't anticipated).  Karl Berry added checks for X11.
david zuhn contributed C++ support.
@ifinfo
Franc,ois
@end ifinfo
@tex
Fran\c cois
@end tex
Pinard made it diagnose invalid arguments.  Jim Blandy bravely coerced
it into configuring GNU Emacs, laying the groundwork for several later
improvements.  Roland McGrath got it to configure the GNU C Library,
wrote the @code{autoheader} script to automate the creation of C header
file templates, and added a @samp{--verbose} option to @code{configure}.
Noah Friedman added the @samp{--macrodir} option and @code{AC_MACRODIR}
environment variable.  (He also coined the term @dfn{autoconfiscate} to
mean ``adapt a software package to use Autoconf''.)  Roland and Noah
improved the quoting protection in @code{AC_DEFINE} and fixed many bugs,
especially when I got sick of dealing with portability problems from
February through June, 1993.

@node Deuteronomy, , Numbers, History
@section Deuteronomy

A long wish list for major features had accumulated, and the effect of
several years of patching by various people had left some residual
cruft.  In April 1994, while working for Cygnus Support, I began a major
revision of Autoconf.  I added most of the features of the Cygnus
@code{configure} that Autoconf had lacked, largely by adapting the
relevant parts of Cygnus @code{configure} with the help of david zuhn
and Ken Raeburn.  These features include support for using
@file{config.sub}, @file{config.guess}, @samp{--host}, and
@samp{--target}; making links to files; and running @code{configure}
scripts in subdirectories.  Adding these features enabled Ken to convert
GNU @code{as}, and Rob Savoye to convert DejaGNU, to using Autoconf.

I added more features in response to other peoples' requests.  Many
people had asked for @code{configure} scripts to share the results of
the checks between runs, because (particularly when configuring a large
source tree, like Cygnus does) they were frustratingly slow.  Mike
Haertel suggested adding site-specific initialization scripts.  People
distributing software that had to unpack on MS-DOS asked for a way to
override the @file{.in} extension on the file names, which produced file
names like @file{config.h.in} containing two dots.  Jim Avera did an
extensive examination of the problems with quoting in @code{AC_DEFINE}
and @code{AC_SUBST}; his insights led to significant improvements.
Richard Stallman asked that compiler output be sent to @file{config.log}
instead of @file{/dev/null}, to help people debug the Emacs
@code{configure} script.

I made some other changes because of my dissatisfaction with the quality
of the program.  I made the messages showing results of the checks less
ambiguous, always printing a result.  I regularized the names of the
macros and cleaned up coding style inconsistencies.  I added some
auxiliary utilities that I had developed to help convert source code
packages to use Autoconf.  With the help of
@ifinfo
Franc,ois
@end ifinfo
@tex
Fran\c cois
@end tex
Pinard, I made the macros not interrupt each others' messages.
(That feature revealed some performance bottlenecks in GNU @code{m4},
which he hastily corrected!)
I reorganized the documentation around problems people want to solve.
And I began a testsuite, because experience
had shown that Autoconf has a pronounced tendency to regress when we
change it.

Again, several alpha testers gave invaluable feedback, especially
@ifinfo
Franc,ois
@end ifinfo
@tex
Fran\c cois
@end tex
Pinard, Jim Meyering, Karl Berry, Rob Savoye, Ken Raeburn, and Mark Eichin.

Finally, version 2.0 was ready.  And there was much rejoicing.
(And I have free time again.  I think.  Yeah, right.)

@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
