\input jtexinfo

     START-INFO-DIR-ENTRY
     * Autoconf: (autoconf).         Create source code configuration scripts.
     END-INFO-DIR-ENTRY

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 m4 macro package.

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

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

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.

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

Introduction
************

     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... 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... The computer scientist shouted: And the Chaos,
     where do you think it was coming from, hmm?

     ---Anonymous

     物理学者と工学者と計算機科学者の 3 人が神の本質について語りあっていた。
     「もちろんそれは物理学者さ」と、物理学者は言った。天地想像の最初に神は光
     を創造した。それは御存知の通り Maxwell の方程式そのものだ。電磁波、そし
     て相対論的に結果は... 「工学者さ！」と、工学者は言った。神は光を創造
     する前に混沌から大地と海を分離したんだぜ。そんな大量の泥を扱えるのは工学
     者だけさ。秩序正しく液体と固体を分離するということは... その時、計算
     機科学者が叫んだ : じゃあ、混沌はどこから来たっていうんだい? え? もちろ
     んそれは...

     ---作者不詳

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のしてくれないことがいくつか必要になります。例えば、各ターゲットプログラムのためのMakefileの自動生成や、システムに欠けている標準ライブラリ関数やヘッダファイルを補う、などです。これらを自動化するための作業は現在進行中です。

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

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

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

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

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

訳註2: 伊藤いとぢゅん純一郎氏の和訳に私、山内斉 (yamauchi@archi.is.tohoku.ac.jp)は大変助けられました。全体を読む気が起きたのは和訳のおかげです。伊藤氏の訳は途中とはいえ、公開して下さったおかげで、私は非常に助けられ、感謝の意を込めて残る部分を和訳しました。私が訳を行なった部分についても、疑問点は「必ず原文を参照」して下さい。訳語が統一されていない部分もあると思いますが、御容赦下さい。(1999/11)

訳註3: というわけで山内氏の訳をマージし、ほとんど訳しあがりました。(1999/11)

Making configure Scripts
************************

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

  * ひとつまたは複数(パッケージ中の各サブディレクトリにひとつづつ)のMakefile。 (see Makefile Substitutions)

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

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

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

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

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

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

配布用ソフトウェアパッケージの作成時に使われるファイル:

     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

ソフトウェアパッケージの設定時に使われるファイル:

                            .-------------> config.cache
     configure* ------------+-------------> config.log
                            |
     [config.h.in] -.       v            .-> [config.h] -.
                    +--> config.status* -+               +--> make*
     Makefile.in ---'                    `-> Makefile ---'

Writing configure.in
====================

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

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

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

     AC_INIT(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
     AC_OUTPUT([FILE...])

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

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

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

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

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

Using autoscan to Create configure.in
=====================================

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

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

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

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

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

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

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

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

Using ifnames to List Conditionals
==================================

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

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

ifnamesは以下のオプションを受け付けます:

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

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

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

Using autoconf to Create configure
==================================

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

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

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

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

--localdir=DIR
-l DIR
     aclocal.m4を探すとき、カレントディレクトリでなしにディレクトリDIRを探しにいきます。

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

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

Using autoreconf to Update configure Scripts
============================================

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

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

autoreconf は、同一のディレクトリツリー上にある、 (aclocal.m4 と acconfig.h を共有している) 巨大なパッケージの各部分となっているようなディレクトリ群や、独立したパッケージ (それぞれの aclocal.m4 と acconfig.h を持つもの) のディレクトリ群のどちらもサポートしません。もし、--localdir を利用した場合には、それらは全て同じパッケージとみなされ、--localdir を利用しない場合には、それぞれのディレクトリは分離したディレクトリとみなされます。この制限は将来的には解消される予定です。

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

autoreconfは以下のオプションを受け付けます:

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

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

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

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

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

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

Initialization and Output Files
*******************************

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

Finding configure Input
=======================

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

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

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

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

Creating Output Files
=====================

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

 -- Macro: AC_OUTPUT ([FILE... [, EXTRA-CMDS [, INIT-CMDS]]])
     出力ファイルを生成します。このマクロは 1度だけ、configure.inの末尾で呼び出す必要があります。マクロの引数FILE...は、スペースで区切られた出力ファイル列です; これは空でも構いません。このマクロは、入力ファイルを FILEへ出力変数の値を置換しながらコピーすることで生成します。入力ファイルの名前はデフォルトでは FILE.inです。出力変数の使い方についてはsee Makefile Substitutionsを参照してください。出力変数を定めるためには、 see Setting Output Variablesを参照してください。このマクロは出力先のディレクトリがなければディレクトリを作成します(が、さらに親のディレクトリは作成されません)。通常、このマクロを使って生成するファイルはMakefileですが、他のファイル、たとえば .gdbinitを生成するのにも使えます。

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

     たいてい、AC_OUTPUTは以下のように呼び出されます:

          AC_OUTPUT(Makefile src/Makefile man/Makefile X/Imakefile)

     入力ファイルの名前は、FILEのあとにコロンをつけて、そのあとに入力ファイル名を繋げることで変更できます。たとえば:

          AC_OUTPUT(Makefile:templates/top.mk lib/Makefile:templates/lib.mk)
          AC_OUTPUT(Makefile:templates/vars.mk:Makefile.in:templates/rules.mk)

     こうすることで、ファイル名をMS-DOSでも使えるフォーマットにしたり、ファイルの前後にメッセージ(訳註: boilerplate)をつけたりすることができます。

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

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

          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])

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

 -- Macro: AC_PROG_MAKE_SET
     makeが変数MAKEを設定しているなら、変数SET_MAKEを空にします。そうでない場合、SET_MAKEをMAKE=makeに設定します。内部でAC_SUBSTを SET_MAKEを置換するように呼び出します。

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

     @SET_MAKE@

Substitutions in Makefiles
==========================

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

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

See Makefile Conventions (The GNU Coding Standards), for more information on what to put in Makefiles.

Preset Output Variables
-----------------------

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

 -- Variable: bindir
     ユーザが実行する実行ファイルを格納するディレクトリです。

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

          #! /bin/sh
          # @configure_input@

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

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

 -- Variable: exec_prefix
     アーキテクチャ依存のファイル名のプレフィックスです。

 -- Variable: includedir
     Cヘッダファイルをインストールする先のディレクトリ名です。

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

 -- Variable: libdir
     ライブラリファイルをインストールする先のディレクトリ名です。

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

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

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

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

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

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

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

 -- Variable: srcdir
     Makefileの処理すべきソースコードの入っているディレクトリ名です。

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

 -- Variable: top_srcdir
     パッケージのトップディレクトリです。トップディレクトリでは、 srcdirとおなじです。

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

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

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

 -- Variable: FFLAGS
     Fortran 77 コンパイラのためのデバッグ/最適化のオプションです。 configure が実行された環境でこん環境変数が指定されていなかった場合、 AC_PROG_F77 を呼び出した時のデフォルト値(または、呼び出さなかった場合には空)が設定されます。configure はこの変数の値を使って Fortran 77 コンパイラの feature を調べるためのプログラムをコンパイルします。

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

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

 -- Variable: LIBS
     リンカに渡す-lオプションと -Lです。

Build Directories
-----------------

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

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

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

     srcdir = @srcdir@
     VPATH = @srcdir@

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

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

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

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

     time.info: time.texinfo
             $(MAKEINFO) $(srcdir)/time.texinfo

Automatic Remaking
------------------

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

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

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

     ${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

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

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

Configuration Header Files
==========================

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

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

 -- Macro: AC_CONFIG_HEADER (HEADER-TO-CREATE ...)
     AC_OUTPUTにCプリプロセッサ向けの #defineディレクティブ入りのファイルを作成させ、@DEFS@を (shell変数DEFSの値でなく) -DHAVE_CONFIG_Hに置換させます。出力ファイル名はHEADER-TO-CREATEに、スペースで区切って指定します。通常、HEADER-TO-CREATEに使うファイル名はconfig.hです。

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

     通常、入力ファイルは HEADER-TO-CREATE.inという名前です; が、もし名前を変えたい場合には HEADER-TO-CREATEにコロンで区切った名前の列を繋げることで変えられます。たとえば:

          AC_CONFIG_HEADER(defines.h:defines.hin)
          AC_CONFIG_HEADER(defines.h:defs.pre:defines.h.in:defs.post)

     こうすることで、ファイル名をMS-DOSでも使えるフォーマットにしたり、ファイルの前後にメッセージ(訳註: boilerplate)をつけたりすることができます。

Configuration Header Templates
------------------------------

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

     AC_CONFIG_HEADER(conf.h)
     AC_CHECK_HEADERS(unistd.h)

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

     /* Define as 1 if you have unistd.h.  */
     #define HAVE_UNISTD_H 0

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

     /* Define if you have unistd.h.  */
     #undef HAVE_UNISTD_H

Using autoheader to Create config.h.in
--------------------------------------

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

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

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

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

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

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

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

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

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

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

Configuring Other Packages in Subdirectories
============================================

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

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

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

Default Prefix
==============

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

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

 -- Macro: AC_PREFIX_DEFAULT (PREFIX)
     デフォルトのインストールディレクトリプレフィクスを、/usr/local でなくPREFIXにします。

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

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

Version Numbers in configure
============================

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

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

          AC_PREREQ(1.8)

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

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

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

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

          AC_REVISION($Revision: 1.30 $)dnl

     configureに以下のような出力を生成します:

          #! /bin/sh
          # From configure.in Revision: 1.30

Existing Tests
**************

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

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

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

Alternative Programs
====================

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

Particular Program Checks
-------------------------

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

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

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

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

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

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

 -- Macro: AC_PROG_CC_C_O
     コンパイラがコマンドラインオプション -cと-oを同時に受け付けない場合、 NO_MINUS_C_MINUS_Oを定義します。

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

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

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

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

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

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

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

 -- Macro: AC_PROG_F77
     利用する Fortran 77 コンパイラを決定します。環境変数 F77 が存在していなかったら、 g77, f77, f2c の順に調べていきます。 output variable の F77にみつかったコンパイラの名前を設定します。 g77 (GNU の Fortran 77 コンパイラ) を使用する場合は、 AC_PROG_F77 は shell 変数 G77 を yes に設定し、そうでない場合には変数は空となります。もし、output variable FFLAGS が環境変数として設定されていない時、g77 の場合には -g -02 が設定されます(ただし、g77 が -g に対応していない場合には、 -O2 が設定されます)。そうでない場合、g77 でない Fortran 77 コンパイラのために、FFLAGS が-g に設定されます。

 -- Macro: AC_PROG_F77_C_O
     Fortran 77 コンパイラが -c と -o のオプションを同時に指定することに対応しているかどうか調べ、もし対応していない場合には F77_NO_MINUS_C_MINUS_O を定義します。

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

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

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

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

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

 -- Macro: AC_PROG_LEX
     flexがあったら、出力変数LEXを flexに、(もしlibfl.aが標準的な場所にあったら)LEXLIBを -lflに設定します。もしflexがなかったら、 LEXをlexに、 LEXLIBを-llに設定します。

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

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

     言い替えれば、以下はうまく動きません:

          $(LN_S) foo /x/bar

     ので、かわりにこうしましょう:

          (cd /x && $(LN_S) foo bar)

 -- Macro: AC_PROG_RANLIB
     もしranlibがみつかったら、出力変数 RANLIBをranlibに設定します。さもなくば、:(なにもしない)に設定します。

 -- Macro: AC_PROG_YACC
     もしbisonがみつかったら、出力変数 YACCをbison -yに設定します。かわりにbyaccがみつかったら、出力変数 YACCをbyaccに設定します。さもなくば、yaccに設定します。

Generic Program and File Checks
-------------------------------

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

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

 -- Macro: AC_CHECK_FILE (FILE [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     FILE というファイルがネイティブなシステム上に存在するかどうかを調べます。このマクロが与えられた場合、もしファイルが存在した場合には、 ACTION-IF-FOUND が実行され、ない場合には ACTION-IF-NOT-FOUND が実行されます。

 -- Macro: AC_CHECK_FILES (FILES[, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     AC_CHECK_FILE FILES に並べられた各ファイルにつきそれぞれ一回づつ AC_CHECK_FILE を適用します。さらに、各ファイルが見つかるごとに HAVEFILE を 1 にセットします。

 -- Macro: AC_CHECK_PROG (VARIABLE, PROG-TO-CHECK-FOR, VALUE-IF-FOUND [, VALUE-IF-NOT-FOUND [, PATH, [ REJECT ]]])
     プログラムPROG-TO-CHECK-FORがPATH中にあるかどうかを調べます。もし発見された場合VARIABLEを VALUE-IF-FOUNDに設定します。発見されなかった場合 (VALUE-IF-NOT-FOUNDが指定されていた場合は) VALUE-IF-NOT-FOUNDに設定します。このマクロは、REJECT (絶対パスのファイル名)をサーチパス上で発見してもそれは無視します。この場合、VARIABLEはパス上でみつかった PROG-TO-CHECK-FORで、REJECTではないファイルの絶対パス名になります。 VARIABLEが既に設定されていた場合、なにもしません。 VARIABLEのために、AC_SUBSTを呼び出します。

 -- Macro: AC_CHECK_PROGS (VARIABLE, PROGS-TO-CHECK-FOR [, VALUE-IF-NOT-FOUND [, PATH]])
     PROGS-TO-CHECK-FORに指定された、スペースで区切られたプログラム名たちがPATH上にあるかどうかを調べます。もしあった場合、そのプログラム名をVARIABLEに設定します。さもなくば、次のプログラム名を探します。もし、指定された全てのプログラムがなかった場合、 VALUE-IF-NOT-FOUNDの値をVARIABLEに設定します。もしVALUE-IF-NOT-FOUNDが指定されていなかったら、 VARIABLEの値は変更されません。 VARIABLEのために、AC_SUBSTを呼び出します。

 -- Macro: AC_CHECK_TOOL (VARIABLE, PROG-TO-CHECK-FOR [, VALUE-IF-NOT-FOUND [, PATH]])
     AC_CHECK_PROGと同様ですが、PROG-TO-CHECK-FORの先頭にAC_CANONICAL_HOSTで判定されたホストタイプをつけたものを最初に探します(see Canonicalizing参照)。例えば、ユーザがconfigure --host=i386-gnuを実行し、その中で

          AC_CHECK_TOOL(RANLIB, ranlib, :)

     というマクロが使われていたなら、まずパス上の i386-gnu-ranlibが探され、もしあったなら i386-gnu-ranlibをRANLIBに設定します。プログラムがなければRANLIBは:にされます。

 -- Macro: AC_PATH_PROG (VARIABLE, PROG-TO-CHECK-FOR [, VALUE-IF-NOT-FOUND [, PATH]])
     AC_CHECK_PROGと同様ですが、プログラムが発見された場合VARIABLEを PROG-TO-CHECK-FORの全体に設定します。

 -- Macro: AC_PATH_PROGS (VARIABLE, PROGS-TO-CHECK-FOR [, VALUE-IF-NOT-FOUND [, PATH]])
     AC_CHECK_PROGSと同様ですが、 PROGS-TO-CHECK-FORの中のいずれかが見付かったら、プログラムの絶対パスを VARIABLEに設定します。

Library Files
=============

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

 -- Macro: AC_CHECK_LIB (LIBRARY, FUNCTION [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND [, OTHER-LIBRARIES]]])
     FUNCTIONに指定されたC、C++またはFortran 77の関数が存在するかどうかを調べます。言語処理系は指定されたもの(see Language Choice)を使います。チェックはテスト用のプログラムとライブラリ LIBRARYを一緒にリンクしてみて成功するかどうかで行われます。 LIBRARYはライブラリのベースネームです。例えば、-lmpを調べる場合、mpを引数LIBRARYに指定することになります。

     ACTION-IF-FOUNDには、リンクが成功した場合に呼び出されるshellコマンド列を指定します。 ACTION-IF-NOT-FOUNDには、リンクが失敗したときに呼び出されるshellコマンド列を指定します。 ACTION-IF-FOUNDとACTION-IF-NOT-FOUNDが両方とも指定されなかった場合、デフォルトの動作になります。デフォルトの動作はLIBに-lLIBRARYを追加し、 HAVE_LIBLIBRARYを(全部大文字)定義するようになっています。

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

 -- Macro: AC_HAVE_LIBRARY (LIBRARY, [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND [, OTHER-LIBRARIES]]])
     このマクロはAC_CHECK_LIBを、引数FUNCTIONを mainにして呼び出すのと同じです。引数LIBRARYは fooでも-lfooでも、あるいはlibfoo.a とでも指定できます。これらの全ての場合に、コンパイラには引数-lfooが渡ります。 LIBRARYにshell変数を渡すことはできません。 LIBRARYは文字列リテラルである必要があります。このマクロはobsoleteです。

 -- Macro: AC_SEARCH_LIBS (FUNCTION, SEARCH-LIBS [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND [, OTHER-LIBRARIES]]])
     FUNCTIONがまだみつかっていなければ、 FUNCTIONが含まれているライブラリを探します。このマクロは最初にAC_TRY_LINK_FUNCをライブラリ指定なしで呼び出し、駄目ならSEARCH-LIBSのライブラリを順に指定して呼び出すのと等価です。

     関数がみつかったらACTION-IF-FOUNDを実行します。みつからなかったらACTION-IF-NOT-FOUNDを実行します。

     LIBRARYをリンクしたときに未定義シンボルが出て、他のライブラリをリンクすればそれが解決するのであれば、追加のライブラリをOTHER-LIBRARIESにスペースで区切って指定してください。例えば-lXt -lX11とか。 OTHER-LIBRARIESを指定しなかった場合、このマクロはFUNCTIONの認識に失敗します。追加のライブラリがなければ、テストプログラムのリンクは常に失敗するからです。

 -- Macro: AC_SEARCH_LIBS (FUNCTION, SEARCH-LIBS[, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     This macro is equivalent to calling AC_TRY_LINK_FUNC once for each library listed in SEARCH-LIBS.  Add -lLIBRARY to LIBS for the first library found to contain FUNCTION, and execute ACTION-IF-FOUND.  Otherwise execute ACTION-IF-NOT-FOUND.

     訳註: このエントリはどうみても原文での削除忘れである。

Library Functions
=================

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

Particular Function Checks
--------------------------

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

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

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

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

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

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

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

 -- Macro: AC_FUNC_FNMATCH
     ライブラリ関数fnmatchが存在し、かつ動作するなら、 HAVE_FNMATCHを定義します (ちなみに、SunOS 5.4付属のものは動きません)。

 -- Macro: AC_FUNC_GETLOADAVG
     システムのロードアベレージを得る方法をチェックします。現在のシステムでgetloadavgが利用できるなら、 HAVE_GETLOADAVGを定義し、 LIBSに必要なライブラリファイルを追加します。

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

      1. SVR4、DGUX、UMAXまたは UMAX4_3のうちであてはまるものを定義します。

      2. nlist.hがあった場合、NLIST_STRUCTを定義します。

      3. struct nlistにメンバn_unがあった場合、 NLIST_NAME_UNIONを定義します。

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

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

 -- Macro: AC_FUNC_GETMNTENT
     getmntentがライブラリファイル sun、seqおよびgenのいずれかに含まれているかどうか調べます (順に、Irix 4、PTX、Unixwareの場合のライブラリファイルです)。 getmntentが存在した場合、 HAVE_GETMNTENTを定義します。

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

 -- Macro: AC_FUNC_MEMCMP
     ライブラリ関数memcmpがないか、または(SunOS 4.1.3のように)8bitデータに対して使えない場合、memcmp.oを出力変数LIBOBJSに追加します。

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

 -- Macro: AC_FUNC_SELECT_ARGTYPES
     select 関数の引数のそれぞれが正しい型を通すかをテストします。そして、SELECT_TYPE_ARG1, SELECT_TYPE_ARG234, SELECT_TYPE_ARG5 にそれぞれの型を定義します。 SELECT_TYPE_ARG1 はデフォルトで int 型に、 SELECT_TYPE_ARG234 はデフォルトで int * 型に、 SELECT_TYPE_ARG5 はデフォルトで struct timeval * に定義されます。

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

 -- Macro: AC_FUNC_SETVBUF_REVERSED
     setvbufの第2引数がバッファリングの形式で、第3引数がバッファへのポインタの場合、 SETVBUF_REVERSEDを定義します。 SETVBUF_REVERSEDが定義されるのは、 release 3以前のSystem Vの場合です。

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

 -- Macro: AC_FUNC_STRFTIME
     strftimeがintlライブラリにあるかどうかを調べます (これはSCO UNIXのためです)。もしあった場合、HAVE_STRFTIMEを定義します。

 -- Macro: AC_FUNC_UTIME_NULL
     utime(FILE, NULL)がFILEのタイムスタンプを現在時刻に設定する場合、 HAVE_UTIME_NULLを定義します。

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

 -- Macro: AC_FUNC_VPRINTF
     vprintfが存在する場合、 HAVE_VPRINTFを定義します。ない場合に_doprntが存在したら、 HAVE_DOPRNTを定義します。ちなみに、vprintfが存在したら、 vfprintfとvsprintfも存在すると仮定して構いません。

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

Generic Function Checks
-----------------------

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

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

 -- Macro: AC_CHECK_FUNCS (FUNCTION... [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     スペースで区切られた複数のFUNCTIONのうち、実際存在するものについてHAVE_FUNCTION(全部大文字)を定義します。 ACTION-IF-FOUNDには、各々の関数がみつかったときに実行したいshellスクリプトを記述します。 ACTION-IF-FOUNDをbreakにすると、最初に関数が見つかったところでループを抜けることができます。 ACTION-IF-NOT-FOUNDには、各関数がみつからなかったときに実行されるshellスクリプトを記述します。

 -- Macro: AC_REPLACE_FUNCS (FUNCTION...)
     このマクロは、特定の関数FUNCTIONが存在しない場合に LIBOBJSにFUNCTION.oを追加します。この動作は、 AC_CHECK_FUNCSで ACTION-IF-NOT-FOUNDに「出力変数LIBOBJSにFUNCTION.oを追加する」と記述した場合と似ています。ライブラリの置き換え用の関数を定義するときには、プロトタイプ宣言を#ifndef HAVE_FUNCTIONでくくっておいた方がいいでしょう。システムにFUNCTIONがある場合、システム定義のincludeファイルのどこかにプロトタイプ宣言があるはずです。定義が矛盾するかもしれないから、システムにFUNCTIONがあるときには再定義を避けるべきです。

Header Files
============

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

Particular Header Checks
------------------------

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

 -- Macro: AC_DECL_SYS_SIGLIST
     sys_siglistがsignal.hまたはunistd.hで定義されているなら、 SYS_SIGLIST_DECLAREDを定義します。

 -- Macro: AC_DIR_HEADER
     AC_HEADER_DIRENTとAC_FUNC_CLOSEDIR_VOIDを呼ぶのと似ていますが、定義するCプリプロセッサマクロが違います。 AC_DIR_HEADERはどのヘッダファイルがみつかったのかを表すCプリプロセッサマクロを定義します。 AC_DIR_HEADER、およびこれにより定義されるCプリプロセッサマクロは obsoleteです。定義されるCプリプロセッサマクロは以下のとおり:

     dirent.h
          DIRENT

     sys/ndir.h
          SYSNDIR

     sys/dir.h
          SYSDIR

     ndir.h
          NDIR

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

 -- Macro: AC_HEADER_DIRENT
     以下のヘッダファイルの有無を調べます。そして、ヘッダファイルが存在しDIRを定義した最初のファイルについて以下のCプリプロセッサマクロを定義します:

     dirent.h
          HAVE_DIRENT_H

     sys/ndir.h
          HAVE_SYS_NDIR_H

     sys/dir.h
          HAVE_SYS_DIR_H

     ndir.h
          HAVE_NDIR_H

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

          #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

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

     このマクロはSCO Xenixのdirとxライブラリも検査します。

 -- Macro: AC_HEADER_MAJOR
     sys/types.hにmajor、minor、それから makedevが定義されておらず、 sys/mkdev.hで定義されている場合、 MAJOR_IN_MKDEVを定義します。 sys/sysmacros.hで定義されている場合、 MAJOR_IN_SYSMACROSを定義します。

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

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

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

          AC_HEADER_STDC
          AC_CHECK_FUNCS(strchr memcpy)

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

          #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

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

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

          #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

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

 -- Macro: AC_UNISTD_H
     unistd.hがあればHAVE_UNISTD_Hを定義します。このマクロはobsoleteです。かわりにAC_CHECK_HEADERS(unistd.h)を使ってください。

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

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

          #ifdef _POSIX_VERSION
          /* Code for POSIX.1 systems.  */
          #endif

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

 -- Macro: AC_USG
     strings.h、rindexやbzeroがないシステムなら USGを定義します。このマクロは string.h、strrchr、memset等が存在すると仮定しています。

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

Generic Header Checks
---------------------

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

 -- Macro: AC_CHECK_HEADER (HEADER-FILE, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     システムヘッダファイルHEADER-FILEがあったら ACTION-IF-FOUNDを実行します。なければACTION-IF-NOT-FOUNDを実行します。単にヘッダファイルがあったときにCプリプロセッサシンボルを定義したいだけなら、 AC_CHECK_HEADERSを使った方がいいでしょう。

 -- Macro: AC_CHECK_HEADERS (HEADER-FILE... [, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     スペースで区切られた複数のHEADER-FILEのうち、実際システムヘッダファイルが存在するものについて HAVE_HEADER-FILE(全部大文字)を定義します。 ACTION-IF-FOUNDには、各々のヘッダファイルがみつかったときに実行したいshellスクリプトを記述します。 ACTION-IF-FOUNDをbreakにすると、最初にヘッダファイルが見つかったところでループを抜けることができます。 ACTION-IF-NOT-FOUNDには、各ヘッダファイルがみつからなかったときに実行されるshellスクリプトを記述します。

Structures
==========

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

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

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

          #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

 -- Macro: AC_STRUCT_ST_BLKSIZE
     struct statにメンバst_blksizeが定義されているなら、 HAVE_ST_BLKSIZEを定義します。

 -- Macro: AC_STRUCT_ST_BLOCKS
     struct statにメンバst_blocksが定義されているなら、 HAVE_ST_BLOCKSを定義します。もしなければ、fileblocks.oを出力変数LIBOBJSに足します。

 -- Macro: AC_STRUCT_ST_RDEV
     struct statにメンバst_rdevが定義されているなら、 HAVE_ST_RDEVを定義します。

 -- Macro: AC_STRUCT_TM
     time.hでstruct tmが定義されていなければ、 TM_IN_SYS_TIMEを定義します。 TM_IN_SYS_TIMEは、struct tmの定義が欲しければ sys/time.hをincludeせよ、という意味です(訳註: 意訳)。

 -- Macro: AC_STRUCT_TIMEZONE
     現在のtimezoneを知る方法を推測します。 struct tmにメンバtm_zoneが定義されているなら、 HAVE_TM_ZONEを定義します。グローバル変数tznameが定義されていたら、HAVE_TZNAMEを定義します。

Typedefs
========

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

Particular Typedef Checks
-------------------------

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

 -- Macro: AC_TYPE_GETGROUPS
     GETGROUPS_Tを、 getgroupsの引数の型(配列の基底型)にあわせて、 gid_tまたはintに定義します。

 -- Macro: AC_TYPE_MODE_T
     mode_tが定義されていない場合、 Cプリプロセッサマクロmode_tをintに#defineします。

 -- Macro: AC_TYPE_OFF_T
     off_tが定義されていない場合、Cプリプロセッサマクロoff_tを longに#defineします。

 -- Macro: AC_TYPE_PID_T
     pid_tが定義されていない場合、Cプリプロセッサマクロpid_tを intに#defineします。

 -- Macro: AC_TYPE_SIGNAL
     signal.hで、関数signalが「返り値がvoidの関数へのポインタ(つまり、(void (*)())」を返す場合、RETSIGTYPEをvoidに定義します。さもなくば、RETSIGTYPEをintに定義します。

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

          RETSIGTYPE
          hup_handler ()
          {
          ...
          }

 -- Macro: AC_TYPE_SIZE_T
     size_tが定義されていなければ、Cプリプロセッサマクロsize_tを unsignedと定義します。

 -- Macro: AC_TYPE_UID_T
     uid_tが定義されていなければ、 Cプリプロセッサマクロuid_tをintに、 gid_tをintに定義します。

Generic Typedef Checks
----------------------

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

 -- Macro: AC_CHECK_TYPE (TYPE, DEFAULT)
     TYPEがsys/types.hで定義されていない場合、 Cプリプロセッサマクロを使って C (or C++)のビルトインタイプDEFAULT (例えば、shortとかunsignedとか)に#defineします。もしヘッダファイルが存在するなら、 stdlib.hやstddef.hについても調べます。

C Compiler Characteristics
==========================

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

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

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

 -- Macro: AC_C_INLINE
     Cコンパイラがinlineをサポートしていればなにもしません。 inlineがサポートされておらず、__inline__あるいは __inlineがサポートされていれば、 inlineを__inline__か__inlineに#defineします。どちらもサポートされていなければ空にします。

 -- Macro: AC_C_CHAR_UNSIGNED
     Cの型charが符号なし(unsigned)だったら、 __CHAR_UNSIGNED__を定義します。ただし、Cコンパイラが既に__CHAR_UNSIGNED__を定義していたらなにもしません。

 -- Macro: AC_C_LONG_DOUBLE
     Cコンパイラがlong double型をサポートしていたら、 HAVE_LONG_DOUBLEを定義します。世の中には _STDC__を定義していないのに long doubleをサポートしているCコンパイラや、 _STDC__を定義しているのに long doubleをサポートしていないCコンパイラがあります。

 -- Macro: AC_C_STRINGIZE
     もし、 C preprocessor が文字列化演算子(訳注 : stringizing operator (文字列連結演算子?、 C 言語で文字列という言葉も使って良いものか。))をサポートしている場合、HAVE_STRINGIZE を定義します。文字列化演算子 #とは、下記のようなマクロです。

          #define x(y) #y

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

     例えば、DEC Alpha AXPで

          AC_CHECK_SIZEOF(int *)

     とすると、SIZEOF_INT_Pは8になります。

 -- Macro: AC_INT_16_BITS
     Cの型intが16ビットの場合、INT_16_BITSを定義します。このマクロはobsoleteです。かわりにより汎用的なAC_CHECK_SIZEOF(int)を使ってください。

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

Fortran 77 Compiler Characteristics
===================================

以下のマクロはFortran 77コンパイラの特性を調べます。以下にない性質を調べたい場合、 AC_TRY_COMPILE (see Examining Syntax) か AC_TRY_RUN (see Run Time)を使ってください。テストの前に、AC_LANG_FORTRAN77 (see Language Choice)を使ってチェック対象コンパイラをFortran 77に切替えるのを忘れずに。

 -- Macro: AC_F77_LIBRARY_LDFLAGS
     Fortran 77のプログラムや共有ライブラリを正しくリンクするために必要な Fortran 77 intrinsic and run-time librariesを呼び出すためのリンカフラグを調べます(-Lや-lなど)。結果として出力変数FLIBSが設定されます。

     このマクロは複数言語のソースコード(例えばC++とFortran 77)をひとつのプログラムや共有ライブラリの中に混ぜないといけないときに使うものです (see Mixing Fortran 77 With C and C++ (GNU Automake))。

     たとえば、C++コンパイラとFortran 77コンパイラの出力を混ぜてリンクしないといけない場合には、リンク時にはC++コンパイラ/リンカを使わないといけません。なぜなら、リンク時にglobal constructorの呼び出し、templateの生成、例外サポートの有効化など、C++特有の処理が必要だからです。

     この場合でも(Fortran 77で生成されたバイナリのために) Fortran 77 intrinsic and run-time librariesをリンクしないといけませんが、 C++コンパイラ/リンカはFortran 77ライブラリをどうやって追加指定しなければいけないのかわかりません。このような場合にFortran 77ライブラリを調べるために AC_F77_LIBRARY_LDFLAGSが作られたのです。

System Services
===============

次のマクロは OS のサービスや機能を調べるためのものです。

 -- Macro: AC_CYGWIN
     Cygwin環境かどうか調べます。 Cygwin環境があれば、shell変数CYGWINをyesに設定します。 Cygwin環境がなければshell変数CYGWINを空にします (訳註: Cygwin環境はあったりなかったりするものなのでしょうか? それとも「Cygwin環境であれば」という方が適当? コメント求む)。

 -- Macro: AC_EXEEXT
     コンパイラの出力ファイルから.c、.o、.objファイルを除外して拡張子を調べ(意訳)、 substitute variable EXEEXTを定義します (訳註: substitute variableの訳語はなに?)。通常、Unixでは空文字列、Win32では.exeまたは.EXEになります。

 -- Macro: AC_OBJEXT
     コンパイラの出力ファイルから.cファイルを除外して拡張子を調べ(意訳)、 substitute variable OBJEXTを定義します。通常、Unixでは.o、Win32では.objになります。

 -- Macro: AC_MINGW32
     MingW32コンパイラ環境かどうか調べます。 MingW32環境があれば、shell変数MINGW32をyesに設定します。 MingW32環境がなければshell変数MINGW32を空にします (訳註: Cygwinに同じ)。

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

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

 -- Macro: AC_PATH_XTRA
     AC_PATH_Xの拡張版です。 X_CFLAGSにXが必要とするCコンパイラのフラグを、 X_LIBSにリンカのフラグを設定します。 Xがない場合にはX_CFLAGSに-DX_DISPLAY_MISSINGを追加します。

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

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

 -- Macro: AC_SYS_LONG_FILE_NAMES
     システムが14文字以上のファイル名をサポートしていたら、 HAVE_LONG_FILE_NAMESを定義します。

 -- Macro: AC_SYS_RESTARTABLE_SYSCALLS
     signalで割り込まれたシステムコールが自動で再開されるなら、 HAVE_RESTARTABLE_SYSCALLSを定義します。

UNIX Variants
=============

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

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

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

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

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

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

 -- Macro: AC_SCO_INTL
     OSがSCO UNIXだったら、-lintlをLIBSに追加します。このマクロはobsoleteです。かわりにAC_FUNC_STRFTIMEを使いましょう。

 -- Macro: AC_XENIX_DIR
     OSがXenixだったら、-lxを出力変数LIBSに追加します。また、dirent.hが使われていたら、-ldirを出力変数LIBSに追加します。このマクロはobsoleteです。 AC_HEADER_DIRENTを使いましょう。

Writing Tests
*************

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

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

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

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

Examining Declarations
======================

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

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

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

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

 -- Macro: AC_EGREP_HEADER (PATTERN, HEADER-FILE, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
     HEADER-FILEをCプリプロセッサに通した結果がPATTERNとマッチすれば、ACTION-IF-FOUNDを実行します。マッチしなければ、ACTION-IF-NOT-FOUNDを実行します。 PATTERNはegrepの正規表現です。

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

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

 -- Macro: AC_EGREP_CPP (PATTERN, PROGRAM, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     PROGRAMはCまたはC++のプログラムテキストです。 PROGRAMのところにはshell変数、 backquote、backslashによる置換が働きます。 PROGRAMをプリプロセッサに通した結果がPATTERNとマッチすれば、ACTION-IF-FOUNDを実行します。マッチしなければ、ACTION-IF-NOT-FOUNDを実行します。 PATTERNはegrepの正規表現です。

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

Examining Syntax
================

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

 -- Macro: AC_TRY_COMPILE (INCLUDES, FUNCTION-BODY, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     このマクロは、テスト用のC、C++またはFortran 77プログラムを書き出し、それがコンパイラでコンパイルできるかどうか調べます。

     CおよびC++の場合、INCLUDEに関数の中身(FUNCTION-BODY) で必要な#include文を指定します(Fortran 77が言語として選ばれていた場合、 INCLUDESは無視されます)。このマクロはコンパイルをするときに C言語を使っているならCFLAGS、C++ならCXXFLAGSと、 (どちらの場合にも共通な)CPPFLAGSの値を使います。 Fortran 77が現在選択されている言語なら、FFLAGSの値を使います。

     もしコンパイルできたなら、shellコマンドACTION-IF-FOUNDを実行します。もしできなかったらACTION-IF-NOT-FOUNDを実行します。

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

Examining Libraries
===================

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

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

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

 -- Macro: AC_TRY_LINK (INCLUDES, FUNCTION-BODY, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     このマクロは、選ばれている言語用のテストプログラムを書き出し、それがコンパイラでコンパイルでき、かつリンクできるかどうか調べます。

     CおよびC++の場合、INCLUDEに関数の中身(FUNCTION-BODY) で必要な#include文を指定します(Fortran 77が言語として選ばれていた場合、 INCLUDESは無視されます)。このマクロはコンパイルをするときに C言語を使っているならCFLAGS、C++ならCXXFLAGSと、 (どちらの場合にも共通な)CPPFLAGSの値を使います。 Fortran 77が現在選択されている言語なら、FFLAGSの値を使います。リンク時には、いずれの場合にもLDFLAGSとLIBSの両方を使います。

     もしコンパイルが成功したなら、shellコマンドACTION-IF-FOUNDを実行します。もしできなかったらACTION-IF-NOT-FOUNDを実行します。

 -- Macro: AC_TRY_LINK_FUNC (FUNCTION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     現在使用中の言語にあわせて(see Language Choice)、コンパイルやリンクのテストに使うプログラムを生成します。プログラムh FUNCTIONの関数プロトタイプと呼び出しからなります。

     もしファイルのコンパイルとリンクが成功すれば shellコマンドACTION-IF-FOUNDを実行します。失敗したらACTION-IF-NOT-FOUNDを実行します。

 -- Macro: AC_TRY_LINK_FUNC (FUNCTION, [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND]])
     Attempt to compile and link a small program that links with FUNCTION.  If the file compiles and links successfully, run shell commands ACTION-IF-FOUND, otherwise run ACTION-IF-NOT-FOUND. (訳註: これ多分削除忘れである)

 -- Macro: AC_COMPILE_CHECK (ECHO-TEXT, INCLUDES, FUNCTION-BODY, ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND])
     これはAC_TRY_LINKに類似した、obsoleteなマクロです。 AC_COMPILE_CHECKは、ECHO-TEXTが空でなければ、テストの前に checking for ECHO-TEXTと標準出力に表示します。テストの進行状況や結果を表示するには、 AC_MSG_CHECKINGとAC_MSG_RESULTを使いましょう (see Printing Messages)。

Checking Run Time Behavior
==========================

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

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

Running Test Programs
---------------------

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

 -- Macro: AC_TRY_RUN (PROGRAM, [ACTION-IF-TRUE [, ACTION-IF-FALSE [, ACTION-IF-CROSS-COMPILING]]])
     PROGRAMにはCプログラムコードを指定します。 PROGRAMに対してはshell変数やbackquoteによる置換が働きます。 PROGRAMのコンパイルとリンクが成功し、実行したときにexitステータス0が返ったら、 shellコマンドACTION-IF-TRUEを実行します。さもなくば、ACTION-IF-FALSEを実行します。このとき、プログラムのexitステータスはshell変数$?に入っています。このマクロは CFLAGS、CXXFLAGS、CPPFLAGS、LDFLAGS、それから LIBSを利用します。

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

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

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

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

 -- Macro: AC_C_CROSS
     このマクロはobsoleteです。何もしません。

Guidelines for Test Programs
----------------------------

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

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

     #if STDC_HEADERS
     # include <stdlib.h>
     #endif

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

Test Functions
--------------

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

     #ifdef __cplusplus
     foo(int i)
     #else
     foo(i) int i;
     #endif

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

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

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

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

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ではunsetすら使えません! スクリプトインタプリタを指定するための#!の後には、以下のようにスペースをつけてください:

     #! /usr/bin/perl

パス名の前のスペースがないと、 4.2BSD互換のシステム(Sequent DYNIXとか)では行は無視されます。 #! /を4バイトのmagic nubmerとして解釈しているためです。

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

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

Testing Values and Files
========================

configure スクリプトは、多くのファイルと文字列のテストの結果を必要とします。これらのテストを行なった際に注意すべきポータビリティのための問題をいくつかとりあげます。

test プログラムは、ファイルと文字列のテストを行う多くの方法を提供しています。このプログラムは、しばしば [ という別の名前で呼び出されます。しかし、この名前はm4 のクォート文字と同じなので、Autoconf のコードで使った場合には問題となります。

もし、test を使って複数のテストを行う必要がある場合、それらの結合には shell 演算子の && と || を用いて下さい。test の演算子、-a と -o を使ってはいけません。 System V では、 -a と -o の優先順位のため、単項演算子と間違うことがあります; POSIX ではこれについて規定していないため、ポータブルなコードになりません。同じ一文の中で && と || を用いる場合には、それらが等しい優先順位を持つように、注意して下さい。

configureスクリプトがクロスコンパイルをサポートするためには、ターゲットのシステムだけろテストするようにし、ホストシステムにてはどんな feature のテストもしないようにせねばなりません。しかし、しばしばある特定のファイルが存在するかどうかをチェックしてみる必要がある場面に直面することになるでしょう。その場合には、test -f かあるいは、 test -r を利用して下さい。test -x を使ってはいけません。というのも 4.3BSD にはそれが存在しないからです。

その他のポータブルでない shell プログラムの構文は、

     VAR=${VAR:-VALUE}

これは、まだある変数がセットされていない時に限って、VAR を VALUE にセットするというものですが、VAR がどんな値、たとえそれが空文字であっても、こうしてはいけません。Ultrix の sh を含む古い BSD の shell はこのコロンを受理せず、文句を言って死にます。このポータブルな書き方は、

     : ${VAR=VALUE}

です。

Multiple Cases
==============

いくつかの操作には、UNIX の方言に応じた、いくつかの達成方法があります。それらを調べるためには、基本的に ``case 文'' を使う必要があります。 Autoconf はcase文を提供していませんが、 Shell 変数を使って判別が完了したのかどうかを記録していけば case文の代わりになる検査を簡単に記述できます。

これは、shell 変数 fstype を使って、どの case が調べられたかを追いかける例です。

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

Language Choice
===============

パッケージは C と C++ の両方のコンパイラを使って feature をテストする必要があります。Autoconf が作成した configure スクリプトは、デフォルトで C を調べます。configure.in に書く次のマクロは、どちらの言語のコンパイラがテストで使われるかを決定します。

 -- Macro: AC_LANG_C
     拡張子 .c のついたテストプログラムを用いて、CC と CPP を使ったコンパイルテストを行います。AC_PROG_CC が動作すればその動作結果の値を、そうでない場合には shell 変数 cross_compilingを空にします。

 -- Macro: AC_LANG_CPLUSPLUS
     拡張子 .C のついたテストプログラムを用いて、CXX と CXXCPP を使ったコンパイルテストを行います。AC_PROG_CXX が動作すればその動作結果の値を、そうでない場合には空を shell 変数 cross_compiling にセットします。

 -- Macro: AC_LANG_FORTRAN77
     拡張子 .f のついたテストプログラムを用いて F77 を使ったコンパイルテストを行います。AC_PROG_F77 が既に動作していた場合には、 AC_PROG_F77 の計算結果の値を、そうでない場合には空を shell 変数 cross_compiling にセットします。

 -- Macro: AC_LANG_SAVE
     現在の言語(AC_LANG_C、AC_LANG_CPLUSPLUSまたは AC_LANG_FORTRAN77によってセットされているもの) をスタック上に覚えます。どの言語を現在のものとしているかは変化しません。このマクロと AC_LANG_RESTORE をマクロ中で使用することで、一時的にある特定の言語へと切り換えを行うことができます。

 -- Macro: AC_LANG_RESTORE
     スタックトップにセーブされている言語を選択します。それは AC_LANG_SAVE としてセットされており、このマクロで選択することでスタックから消えます。このマクロは、一番最近呼ばれたAC_LANG_SAVEの直前に呼ばれた言語指定マクロ(AC_LANG_C、AC_LANG_CPLUSPLUS、 AC_LANG_FORTRAN77)と等価です (訳註: さきほどまで使っていた言語を AC_LANG_SAVE してこの AC_LANG_RESTORE を呼べば元に戻る。 Yam)。

     このマクロは AC_LANG_SAVE の呼び出しよりも多くの回数呼んではいけません。

 -- Macro: AC_REQUIRE_CPP
     テストが行なわれた時に、どのプリプロセッサが利用されていたかを請け合います。現在の言語が C, C++ のどちらであるかにより、AC_PROG_CPP か AC_PROG_CXXCPP を引数にして、AC_REQUIRE (see Prerequisite Macros) を呼んで下さい。

Results of Tests
****************

ひとたび configure が何か feature の存在を検知した時、その情報はどのように記録すべきでしょうか? 記録の方法として、次の 4 つがあります : C のプリプロセッサのシンボルを定義する、出力ファイル中の変数をセットする、 configure が走る時に使う cache ファイル中に結果を保存する、そして、テストの結果をユーザに知らせるためにメッセージを出力する。

Defining C Preprocessor Symbols
===============================

通常は feature のテストの結果を C のプロプロセッサのシンボルとして定義します。これは、AC_DEFINE かあるいは AC_DEFINE_UNQUOTED を呼ぶことで実現されます。

デフォルトでは、AC_OUTPUT はこれらのマクロによって定義されたシンボルを変数 DEFS として出力します。この中身は、定義されたそれぞれのシンボルが -DSYMBOL=VALUE のようにオプションの形になったものです。Autoconf の version 1 とは違い、 configure が走っている間は、変数 DEFS の値はありません。 Autoconf マクロが既にある C プロプロセッサのシンボルとして定義されているかどうか調べるために、次の例のように、適宜キャッシュ変数の値を調べます。

     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

もし AC_CONFIG_HEADER が呼ばれた場合には、DEFS の値を作成せず、AC_OUTPUT がテンプレートファイル中の #define 文を正しい値で置き換えて、ヘッダファイルを作成します。この種の出力についてのより詳細な情報については、see Configuration Headers を参照のこと。

 -- Macro: AC_DEFINE (VARIABLE [, VALUE [, DESCRIPTION]])
     C のプリプロセッサ変数を VARIABLE に定義します。VALUE があればその文字列を VARIABLE に代入し、そうでなければ 1 をセットします。 VALUE は改行を含んではなりません。また、AC_CONFIG_HEADER を利用しない場合には、# を含んではいけません。これは make が # を処理してしまうためです。shell変数を使う場合には、代わりに AC_DEFINE_UNQUOTED を使って下さい (m4 の quote 文字である [ と ] を含む値を定義する場合に必要です)。 DESCRIPTION is only useful if you are using AC_CONFIG_HEADER.  In this case, DESCRIPTION is put into the generated config.h.in as the comment before the macro define; the macro need not be mentioned in acconfig.h. 次の例は、C のプリプロセッサ変数、EQUATION を 文字定数 "$a > $b" とするものです。

          AC_DEFINE(EQUATION, "$a > $b")

 -- Macro: AC_DEFINE_UNQUOTED (VARIABLE [, VALUE [, DESCRIPTION]])
     AC_DEFINE と似ていますが、3 つの shell 展開がVARIABLE と VALUE 上で--- 一度 ---行なわれます: その 3 つとは、値の展開 ($)、コマンド置き換え (`)、バックスラッシュのエスケープ (\) です。値の中にシングルクォートとダブルクォート文字があっても特別な意味は持ちません。VARIABLE あるいは VALUE が shell 変数の場合に、AC_DEFINE の代わりにこのマクロを使用して下さい。例えば以下のようになります。:

          AC_DEFINE_UNQUOTED(config_machfile, "${machfile}")
          AC_DEFINE_UNQUOTED(GETGROUPS_T, $ac_cv_type_getgroups)
          AC_DEFINE_UNQUOTED(${ac_tr_hdr})

Bourne shell の風変りなシンタックスのため、他のマクロの呼び出しから、あるいは shell のコードから、AC_DEFINE あるいは AC_DEFINE_UNQUOTED を呼び出す際、これらを分離するためにセミコロンを使ってはいけません。そうして作成された configure スクリプトではシンタックスエラーになります。スペースか改行を使って区切って下さい。つまり、

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

あるいは次のようにします:

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

以下の例は間違いです。

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

Setting Output Variables
========================

テストの結果を記録する一つの方法は、output variables をセットすることでした。これは shell 変数であり、その値は configure が出力するファイルの内容を置き換えます。次の 2 つのマクロが新たな output variables を作成します。See Preset Output Variables には、常に出力可能な output variables のリストがあります。

 -- Macro: AC_SUBST (VARIABLE)
     shell 変数から、output variable を生成します。AC_OUTPUT が出力ファイル(通常1つかそれ以上の Makefile 中の変数 VARIABLE を置き換えます。これは、AC_OUTPUT が、AC_OUTPUT の呼ばれた時に、入力ファイル中にある @VARIABLE@ を、shell 変数 VARIABLE の値で置き換えることを意味します。VARIABLE の値は、リテラルとしての改行を含んではいけません。

 -- Macro: AC_SUBST_FILE (VARIABLE)
     shell 変数から output variable を作成する他の方法があります。 AC_OUTPUT は shell 変数 VARIABLE が持つファイルを出力ファイルに挿入する(置き換えなし)ことができます。これは AC_OUTPUT は、それが呼ばれた時に、出力ファイル (例えば Makefile.in) 中の @VARIABLE@ のインスタンスを、shell 変数 VARIABLE が持つファイル名のファイルの内容で置き換えることができることを意味します。ファイルを挿入したくない場合には、/dev/null をセットして下さい。

     このマクロは、Makefile に、特殊な依存関係を処理するために分割してある makefile や、あるいは、特別なホストやターゲットのタイプによって他の make のディレクティブを Makefile に挿入する際に有益です。たとえば、configure.in は次のコードを含むこともできます:

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

     そして Makefile.in にはこのように書いておきます。

          @host_frag@

Caching Results
===============

いくつかの configure スクリプト(あるいは一つのスクリプト中だけでも)で繰り返し同じ feature を調べなくても良いように、configure は cache file 中にチェックの結果の多くを保存します。configure を走らせた時に、cache file がみつかったらなら。そのスクリプトは結果を読み込み、同じチェックを繰り返さないようにします。そのため、 configure は一度走らせれば、毎回全てのチェックをやり直すよりもずっと高速に動作します。

 -- Macro: AC_CACHE_VAL (CACHE-ID, COMMANDS-TO-SET-IT)
     CACHE-ID の名前を持つチェック結果が利用可能になります。チェックの結果が、cache file 中に読み込める形で存在し。configure が --quiet あるいは --silent を引数にとっていなかった場合には、結果がキャッシュされていたことをメッセージとして報告します; そうでない場合には、shell コマンド COMMANDS-TO-SET-IT が実行されます。これらのコマンドは CACHE-ID の値をセットするのみとすべきで、他の副作用を持つべきではありません。特に、AC_DEFINE を呼び出してはいけません; AC_CACHE_VAL の呼び出し後のコードはキャッシュの値を基に動作すべきです。また、値をセットするコード中では AC_MSG_CHECKING のようなメッセージを出力するべきではありません; それは、チェックの結果がキャッシュから読み込まれるか、あるいは、shell コマンドの実行によって決定されるかにかかわらず、必ずメッセージを出力するべきだからです。したがって、メッセージを出力するのであれば AC_CACHE_VAL を呼ぶ前に出力すべきです。もし、 shell コマンドが値を決めるために実行されるのであれば、その値は、 configure がその出力ファイルを生成する直前にキャッシュに保存されるでしょう。See Cache Variable Names には CACHE-ID の変数の名前をどのように選ぶべば良いかについて書いてあります。

 -- Macro: AC_CACHE_CHECK (MESSAGE, CACHE-ID, COMMANDS)
     これは、AC_CACHE_VAL に対するラッパで、メッセージの出力を考慮します。このマクロを使って書くのが、普通一番簡単に書ける方法です。このマクロは、MESSAGE に対して AC_MSG_CHECKING を呼び出し、その後に CACHE-ID と COMMANDS を引数にして AC_CACHE_VAL を呼び出します。そして最後に CACHE-ID を引数にしてAC_MSG_RESULT を呼びます。

 -- Macro: AC_CACHE_LOAD
     現在存在するキャッシュファイルから値を読み込みます。あるいは、もしキャッシュファイルが存在しない場合には新しいキャッシュファイルを作成します。これはAC_INITから自動的に呼ばれます。

 -- Macro: AC_CACHE_SAVE
     キャッシュされた値を全てキャッシュファイルに書き込みます。これは AC_OUTPUT から自動的に呼ばれます。しかし、AC_CACHE_SAVE を configure.in 中の鍵となる地点で呼びことはなかな利用できます。configure のスクリプトが早い段階で異常終了するような場合にこれをチェックポイントとして使えます。

Cache Variable Names
--------------------

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

     PACKAGE-PREFIX_cv_VALUE-TYPE_SPECIFIC-VALUE[_ADDITIONAL-OPTIONS]

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

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

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

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

SPECIFIC-VALUE
     テストが適用されるキャッシュのクラスのメンバです。たとえば、どの関数か (alloca), どのプログラムか (gcc), output variable はどれか (INSTALL) を示します。

ADDITIONAL-OPTIONS
     テストが適用される特定のメンバの任意のなんらかのふるまいです。たとえば、 broken や set です。もしこれらが適用されない場合には、名前のこの部分は省かれるでしょう。

cache 変数として割り当てられる変数は改行を含んではいけません。通常、それらの値は boolean (yes または no) となるか、ファイルや関数の名前になるでしょう。そのため、この制限はきついものではありません。

Cache Files
-----------

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

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

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

     define([AC_CACHE_LOAD], )dnl
     define([AC_CACHE_SAVE], )dnl
     AC_INIT(whatever)
      ... rest of configure.in ...

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

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

もしあなたの configure スクリプト、あるいは configure.in から呼ばれるマクロが configure のプロセスを異常終了させることがある場合、これを利用してキーとなる地点でキャッシュに何度かチェックポイントを設定することは有益でしょう。そうすることで、前回の異常終了の原因となったエラーが(願わくば) 正しく修正された、configure スクリプトを再び最初から起動しなおすためにかかる時間のほとんどを節約できます。

      ... AC_INIT, etc. ...
     dnl checks for programs
     AC_PROG_CC
     AC_PROG_GCC_TRADITIONAL
      ... more program checks ...
     AC_CACHE_SAVE

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

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

Printing Messages
=================

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

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

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

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

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

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

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

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

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

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

 -- Macro: AC_CHECKING (FEATURE-DESCRIPTION)
     このマクロはAC_MSG_CHECKINGと似ていますが、AC_CHECKINGは FEATURE-DESCRIPTIONのあとに改行を出力します。このマクロは主に、複数並んだOS機能チェックの全体としての目的を出力するのに使えます。たとえば:

          AC_CHECKING(if stack overflow is detectable)

 -- Macro: AC_VERBOSE (RESULT-DESCRIPTION)
     このマクロはAC_MSG_RESULTと似ています。ただし、AC_VERBOSEはAC_MSG_CHECKINGではなく、 AC_CHECKINGに続いて呼び出される、という点だけが違います。メッセージはtabに続いて出力されます。このマクロはobsoleteです。

Writing Macros
**************

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

Macro Definitions
=================

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

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

     AC_DEFUN(MACRO-NAME, [MACRO-BODY])

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

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

See How to define new macros (GNU m4), for more complete information on writing m4 macros.

Macro Names
===========

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

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

AC_の次にある単語は、調べる対象のOS機能のカテゴリを示しています。ここでは、特定のテストのマクロや、あなたが書こうと思うようなマクロのために Autoconf が使用するカテゴリを示します。また、cache 変数も、全て小文字でこの名前を利用します。この名前の規則が適用可能だと思ったらどこでもこれらを使って下さい。もし適用できないようであれば、自分自身のカテゴリを発明することです。

C
     C 言語に組み込みの features。

DECL
     ヘッダファイル中にある C の変数の宣言。

FUNC
     ライブラリ中の関数。

GROUP
     UNIX のファイルでのグループオーナー。

HEADER
     ヘッダファイル。

LIB
     C ライブラリ。

PATH
     ファイルの、プログラムを含むフルパス。

PROG
     プログラムのベース名。

STRUCT
     ヘッダファイル中の C 構造体の宣言。

SYS
     オペレーティングシステムのfeature。

TYPE
     C の組み込みあるいは。宣言された型。

VAR
     ライブラリ中の C 変数。

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

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

Quoting
=======

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

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

     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)

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

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

Dependencies Between Macros
===========================

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

Prerequisite Macros
-------------------

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

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

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

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

 -- Macro: AC_PROVIDE (THIS-MACRO-NAME)
     マクロTHIS-MACRO-NAMEが呼び出されたことを記録します。THIS-MACRO-NAMEはAC_PROVIDE マクロを呼び出すマクロの名前でなければなりません m4の組み込み変数$0を使うと簡単にマクロの名前を得る事ができます。たとえばこんな風:

          AC_PROVIDE([$0])

Suggested Ordering
------------------

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

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

     AC_BEFORE([$0], [AC_PROG_CPP])dnl

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

 -- Macro: AC_BEFORE (THIS-MACRO-NAME, CALLED-MACRO-NAME)
     マクロCALLED-MACRO-NAMEが既に呼び出されていた場合、m4が標準エラー出力に警告メッセージを出力するようにします。THIS-MACRO-NAMEはマクロAC_BEFOREを呼び出すマクロの名前である必要があります。CALLED-MACRO-NAMEに指定されるマクロはAC_DEFUNで前もって定義されているか、AC_PROVIDEの呼び出しを含んでいるかする必要があります。これは CALLED-MACRO-NAMEが呼び出されたことを検出するため必要です。

Obsolete Macros
---------------

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

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

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

Manual Configuration
********************

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

Specifying the System Type
==========================

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

     CPU-COMPANY-SYSTEM

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

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

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

--host=HOST-TYPE
     パッケージが実行されるシステムタイプ名;

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

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

     CC=m68k-coff-gcc configure --target=m68k-coff

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

Getting the Canonical System Type
=================================

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

 -- Macro: AC_CANONICAL_SYSTEM
     システムタイプを判定し、正規化されたシステムタイプ名を出力変数に設定します。設定される変数については see System Type Variablesを参照。

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

 -- Macro: AC_VALIDATE_CACHED_SYSTEM_TUPLE (CMD)
     もしキャッシュファイルの内容が現在のホスト、ターゲット、ビルドするシステムの型と一貫性を持たないのであれば、CMD を実行するか、デフォルトのエラーメッセージをい出力します。

System Type Variables
=====================

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

build, host, target
     正規化されたシステム名;

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

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

Using the System Type
=====================

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

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

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

     例えば、以下を使うと:

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

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

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

Site Configuration
******************

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

Working With External Software
==============================

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

     --with-PACKAGE[=ARG]
     --without-PACKAGE

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

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

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

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

 -- Macro: AC_ARG_WITH (PACKAGE, HELP-STRING [, ACTION-IF-GIVEN [, ACTION-IF-NOT-GIVEN]])
     configureスクリプトにユーザが --with-PACKAGEや --without-PACKAGEのようなコマンドラインオプションを与えた場合、 shellコマンドACTION-IF-GIVENを実行します。もしどちらも与えられなかった場合、 ACTION-IF-NOT-GIVENを実行します。 PACKAGEは外部ソフトウェアパッケージの名前を示します。 PACKAGEは英数字とマイナス記号だけでできている必要があります。

     コマンドラインオプションの引数は、 shellコマンドACTION-IF-GIVENの中から shell変数withvalとして参照できます。 withvalの値はshell変数with_PACKAGE (パッケージ名中の-は_に変換されます)の値とおなじですので、どちらを使っても構いません。

     HELP-STRINGはオプションの概説です。例えば以下のようにします:

            --with-readline         support fancy command line editing

     HELP-STRINGは必要なら2行以上にわたっても構いません。 configure --helpを実行したとき、桁が揃うようにしてください。 HELP-STRING中にはtab文字は使わないでください。行の先頭にスペースを含めるためには、[と]でくくる必要があるでしょう。

 -- Macro: AC_WITH (PACKAGE, ACTION-IF-GIVEN [, ACTION-IF-NOT-GIVEN])
     これは、AC_ARG_WITHの古いバージョンです。 HELP-STRINGが使えません。

Choosing Package Options
========================

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

     --enable-FEATURE[=ARG]
     --disable-FEATURE

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

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

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

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

 -- Macro: AC_ARG_ENABLE (FEATURE, HELP-STRING [, ACTION-IF-GIVEN [, ACTION-IF-NOT-GIVEN]])
     ユーザがconfigureの引数に --enable-FEATUREまたは--disable-FEATUREのオプションを指定した場合、 shellコマンドACTION-IF-GIVENを実行します。どちらも指定されていなければACTION-IF-NOT-GIVENを実行します。 FEATUREはパッケージの機能名です。 FEATUREは英数字とハイフンの組み合わせでないといけません。

     ACTION-IF-GIVENの中では、オプションに=に続き引数が指定されていたら、 shell変数enablevalに値が格納されています。実際には、enablevalとenable_FEATUREと同じ値になっています (enable_FEATUREのFEATURE部分は、もとのFEATUREのハイフンを下線(_)にしたもの)。必要ならどちらを参照しても構いません。 HELP-STRINGはAC_ARG_WITH(see External Software)で使われる HELP-STRINGと同じです。

 -- Macro: AC_ENABLE (FEATURE, ACTION-IF-GIVEN [, ACTION-IF-NOT-GIVEN])
     このマクロはobsoleteです。 AC_ARG_ENABLEからHELP-STRINGのサポートを外したようなものです。

Configuring Site Details
========================

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

このようなサイト依存の設定情報は、プログラムが編集したものではなく、ユーザだけによって編集されたファイルに格納されている必要があります。ファイルを置く位置はprefix変数をもとにしたパス、またはユーザのホームディレクトリなどの標準的な場所にします。ファイルを置く位置を環境変数で設定してもよいでしょう。プログラムはコンパイル時でなく実行時に、そのファイルを調べます。

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

Transforming Program Names When Installing
==========================================

Autoconf にはインストール時にプログラムの名前を変更することについてのサポートがあります。これらの変更機能を利用するには、configure.in からマクロ AC_ARG_PROGRAM を呼び出さねばなりません。

 -- Macro: AC_ARG_PROGRAM
     output variable の program_transform_name は、インストールされるプログラムの名前を変更するための sed のコマンド列を保持します。

     この後述べられるオプションのいずれかが configure に渡された場合、それに従ってプログラムの名前が変更されます。そうでない場合、もし AC_CANONICAL_SYSTEM が呼ばれ、--target 値が host type と違う場合(--host で指定されるかあるいは、config.sub によってデフォルトが指定されている場合)にはダッシュに続けて target type が prefix として利用されます(訳注: 原文は the target type followed by a dash is used as a prefix、おそらく name-target_type という名前になるという意味でしょう)。そうでない場合には、プログラム名の変更はありません。

Transformation Options
----------------------

名前の変更を指示するために、configure に次のコマンドラインオプションを指定することができます。

--program-prefix=PREFIX
     名前の前に PREFIX を付加します;

--program-suffix=SUFFIX
     名前の後に SUFFIX を付加します;

--program-transform-name=EXPRESSION
     名前に対して sed の置換式(EXPRESSION)を作用させます。

Transformation Examples
-----------------------

これらの変換はクロスコンパイルの開発環境におけるプログラムに対して使うと効果的です。たとえば、--target=i960-vxworks で設定された Sun 4 上で走るクロスアセンブラは、通常、Sun 4 のアセンブラと間違えられないように as ではなく、i960-vxworks-as という名前でインストールされます。

GNU プログラムがインストールされた場合に、あなたのシステムの同名のプログラムを隠さないように、プログラムの名前が g で始まるように指定することもできます。たとえば、GNU の diff に対し、 --program-prefix=g を指定して configure を実行すれば、プログラムは、make install を行なった時に /usr/local/bin/gdiff という名前でインストールされます。

もっと洗練された例として、次のように指定します。

     --program-transform-name='s/^/g/; s/^gg/g/; s/^gless/less/'

すると、ソースツリーのほとんどのプログラム名の先頭に g が付きます。ただし、gdb のように最初から g がついているものや、 less と lesskey のように、GNU のプログラムでないものは除外されます(ここでは、この feature を使ってセットアップするためにこれらのプログラムがソースツリーに含まれていると仮定します)。

同時に複数のバージョンの同じプログラムをインストールするための方法として、名前の片方か両方共にバージョン番号を付加することが考えられます。たとえば、 Autoconf のバージョン 1 をしばらくは利用したいとします。この場合、 Autoconf のバージョン 2 の configure 実行時に --program-suffix=2 のオプションを付加して設定し、/usr/local/bin/autoconf2, /usr/local/bin/autoheader2, などのようにインストールすることができます。

Transformation Rules
--------------------

ここでは Makefile.in 中で program_transform_name 変数を使う方法を述べます。

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

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

もし、二つ以上のプログラムをインストールしたい場合には、ここで次に示すよう loop を書くことができます。

     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

文書ファイル(Texinfo や man) の変換を行なうかどうかということはトリッキーな問題です; 名前の変換についてはいくつかの理由があって完璧な答えはなさそうです。文書は通常、特定のアーキテクチャに依存するものではありませんし、Texinfo ファイルはシステムの文書と競合することもありません。しかし、同じファイル名の前のバージョンのものと競合することはあるでしょう。そして、man ページは時々、システムの文書と競合を起こします。妥協案として、Texinfo マニュアルはそのままにしておき、man ページの名前は変更することが良いでしょう。

Setting Site Defaults
=====================

Autoconf が生成した configure スクリプトは、あなたのサイトにおける、いくつかの設定値に対するデフォルトの値を提供します。このためには、 site- と system-wide な初期化ファイルを用意して下さい。

もし、環境変数 CONFIG_SITE がセットされているのならば、 configure は、その値を読み込む shell スクリプトの名前として利用します。そうでない場合には、まず、PREFIX/share/config.site が存在するかを見て、あれば shell スクリプトを読み込み、次に PREFIX/etc/config.site があるかどうかを見てあれば読みます。つまり、共有のファイルで指定したことは機械毎のファイルでの指定で上書きされます。

サイトファイルはどんな shell スクリプトでもかまいません。しかし、実際にはある種のコードだけがそこに含まれていることになるでしょう。 configure はまず任意のサイトファイルを読み込んだ後に任意のキャッシュファイルを読むため、サイトファイルは、そのシステム上で動作する Autoconf が生成した全ての configure スクリプト間で共有されるデフォルトのキャッシュファイルを定義可能です。もし、デフォルトのキャッシュファイルをサイトファイル中でセットした場合、そのサイトファイル中で output variable CC もセットするのは良い考えです。というのは、キャッシュファイルはある特定のコンパイラのみにとって有効なものであり、多くのシステムはいくつかのコンパイラを持っていることがあるからです。

configure のコマンドラインオプションによりセットされた値を、サイトファイル中で調べたり上書きすることが可能です; 各オプションは、オプション名と同じ名前のshell変数を設定します (ただし、名前中のダッシュは下線に変更されます)。 --without- と --disable- の両オプションはこれにあてはまりません。これらは、対応する --with- あるいは --enable- にnoを指定するのと等価です。まとめて例を挙げると: --cache-file=localcache は、 cache_file という変数に、localcache という値をセットします; --enable-warnings=no あるいは --disable-warnings は、 enable_warnings に値 no をセットします; --prefix=/usr は変数 prefix に値 /usr をセットします; などなど。

サイトファイルはその他の(configureのコマンドラインオプション以外の)出力変数のデフォルト値を設定するのにも利用できます。 CFLAGS のような変数に、通常のデフォルトとは違う値を毎度毎度与えるかわりに、サイトファイルを利用できます。なります。もし、通常のデフォルトではない値を PREFIX や EXEC_PREFIX として利用したい場合(サイトファイルがどこに置かれても)、環境変数 CONFIG_SITE を指定さえすれば、サイトファイル中でセットできます。

いくつかのキャッシュ値もまたサイトファイルそのものでセットできます。これはテストプログラムを動作させないとチェックできない feature があるが、それが不可能なクロスコンパイル環境で有益です。

システムに対して PREFIX/etc/config.site 中でこれらの値を正しくセットすることによって、``あらかじめキャッシュ''を用意することができます。セットする必要のあるキャッシュ値の名前をみつけるために、関係のある configure スクリプトや、これらのマクロに対する Autoconf の m4 のソースコード中から、名前に _cv_ のついている shell 変数を探して下さい。

キャッシュファイルでは、サイトファイル中でセットされる変数を上書きしないように注意しなくてはいけません。同様に、サイトファイル中ではコマンドラインのオプションを上書きすべきではありません。あなたがコードを書く場合には、 prefix や cache_file のような変数を変更する前には、それらが(configure の最初の方でセットされているような)デフォルトの値を持つかどうかチェックすべきです。

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

     # 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

Running configure Scripts
*************************

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

     [file install.texi not included]

Recreating a Configuration
**************************

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

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

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

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

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

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

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

 -- Variable: CONFIG_FILES
     @VARIABLE@の置換を行うべきファイル名。デフォルトはconfigure.inでAC_OUTPUTに与えられた引数です。

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

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

     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

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

Questions About Autoconf
************************

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

Distributing configure Scripts
==============================

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

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

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

Why Require GNU m4?
===================

     なんでAutoconfはGNU m4を必要とするんですか?

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

     builtin
     indir
     patsubst
     __file__
     __line__

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

How Can I Bootstrap?
====================

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

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

Why Not Imake?
==============

     なんでconfigureスクリプトでなしにImakeを使わないのですか?

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

以下の答えは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をcppの#includeとマクロ機構を使って簡単に生成できる、ということがあります。しかし、cppはプログラマブルではありません。 cppでは限られた条件文しか書けませんし、ループは記述できません。 cppでは実行環境を調べることもできません。

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

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

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

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

最後にMark Eichinが言うには:

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

逆の見方をすると:

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

Upgrading From Version 1
************************

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

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

Changed File Names
==================

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

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

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

Changed Makefiles
=================

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

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

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

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

     prefix = /usr/local
     exec_prefix = ${prefix}

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

     prefix = @prefix@
     exec_prefix = @exec_prefix@

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

Changed Macros
==============

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

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

Using autoupdate to Modernize configure
=======================================

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

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

autoupdateは以下のオプションを受け付けます:

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

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

--version
     autoupdateのバージョン番号を表示して終了します。

Changed Results
===============

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

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

     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

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

     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

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

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

Changed Macro Writing
=====================

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

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

ドキュメントに書かれていないAutoconfの内部構造(マクロ、変数や実装上の抜け道)を使ってトリッキーなことをしている場合、バージョンの違いによる変化に影響されていないかをチェックしてください。もしかしたら、ずるをしないでもバージョン2で用意されているやりかたで同じ事ができるかもしれません。できないかもしれませんけど。

自分で記述したテストを高速にするために、キャッシュを使いましょう。あなたの記述したテストが、汎用的なマクロとして一般化できるかどうか考えましょう。

History of Autoconf
*******************

おそらくあなたは、なぜ Autoconf が書かれたのかということに興味があるでしょう。いかにしてそれが現在の形となったのか? (どうしてそれがゴリラのツバのようにばっちいのか?) そう思わないのでしたら、この章は無意味なので飛ばした方が良いでしょう。もし、興味があるならば、見ていくことにしましょう...

Genesis
=======

1991 年の 7 月、私は Free Software Foundation のための GNU のユーティリティの多くをメンテナンスしていた。多くのプラットフォームをサポートするに従い、また、プログラムの数が増加するに従って、Makefile 中で選択せねばならない -D オプションの数が増加し(約 20)、耐えがたい負担となっていた。特に私は異なるシステムが新しくリリースされるごとにテストせねばならなかった。そこで、私は fileutils パッケージのために正しい設定を行うための小さなスクリプトを書き、fileutils 2.0 の一部としてそれをリリースした。その configure スクリプトは十分上手く働き、私はその次の月に他のいくつかの GNU ユーティリティパッケージのため、同様の configure を (手動で)作成した。Brian Berliner も私のスクリプトの一つを彼の CVS revision control system に適用した。

その夏も終わる頃、Richard Stallman と Richard Pixley がGNU コンパイラツールで同じようなスクリプトを作っていることを聞いた。そこで私は私の configure スクリプトを彼らの進化していくインターフェースをサポートするために適用した: テンプレートとして、Makefile.in という名前を使い; +srcdir と (多くの) 最初となったオプションを加え、 config.status ファイルを生成した。

Exodus
======

ユーザからのフィードバックをもらうに従い、私は多くの改良を加えた。しかしそれは、Emacs のサーチと置換、カットとペーストを使い、それぞれのスクリプトに同様の変更を適用するというものだった。私が configure スクリプトを多くの GNU ユーティリティに適用していくにつれて、それらを手動で更新していくことが不可能になった。

GNU graphics ユーティリティのメインテナである Rich Murphey は configure スクリプトはすばらしいとメイルを私に送ってきた。そしてそれらを生成するプログラムを送ってくれないかと尋ねてきた。それはできない。しかし、そのようになるべきだ！と私は思った。そこで私はそれらをどうやったら生成できるかということを考えはじめた。手書きの configure スクリプトの奴隷から解放され、豊かで簡単な Autoconf の世界の幕開けである。

Cygnus の configure がそのころ構築されていたが、それはテーブル駆動のものであった、それは、主に離散的なシステムタイプを示す数字に、ほとんど想像すらできない feature (たとえば、オブジェクトファイルのフォーマットの詳細など)を示す小さな数字を扱うことを意味していた。Bash のために Brian Fox が作成した自動設定システムは同様のアプローチをとっていた。

各オペレーティングシステムの持っているそれぞれの異なる feature を保持するデータベースを作成し、それを更新するという方法は、一般的に利用するためにはほとんど望みがないと思われた。もっと簡単で、より合理的な方法は、ほとんどの feature をその場で調べるということである。特に人々がローカルにハックしているようなハイブリッドなシステムや、ベンダがインストールしたものにパッチを当てているような場合にはこのようなデータベースのアプローチは無理だろう。

私は Cygnus の configure に似たアーキテクチャを使うことを考えた。それは、単一の configureスクリプトが動作時に configure.in の多数のかけらを読み込むものだった。しかし私は全てのパッケージにおける feature テストの全てを配布するのは御免だった。そこで私はプリプロセッサによってそれぞれの configure.in から作成される環境によって毎回異なる一つの configure を生成するようにした。このアプローチはより制御しやすく、自由度も高かった。

私はしばらく Larry Wall, Harlan Stenn, Raphael Manfredi らの Metaconfig パッケージを使ってみた。しかし、いくつかの理由でそれらを使わないことにした。Configure はそれを対話的に生成するのだが、私にはそれは不便に思えた。いくつかの features (ライブラリ関数など) をそのように調べるというのは好ましくないと思った。しかも私はそれがまだメンテナンスを必要としたことを知らなかった。そのため、Configure スクリプトは多くの新しいシステム(System V R4 や NeXT のようなシステム) では動作しないことを目のあたりにすることになる。それではまた、feature の存在についての反応が柔軟とは思えなかった。まや、このプログラムを使いこなすことが難しいこともわかった。その上、それは私の要求に対して大きく、複雑すぎるのだ(私は Autoconf が期せずして現在のように成長するとは認識していなかった)。

私は、Perl を使って私流の configure を生成することを考えたが、単純なテキスト置換の仕事には m4 の方が向いていると考えた。出力が暗黙のもののため、そのことはほとんど邪魔にはならなかった。その上、既に皆は m4 を持っていた(最初、私は GNU の拡張した m4 に依存していなかった)。 また、Maryland 大学の私の友人の幾人かは、tvtwm を含むいくつかのプログラムのフロントエンドとして m4 を使っていた。そのため私には新しい言語に挑戦するという楽しみもあった。

Leviticus
=========

私の configure スクリプトは、ユーザの介在なしにシステムの能力を自動的に決定するものであったので、私はこのプログラムを Autoconfig と呼んでいた。しかし、バージョン番号を上がっていくと、この名前は古い UNIX のファイルシステムにとっては長くなりすぎたので、短い名前にして Autoconf とした。 1991 年の秋に、ポータビリティの Holy Grail の後に、私と探索者の仲間達(まあ、つまり alpha テスタ達のこと)が私が手で書いたスクリプトのかけらを m4 マクロ中にカプセル化したり、feature を加えたり、チェックの利用を改良するというようなフィードバックを行なってくれた。そのテスタたちの中でも突出していたのが Franc,ois Pinard である。彼は m4 を走らせ、autoconf shell スクリプトを作成し、未解決のマクロの呼び出しを調べるという考えを持っていた。 Richard Pixley はより正確な結果を得るため、ファイルとシンボルをファイルシステム上で探すかわりにコンパイラを動かすことを提案した。Karl Berry は、 TeX を設定するための Autoconf を得て、ドキュメントにマクロインデックスを追加した。Ian Taylor は彼の UUCP パッケージを Autoconf で利用するため、Makefile 中の -D オプションを置くかわりに C のヘッダファイルを生成するというサポートを加えた。alpha テスター達は Autoconf マクロの名前や呼び出し規約がリリースごとに変化したが、彼らのファイルを快く書き直してくれた。彼ら全ては、多くのチェックやすばらしいアイデア、そしてバグの修正への貢献者である。

Numbers
=======

1992 年の 7 月、alpha テストの一ヶ月のあと、私は Autoconf 1.0 をリリースし、多くの GNU パッケージをそれが使えるように変換を行なった。驚いたのは積極的な反応がとても多かったということである。ほとんどの人々は私が進行状況を見るまでもなく Autoconf を利用しはじめたことである。特に GNU Project ではないソフトウェアの製作者 (TCL, FSP, Kerberos V5 など) 達が利用しはじめた。彼らはconfigure スクリプトを作成した時に出会った問題を報告してくれ、Autoconf には急速に改良が加えられていった。

Autoconf は m4 の実装に対する良い試練となった。UNIX m4 は、 Autoconf の定義するマクロの長さに耐えきれず core dump するようになり、 GNU m4 にひそんでいたいくつかのバグも発見された。時に、我々は GNU m4 にだけ存在するいくつかの feature を利用する必要を感じるようになった。特に 4.3BSD m4 では、組み込みマクロの貧弱さがめだった。 System V のバージョンはより良いものであったが、我々が必要としていた全てを提供していたわけではなかった。

人々が Autoconf に(私が予測しなかったような)能力を追加して、開発は更に進んだ。Karl Berry は X11 の機能を、david zuhn は C++ のサポートに貢献した。 Franc,ois Pinard は、無効な引数を診断できるようにした。Jim Blandy は勇敢にも GNU Emacs に対して Autoconf を利用し、その後のいくつかの改良の基礎を築いた。 Roland McGrath は Autoconf を GNU C Library に適用し、C のヘッダファイルのテンプレートを自動的に生成するための autoheader を書き、そして、 configure に --verbose オプションを加えた。Noah Friedman は --macrodir オプションと AC_MACRODIR 環境変数を加えた (彼はまた autoconfiscate という言葉を生み出し、``ソフトウェアのパッケージをAutoconf 対応にする''の意味で使用した)。 Roland と Noah は AC_DEFINE 中のクォートの保護を改良し、また、多くのバグを直した。特に 1993 年の 2 月から 6 月にかけて私が病気の間にポータビリティの問題を扱ってくれた。

Deuteronomy
===========

長い、主な feature に関する今後改良して欲しいリストが蓄積され、様々な人々がそれらの作業に対してパッチを作成するという数年間の努力があった。1994 年の 4 月に、Cygnus のサポートとして働く一方で私は、Autoconf のメジャーバージョンを変更する作業を始めた。私は、david zuhn と Ken Raeburn の助けを借りて、Autoconf に欠けている Cygnus の configure の持つ feature のほとんどを追加し、 Cygnus configure に関係した部分を大幅に欠き直していった。これらの feature には config.sub, config.guess, --host, --target といったものを使うためのサポート、ファイルのリンクを行う機能、サブディレクトリで configure スクリプトを実行することへのサポートを含んでいた。これらの feature によって Ken は GNU as で、Rob Savoye は DejaGNU で Autoconf を利用することが可能になった。

私は他の人々の提案に答えて、より多くの feature を加えた。多くの人々は、 configure スクリプトが動作の間に調べた結果を共有することを提案してきた。なぜなら、(特に Cygnus のような巨大なソースツリーを持つもので configure を走らせる場合) それらはとてつもなく遅かったからだ。Mike Haertel はサイト依存の初期化スクリプトを加えることを提案した。MS-DOS 上でソフトウェアを配布している人々は .in という拡張子を持つファイル名を書き換える方法を提案した。というのは、config.h.in のような 2 つのドットを持つようなファイル名が生成できないからだ。Jim Avera は AC_DEFINE と AC_SUBST 中のクォートの問題の大規模な試験を行なった: 彼の洞察力はすばらしく、重要な改良がなされた。Richard Stallman はコンパイラの出力が /dev/null ではなく、config.log に送られるように提案した。これは Emacs の configure スクリプトをデバッグする人々を助けるためである。

私はプログラムの質に対する私の不満を解消するために他にも変更を加えた。あいまいさを除くようなチェックの結果を示すメッセージを生成し、常に結果を出力するようにした。マクロの名前を正規化し、矛盾したコーディングスタイルを整理した。ソースコードのパッケージを Autoconf を使うことで容易に変換できるよう、いくつかの補助的なユーティリティを加えた。これには、 Franc,ois Pinard の助けを借り、互いに他のメッセージを中断しないようなマクロを作成した(その feature は GNU m4 におけるある性能上のボトルネックをあらわにしました。彼はただちにそのボトルネックを修正した！)。 私はドキュメント周りの問題で人々が望んでいるものを再構成した。そしてまずテストスイートを作成しはじめた。これはこれまでの経験から Autoconf は我々が変更しようとすると後戻りする傾向があると指摘されるためである。

重ねて申し上げるが、幾人かの alpha テスタからははかり知れない価値を持つフィードバックを頂いた。特に Franc,ois Pinard, Jim Meyering, Karl Berry, Rob Savoye, Ken Raeburn, Mark Eichin に感謝する。

既に、version 2.0 の準備はできています。これは非常な喜びです(そして私にはまた自由な時間ができました。多分……。そうです。確かに)。

Old Macro Names
***************

Autoconfのバージョン2では、多くのマクロが統一的でわかりやすい命名規則に従うよう改名されました。

以下は、改名されたマクロの古い名前と現在の名前のリストです。バックワードコンパチビリティのためにautoconfは古い名前を受け付けますが、古い名前はobsoleteです。新しい命名規則についてはsee Macro Names参照。

AC_ALLOCA
     AC_FUNC_ALLOCA

AC_ARG_ARRAY
     あまり役立たないので削除

AC_CHAR_UNSIGNED
     AC_C_CHAR_UNSIGNED

AC_CONST
     AC_C_CONST

AC_CROSS_CHECK
     AC_C_CROSS

AC_ERROR
     AC_MSG_ERROR

AC_FIND_X
     AC_PATH_X

AC_FIND_XTRA
     AC_PATH_XTRA

AC_FUNC_CHECK
     AC_CHECK_FUNC

AC_GCC_TRADITIONAL
     AC_PROG_GCC_TRADITIONAL

AC_GETGROUPS_T
     AC_TYPE_GETGROUPS

AC_GETLOADAVG
     AC_FUNC_GETLOADAVG

AC_HAVE_FUNCS
     AC_CHECK_FUNCS

AC_HAVE_HEADERS
     AC_CHECK_HEADERS

AC_HAVE_POUNDBANG
     AC_SYS_INTERPRETER (呼び出し方法変更)

AC_HEADER_CHECK
     AC_CHECK_HEADER

AC_HEADER_EGREP
     AC_EGREP_HEADER

AC_INLINE
     AC_C_INLINE

AC_LN_S
     AC_PROG_LN_S

AC_LONG_DOUBLE
     AC_C_LONG_DOUBLE

AC_LONG_FILE_NAMES
     AC_SYS_LONG_FILE_NAMES

AC_MAJOR_HEADER
     AC_HEADER_MAJOR

AC_MINUS_C_MINUS_O
     AC_PROG_CC_C_O

AC_MMAP
     AC_FUNC_MMAP

AC_MODE_T
     AC_TYPE_MODE_T

AC_OFF_T
     AC_TYPE_OFF_T

AC_PID_T
     AC_TYPE_PID_T

AC_PREFIX
     AC_PREFIX_PROGRAM

AC_PROGRAMS_CHECK
     AC_CHECK_PROGS

AC_PROGRAMS_PATH
     AC_PATH_PROGS

AC_PROGRAM_CHECK
     AC_CHECK_PROG

AC_PROGRAM_EGREP
     AC_EGREP_CPP

AC_PROGRAM_PATH
     AC_PATH_PROG

AC_REMOTE_TAPE
     あまり役立たないので削除

AC_RESTARTABLE_SYSCALLS
     AC_SYS_RESTARTABLE_SYSCALLS

AC_RETSIGTYPE
     AC_TYPE_SIGNAL

AC_RSH
     あまり役立たないので削除

AC_SETVBUF_REVERSED
     AC_FUNC_SETVBUF_REVERSED

AC_SET_MAKE
     AC_PROG_MAKE_SET

AC_SIZEOF_TYPE
     AC_CHECK_SIZEOF

AC_SIZE_T
     AC_TYPE_SIZE_T

AC_STAT_MACROS_BROKEN
     AC_HEADER_STAT

AC_STDC_HEADERS
     AC_HEADER_STDC

AC_STRCOLL
     AC_FUNC_STRCOLL

AC_ST_BLKSIZE
     AC_STRUCT_ST_BLKSIZE

AC_ST_BLOCKS
     AC_STRUCT_ST_BLOCKS

AC_ST_RDEV
     AC_STRUCT_ST_RDEV

AC_SYS_SIGLIST_DECLARED
     AC_DECL_SYS_SIGLIST

AC_TEST_CPP
     AC_TRY_CPP

AC_TEST_PROGRAM
     AC_TRY_RUN

AC_TIMEZONE
     AC_STRUCT_TIMEZONE

AC_TIME_WITH_SYS_TIME
     AC_HEADER_TIME

AC_UID_T
     AC_TYPE_UID_T

AC_UTIME_NULL
     AC_FUNC_UTIME_NULL

AC_VFORK
     AC_FUNC_VFORK

AC_VPRINTF
     AC_FUNC_VPRINTF

AC_WAIT3
     AC_FUNC_WAIT3

AC_WARN
     AC_MSG_WARN

AC_WORDS_BIGENDIAN
     AC_C_BIGENDIAN

AC_YYTEXT_POINTER
     AC_DECL_YYTEXT

Environment Variable Index
**************************

以下は、Autoconfが参照する環境変数の名前を、アルファベット順に並べたリストです。

Output Variable Index
*********************

以下はAutoconfが(Makefileなどの)出力ファイルを作成する際に、置換を行う変数名のアルファベット順リストです。置換動作に関してはsee Setting Output Variablesを参照。

Preprocessor Symbol Index
*************************

以下は、Autoconfマクロが定義するCプリプロセッサシンボルのアルファベット順リストです。 Autoconfを利用する場合、Cソースコード中の#ifディレクティブで以下のシンボルを使う必要があります。

Macro Index
***********

以下は、Autoconfマクロのアルファベット順リストです。リストを使いやすくするため、マクロ名先頭のAC_は除いてあります。