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 section 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 section Upgrading From Version 1を 参照してください。 Autoconfの開発経緯についてはSee section History of Autoconfを参照してください。 Autoconfに関する質問集はSee section Questions About Autoconfを参照してください。
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)
configure Scripts
Autoconfによって生成される自動設定スクリプトは、configureと
呼ばれることになってます。configureは実行されると、
設定パラメタを適切な値に書き換えながらいくつかのファイルを作成します。
configureが生成するファイルは以下のとおりです:
#define
ディレクティブを含むCヘッダファイル。
ファイル名は設定で変えられます。
(see section Configuration Header Files)
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 ---'
あるソフトウェアパッケージ用のconfigureスクリプトを
生成するためには、`configure.in'という名前のファイルを
作成する必要があります。このファイルには、ソフトウェアパッケージが
必要とする、または使う事のできるOSの機能をチェックするための
Autoconfマクロの呼出列が記述されます。
たくさんの機能をチェックするために、Autoconfマクロとして既に
たくさんのものが準備されています。section Existing Testsを
参照してください。
AutoconfマクロのないOSの機能でも、多くの場合には特製チェックルーチンを
作るのにAutoconfテンプレートマクロを使うことができます。
section Writing Testsを参照してください。
特にトリッキー、または特殊なOS機能のチェックをする場合、
`configure.in'に手でshellコマンド列を書かないといけないかも
しれません。
autoscanプログラムを使うと、`configure.in'を
書きはじめるための元ファイルを自動生成してくれます(より詳しくは
see section Using autoscan to Create `configure.in'を参照)。
`configure.in'の中でAutoconfマクロを呼び出す順番は、一部の例外を
除けば重要ではありません。`configure.in'ファイルにはAC_INIT
マクロの呼び出しが一番最初に、AC_OUTPUTマクロの呼び出しが
一番最後に入っている必要があります(see section Creating Output Files参照)。
さらに、一部のマクロは先に呼ばれる他のマクロに依存しています。
先に呼ばれるマクロによって設定される値によって動作を変えるためです。
このようなマクロはそれぞれのマクロの説明に注意書きがしてあります
(see section 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 servicesAC_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.
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 section Configuration Header Files)
マクロの呼び出しを追加する必要があります。さらに、プログラムが
Autoconfとうまく動くように、ソースコードの方に#ifディレクティブを
追加する必要があるでしょう(この作業を楽にするためのツールについては
see section Using ifnames to List Conditionalsを参照)。
autoscanはいくつかのデータファイルを使って、ソースファイルの中にある
シンボルをみつけたときに出力すべきマクロ名を決定します。
このファイルはAutoconfマクロファイルと一緒に配布され、全て
おなじフォーマットになっています。ファイルの各行はシンボル、スペース、
シンボルをみつけたときに出力するべきAutoconfのマクロ名、というふうに
なっています。`#'で始まる行はコメントです。
autoscanはPerlがインストールされている場合にのみインストールされます。
autoscanのオプションには以下があります:
--help
--macrodir=dir
AC_MACRODIRを
設定しても同じ効果が得られます。
コマンドラインオプションは環境変数の設定より
優先されます。
--verbose
--version
ifnames to List Conditionals
ifnamesはソフトウェアパッケージ用に`configure.in'を書くのを
支援します。ifnamesは、パッケージ中のソースコードで
Cプリプロセッサの条件文(`#if')に使われている識別子を出力します。
もし、パッケージが既に移植性を高めるように記述されている場合には、
configureでなにをチェックしないといけないか決めるのに使えます。
autoscanの出力を穴うめして`configure.in'を作成するのにも
役立ちます(see section Using autoscan to Create `configure.in')。
ifnamesはコマンドラインに指定されたCソースファイル(なにも
指定されなかったら標準入力)をチェックし、結果を標準出力に出力します。
結果は#if、#elif、#ifdef、または#ifndef
の各ディレクティブで使われている識別子をソートして出力します。
各行にはひとつの識別子と、その識別子を使っているファイル名をスペースで
区切ったものが出力されます。
ifnamesは以下のオプションを受け付けます:
--help
-h
--macrodir=dir
-m dir
AC_MACRODIRを
設定しても同じ効果が得られます。
コマンドラインオプションは環境変数の設定より
優先されます。
--version
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 section Writing Macros
参照)。同じマクロがautoconfが読み込むファイルのうち複数のファイルで
定義されていた場合、あとから読み込まれたものが有効になります。
autoconfは以下のオプションを受け付けます:
--help
-h
--localdir=dir
-l dir
--macrodir=dir
-m dir
AC_MACRODIRを
設定しても同じ効果が得られます。
コマンドラインオプションは環境変数の設定より
優先されます。
--version
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 section Automatic Remakingを参照してください。この方法
を使うとconfiguration headerテンプレートのタイムスタンプはきちんと取り扱
われますが、`--macrodir=dir'や`--localdir=dir'は渡
されません。
autoreconfは以下のオプションを受け付けます:
--help
-h
--force
-f
--localdir=dir
-l dir
--macrodir=dir
-m dir
AC_MACRODIRを設定しても同じ効果が
得られます。コマンドラインオプションは環境変数の
設定より優先されます。
--verbose
autoreconfからautoconf(と、必要なら
autoheader)を呼び出すディレクトリ名を表示します。
--version
Autoconfで生成されたconfigureスクリプトは、初期化や結果出力の
ための情報を必要します。たとえば、パッケージのソースファイルは
どこにあるのかとか、どのような出力ファイルを生成すべきか、などです。
以下の節では、初期化と結果出力について説明します。
configure Input
configureスクリプトは他の全てのマクロより先に、AC_INIT
マクロを呼び出さねばなりません。必ず呼び出されなければならないマクロは
AC_INITとAC_OUTPUTだけです(see section Creating Output Files)。
configureは、指定された
ディレクトリにソースコードが実際あるかどうか、
そのファイルが存在するかどうかを調べることで判断します。
ときには、ユーザはコマンドラインオプション`--srcdir'で
間違ったディレクトリを指定するかもしれません; この判定は、
安全のためのチェックです。詳しくはSee section Running configure Scriptsを
参照してください。
手動で設定を行うパッケージや、installプログラムを
利用するパッケージでは、AC_CONFIG_AUX_DIRを使って、
configureに他のshellスクリプトがどこにあるかを
知らせる必要があるかもしれません。たいていはデフォルトで
調べにいく場所で正しいのですが。
configureスクリプトを利用することを
指定します。dirは絶対パス、または
`srcdir'からの相対パスで指定します。
デフォルトは`srcdir'または
`srcdir/..'または
`srcdir/../..'のうち、
`install-sh'が最初にみつかった場所です。
他のファイルの置き場所についてはチェックが
行われません。これはAC_PROG_INSTALLを
使っただけで他のファイルを配布しなければ
ならなくなるのを防ぐためです。
このマクロは`install.sh'もチェックしますが、
このファイル名はobsoleteです。なぜなら、
`Makefile'がない場合、makeが組み込み
ルールを使って`install.sh'から`install'を
生成しようとするからです。
Autoconfで生成されたconfigureスクリプトは、
最後にAC_OUTPUTを呼び出さねばなりません。
このマクロは、`Makefile'や他のファイルを自動設定結果にしたがって
生成します。configure.inに必ず含まれなければならない
マクロは、AC_OUTPUTの他にはAC_INITだけです(see section Finding configure Input)。
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に指定された
コマンドの直前に実行されます。
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を使うことができます。
makeが変数MAKEを設定しているなら、
変数SET_MAKEを空にします。
そうでない場合、SET_MAKEを`MAKE=make'に
設定します。内部でAC_SUBSTを
SET_MAKEを置換するように呼び出します。
このマクロを利用する場合、MAKEを利用する
各々のMakefile.inに以下のような行を置いてください:
@SET_MAKE@
配布パッケージの各サブディレクトリのうちでコンパイルやインストールが
必要なディレクトリには、`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 section Setting Output Variablesを参照してください。
configureスクリプトを用いるソフトウェアパッケージは、
`Makefile'ではなくて`Makefile.in'と一緒に配布される
必要があります; こうすれば、ユーザはコンパイルの前に必ず
configureスクリプトを実行して、各々のシステムにあわせた
設定を行うことになります。
See section `Makefile Conventions' in The GNU Coding Standards, for more information on what to put in `Makefile's.
Autoconfマクロでいくつかの出力変数が前もって設定されています。 Autoconfマクロの一部では、追加の出力変数を設定します。これについては 各マクロの説明のところで述べられています。 出力変数の完全なリストをみるにはSee section Output Variable Indexを 参照してください。前もって設定される出力変数の意味を以下に示します。 `dir'で終る出力変数については、 See section `Variables for Installation Directories' in The GNU Coding Standards, を参照してください。
configureによって
自動生成されました」というコメントと、
入力ファイル名を含んだコメント文字列です。
AC_OUTPUTは、生成する`Makefile'の
先頭に、この文字列を含むコメント行を
付け加えます。他のファイルについては、
この変数を各入力ファイル先頭のコメント
領域の中で参照しましょう。たとえば、
shellスクリプトである入力ファイルの先頭は
以下のようになります:
#! /bin/sh # @configure_input@
また、この行を置いておくことで、ファイルを
編集する人にconfigureを使って
処理しないといけない、ということを
思い出させることができます。
srcdirとおなじです。
configureが
実行された環境で指定されていなかった場合、
AC_PROG_CCを呼び出したときの
デフォルト値(または、呼び出さなかったら空)が
設定されます。configureはこの変数の
値を使って、Cコンパイラの機能チェックのための
コンパイルを行います。
configureが実行された
環境でこの変数が指定されなかった場合、
デフォルト値は空になります。
configureはこの変数の
値を使って、Cコンパイラの機能チェック
のためのコンパイル、または
プリプロセスを行います。
configureが
実行された環境で指定されていなかった場合、
AC_PROG_CXXを呼び出したときの
デフォルト値(または、呼び出さなかったら空)が
設定されます。configureはこの変数の
値を使って、C++コンパイラの機能チェックのための
コンパイルを行います。
configure が実行された環境でこん環境変数が指定されていなかった場
合、 AC_PROG_F77 を呼び出した時のデフォルト値(または、呼び出さな
かった場合には空)が設定されます。configure はこの変数の値を使って
Fortran 77 コンパイラの feature を調べるためのプログラムをコンパイルしま
す。
AC_CONFIG_HEADERマクロが呼び出された
場合、configureは`@DEFS@'を
`-D'群でなく、`-DHAVE_CONFIG_H'で
置き換えます(see section Configuration Header Files
参照)。この変数はconfigureがテストを
行っている間は定義されません。出力ファイルを
生成するときにだけ定義されます。
既に行われてたテストの結果を参照する
場合には、See section Setting Output Variablesを
参照してください。
configureが実行された環境で
指定されていなかった場合、
デフォルト値の空文字列が
設定されます。
configureはこの変数の値を
使って、Cコンパイラの機能チェックの
際のリンクを行います。
ソフトウェアパッケージを展開した単一のソースコードツリー上で、 同時に複数のアーキテクチャのためのコンパイルを行うことができます。 オブジェクトファイルは各アーキテクチャ別のディレクトリに格納されます。
このためには、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
以下に示すようなルールをトップレベルの`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 section Creating Output Filesを参照。
設定ファイルにまつわる依存関係については、See section Recreating a Configurationを 参照。
パッケージの移植性テストで、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'を使ってパッケージをコンパイルすることができます
(訳註: 結構意訳)。
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)をつけたり することができます。
配布パッケージには、ヘッダファイルのテンプレートを含める必要があります。
テンプレートは出力がこうあってほしいと思うとおりに書き、
コメントと、デフォルト値を含めた#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
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
--macrodir=dir
-m dir
AC_MACRODIRを設定しても同じ効果が
得られます。コマンドラインオプションは環境変数の
設定より優先されます。
--version
ほとんどの場合、サブディレクトリに`Makefile'を作るには
AC_OUTPUTを使えば十分です。
しかし、複数の独立したパッケージを制御するconfigure
スクリプトを作る場合には、AC_CONFIG_SUBDIRSを使うことで
サブディレクトリにあるconfigureスクリプトを呼び出すことができます。
AC_OUTPUTマクロに、
dirに指定されたディレクトリ
にあるconfigureを実行させます。
ディレクトリが複数の場合はdirに
ディレクトリをスペースで区切って並べます。
ディレクトリdirがみつからない場合、
エラーにはなりません。これは、
configure大きなソースコード
ツリーのうちの実在する一部分だけを
設定できるようにするためです。
dirに`configure.in'があって
`configure'がない場合、Cygnus
ディレクトリAC_CONFIG_AUXDIRにある
Cygnus configureスクリプトが
使われます。
サブディレクトリにあるconfigure
スクリプトには、現在実行中の
configureスクリプトと、
基本的には同じコマンドライン引数が
渡されます。
コマンドライン引数は必要な場合には
わずかに変更されます(例えば、
キャッシュファイルやソースファイルの
あるディレクトリへの相対パスの調整など)。
このマクロは出力変数subdirsに、
サブディレクトリのリスト(dir ...)
を設定します。`Makefile'ルールでは
この変数を使って、どのサブディレクトリを
再帰的にmakeすればいいのか決める
ことができます。このマクロは複数回
呼び出しても構いません。
デフォルトでは、configureはインストールのためのファイル名の
ディレクトリプレフィクスを`/usr/local'に設定します。configureの
ユーザは、`--prefix'と`--exec-prefix'オプションを使って、
他のディレクトリプレフィクスを選択することができます。
デフォルトの設定を変更するにはふたつの方法があります:
configure生成時と、configureの実行時です。
一部のソフトウェアパッケージでは、デフォルトで`/usr/local'以外のところに
インストールしたい場合があるでしょう。このためには、
AC_PREFIX_DEFAULTマクロを使ってください。
configureスクリプトが、既にインストールされている
関係あるプログラムのインストール位置から、
インストールディレクトリプレフィクスを推測してくれると
便利なこともあるでしょう。このためには、AC_PREFIX_PROGRAMを
呼び出しましょう。
PATHをたぐって
探されます。もしprogramが
PATHに書かれたディレクトリの
どこかに存在した場合、ディレクトリ
プレフィクスをprogramのある
ディレクトリの親ディレクトリに
設定します; もしなかったら、
`Makefile.in'に指定された
プレフィクスをそのままにします。
例えば、programがgccで、
PATHを探した結果
`/usr/local/gnu/bin/gcc'が
見つかった場合、プレフィクスは
`/usr/local/gnu'になります。
configure
以下のマクロはconfigureスクリプトのバージョン番号を管理します。
このマクロは使っても使わなくても構いません。
configureを生成するのに
使われているAutoconfがversion
以前のものだった場合、エラーメッセージを
標準エラー出力に出力し、configureを
生成しません。例えば:
AC_PREREQ(1.8)
このマクロは、`configure.in'が、
Autoconfのバージョンアップで変化した
自明でないふるまいに依存している場合に
役立ちます。もし最近定義されたマクロが
必要なだけの場合、AC_PREREQマクロは
あまり使いでがありません。なぜなら、
autoconfはAutoconfの
ユーザに、マクロがないというエラーを
出力しているはずだからです。
同様のことは、`cofigure.in'を
AC_PREREQが追加される以前の
Autoconfに通したときに起こります。
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
以下のマクロは、パッケージが必要な、あるいは使いたい特定のOSの機能を 調べます。以下のマクロに定義されていない機能の有無をチェックしたい場合、 基本テストマクロ(primitive test macro)に適切な引数を渡してチェックを 実現することになります(see section Writing Tests参照)。
以下のテストは、どの機能をチェックしているか、なにがわかったかを
知らせるメッセージを出力します。チェック結果はconfigureを
再度実行したときのためにキャッシュされます(see section Caching Results参照)。
マクロには出力変数を設定するものがあります。出力変数の値を 参照するやりかたについてはSee section Substitutions in Makefilesを参照してください。 以下で、「nameを定義します」という文は、 「Cプリプロセッサシンボルnameを1に定義します」という意味です。 定義された値をプログラム中で参照するやりかたについてはSee section Defining C Preprocessor Symbols を参照してください。
以下のマクロは特定のプログラムの有無、またはふるまいをチェックします。 マクロは、いくつかの候補となるプログラムからどれかひとつを選んだり、 選んだものをどう利用するかを定めるために使われます。 パッケージで使うプログラム専用のマクロが定義されておらず、 そのプログラムに関する特殊なチェックが必要ない場合、 汎用のマクロのうちいずれかを利用することができます。
以下のマクロは特定のプログラムをチェックします--- プログラムが存在するかどうか、およびいくつかのプログラムについては プログラム特有の機能をチェックします。
yytextの型が`char []'でなく
`char *'だった場合、
YYTEXT_POINTERを定義します。
また、lexの出力ファイル名を
出力変数LEX_OUTPUT_ROOTに
定義します。通常は`lex.yy'ですが
他の値のこともあります。これらの結果は
lexとflexのどちらが
利用されているかによって変わります。
mawk、gawk、nawk、
awkがあるかどうかをこの順序で
調べ、出力変数AWKの値を
最初にみつけたプログラムの
名前に設定します。mawkを最初に
調べるのは、これが一番高速動作する
実装だと言われているからです。
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 section Manual Configurationを
参照してください。
NO_MINUS_C_MINUS_Oを定義します。
CPPに、Cプリプロセッサを
実行するためのコマンド名を定義します。
`$CC -E'が動かない場合、
`/lib/cpp'が使われます。
CPPを`.c'ファイル以外に
用いるのは移植性がありません。
移植性のために、CPPに通すのは
拡張子が`.c'のファイルだけにしましょう。
現在選択されている言語がCの場合
(see section Language Choice参照)、
一部のテストマクロは出力変数CPPの
値を間接的に利用しています。
「間接的に」というのは、テストマクロ内部でマクロ
AC_TRY_CPP、AC_CHECK_HEADER、
AC_EGREP_HEADER、AC_EGREP_CPPを
呼び出しているからです。
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 section Manual Configurationを
参照してください。
CXXCPPに、C++プリプロセッサを
実行するためのコマンド名を定義します。
`$CXX -E'が動かない場合、
`/lib/cpp'が使われます。
CXXCPPを`.c'、`.C'
または`.cc'以外のファイルに
用いるのは移植性がありません。
移植性のために、CPPに通すのは
上記に挙げた拡張子をもつファイルだけにしましょう。
現在選択されている言語がC++の場合
(see section Language Choice参照)、
一部のテストマクロは出力変数CXXCPPの
値を間接的に利用しています。
「間接的に」というのは、テストマクロ内部でマクロ
AC_TRY_CPP、AC_CHECK_HEADER、
AC_EGREP_HEADER、AC_EGREP_CPPを
呼び出しているからです。
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' に設定されます。
F77_NO_MINUS_C_MINUS_O を定義します。
ioctlがうまく動かない場合、
出力変数CCに`-traditional'を
付け加えます。
通常、これはGNU Cコンパイラ用に修正された
ヘッダファイルがインストールされていない
古いシステムで起こります。
GNU Cコンパイラの最近のバージョンでは、
インストール時にヘッダファイルを修正するので、
この問題は起きなくなってきました。
PATH上にBSD互換の
installプログラムがあった場合、
出力変数INSTALLをその名前にセットします。
さもなくば、`dir/instal-sh -c'を
セットします。
後者の場合、AC_CONFIG_AUX_DIRに
指定されたディレクトリ(またはデフォルトの
ディレクトリ)を使ってdirを決定します
(see section Creating Output Files)。
さらに、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'に単に含めればいいのです。
flexがあったら、出力変数LEXを
`flex'に、(もし`libfl.a'が
標準的な場所にあったら)LEXLIBを
`-lfl'に設定します。
もしflexがなかったら、
LEXを`lex'に、
LEXLIBを`-ll'に設定します。
LN_Sを`ln -s'に設定します。
動かなかったら、`ln'に設定します。
カレントディレクトリ以外のパス名をリンク先として
指定した場合、`ln'と`ln -s'では
意味が異なってきます。
`$(LN_S)'を使って安全にリンクを作成するためには、
makefile中でどちらが使われているか調べて動作を変えるか、
lnコマンドをリンクが置かれるディレクトリで
呼び出すかのいずれかを行わねばなりません。
言い替えれば、以下はうまく動きません:
$(LN_S) foo /x/bar
ので、かわりにこうしましょう:
(cd /x && $(LN_S) foo bar)
ranlibがみつかったら、出力変数
RANLIBを`ranlib'に設定します。
さもなくば、:(なにもしない)に設定します。
bisonがみつかったら、出力変数
YACCを`bison -y'に設定します。
かわりにbyaccがみつかったら、出力変数
YACCを`byacc'に設定します。
さもなくば、yaccに設定します。
以下のマクロは、プログラムをみつけるための専用マクロが特に
定義されていないプログラムをみつけるために使われます。
プログラムの存在だけでなくプログラムの挙動を調べたい場合、
自分でテストスクリプトを記述する必要があります(see section Writing Tests)。
デフォルトでは、マクロは環境変数PATHを使います。
ユーザのPATHにないようなプログラムをチェックする場合、
以下のように自分でサーチパスを変更してマクロに渡すことができます:
AC_PATH_PROG(INETD, inetd, /usr/libexec/inetd, $PATH:/usr/libexec:/usr/sbin:/usr/etc:etc)
AC_CHECK_FILE
files に並べられた各ファイルにつきそれぞれ一回づつ
AC_CHECK_FILE を適用します。さらに、各ファイルが見つかるごとに
`HAVEfile' を 1 にセットします。
PATH中に
あるかどうかを調べます。もし発見された場合variableを
value-if-foundに設定します。発見されなかった場合
(value-if-not-foundが指定されていた場合は)
value-if-not-foundに設定します。
このマクロは、reject (絶対パスのファイル名)を
サーチパス上で発見してもそれは無視します。
この場合、variableはパス上でみつかった
prog-to-check-forで、rejectではない
ファイルの絶対パス名になります。
variableが既に設定されていた場合、なにもしません。
variableのために、AC_SUBSTを呼び出します。
PATH上に
あるかどうかを調べます。もしあった場合、
そのプログラム名をvariableに設定します。
さもなくば、次のプログラム名を探します。
もし、指定された全てのプログラムがなかった場合、
value-if-not-foundの値をvariableに設定します。
もしvalue-if-not-foundが指定されていなかったら、
variableの値は変更されません。
variableのために、AC_SUBSTを呼び出します。
AC_CHECK_PROGと同様ですが、prog-to-check-forの
先頭にAC_CANONICAL_HOSTで判定されたホストタイプを
つけたものを最初に探します(see section Getting the Canonical System Type参照)。
例えば、ユーザが`configure --host=i386-gnu'を
実行し、その中で
AC_CHECK_TOOL(RANLIB, ranlib, :)
というマクロが使われていたなら、まずパス上の
`i386-gnu-ranlib'が探され、もしあったなら
`i386-gnu-ranlib'をRANLIBに設定します。
プログラムがなければRANLIBは`:'にされます。
AC_CHECK_PROGと同様ですが、
プログラムが発見された場合variableを
prog-to-check-forの全体に設定します。
AC_CHECK_PROGSと同様ですが、
progs-to-check-forの中のいずれかが
見付かったら、プログラムの絶対パスを
variableに設定します。
以下のマクロは指定されたC、C++またはFortran 77ライブラリファイルが 存在するかどうかを調べます。
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が存在することを 検出できません。なぜなら、未解決シンボルのせいでリンクが 常に失敗するからです。
AC_CHECK_LIBを、引数functionを
mainにして呼び出すのと同じです。引数libraryは
`foo'でも`-lfoo'でも、あるいは`libfoo.a'
とでも指定できます。これらの全ての場合に、コンパイラには
引数`-lfoo'が渡ります。
libraryにshell変数を渡すことはできません。
libraryは文字列リテラルである必要があります。
このマクロはobsoleteです。
AC_TRY_LINK_FUNCをライブラリ指定なしで呼び出し、
駄目ならsearch-libsのライブラリを順に指定して呼び出すのと等価です。
関数がみつかったらaction-if-foundを実行します。 みつからなかったらaction-if-not-foundを実行します。
libraryをリンクしたときに未定義シンボルが出て、 他のライブラリをリンクすればそれが解決するのであれば、 追加のライブラリをother-librariesにスペースで区切って指定してください。 例えば`-lXt -lX11'とか。 other-librariesを指定しなかった場合、 このマクロはfunctionの認識に失敗します。 追加のライブラリがなければ、テストプログラムのリンクは常に失敗するからです。
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.
訳註: このエントリはどうみても原文での削除忘れである。
以下のマクロは、Cのライブラリ関数があるかどうかを調べます。 もし、あるマクロをチェックする特別の関数が定義されておらず、 特殊なチェックが必要でない場合には、汎用の関数チェックマクロを 用いることができます。
以下のマクロは、特定のCライブラリ関数をチェックします --- 関数が存在するかどうか、および特定の引数を与えられたときの 挙動がチェックされます。
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
closedirが
意味のある値を返さない場合、CLOSEDIR_VOIDを
定義します。
定義されなかった場合には、
closedirを呼んだ場合
返り値を用いてエラーチェックを行うべきです。
fnmatchが存在し、かつ動作するなら、
HAVE_FNMATCHを定義します
(ちなみに、SunOS 5.4付属のものは動きません)。
getloadavgが利用できるなら、
HAVE_GETLOADAVGを定義し、
LIBSに必要なライブラリファイルを追加します。
もしgetloadavgが利用できないなら、
`getloadavg.o'を出力変数LIBOBJSに追加し、
必要ならいくつかのCプリプロセッサマクロや出力変数を定義します:
SVR4、DGUX、UMAXまたは
UMAX4_3のうちであてはまるものを定義します。
NLIST_STRUCTを定義します。
NLIST_NAME_UNIONを定義します。
LDAV_PRIVILEGEDが定義された場合、
getloadavgが正しく動作するには、
プログラムは(setuid bitをたてるなどして)
root権限で動作するようにインストールされる必要があります。
この場合、GETLOADAVG_PRIVILEGEDが定義されます。
NEED_SETGIDが定義されます。
インストールする際にsetgid bitをたてる必要がある場合には
値は`true'に、さもなくば値は`false'になります。
NEED_SETGIDが`true'である場合には、
プログラムファイルの所属すべき
gidがKMEM_GROUPに定義されます。
getmntentがライブラリファイル
`sun'、`seq'および`gen'の
いずれかに含まれているかどうか調べます
(順に、Irix 4、PTX、Unixwareの場合の
ライブラリファイルです)。
getmntentが存在した場合、
HAVE_GETMNTENTを定義します。
getpgrpが引数をとらない場合
(つまりPOSIX.1準拠の場合)、
GETPGRP_VOIDを定義します。
定義されなかった場合、getpgrpはBSDでのように
プロセスIDを引数にとります。
このマクロはgetpgrpがあるかどうかは
全く調べません; getpgrpがない場合に
対処するには、先にAC_CHECK_FUNCを使って
getpgrpがあるかどうか調べてください。
memcmpがないか、
または(SunOS 4.1.3のように)8bitデータに対して
使えない場合、`memcmp.o'を
出力変数LIBOBJSに追加します。
mmapが存在して正常動作する場合、
HAVE_MMAPを定義します。
動作チェックは、既にマップされたメモリを
自プロセスの固定アドレスにマップする場合に関してのみ
行われます。
select 関数の引数のそれぞれが正しい型を通すかをテストします。そし
て、SELECT_TYPE_ARG1, SELECT_TYPE_ARG234,
SELECT_TYPE_ARG5 にそれぞれの型を定義します。
SELECT_TYPE_ARG1 はデフォルトで `int' 型に、
SELECT_TYPE_ARG234 はデフォルトで `int *' 型に、
SELECT_TYPE_ARG5 はデフォルトで `struct timeval *' に定義さ
れます。
setpgrpが引数をとらない場合
(つまりPOSIX.1準拠の場合)、
SETPGRP_VOIDを定義します。
定義されなかった場合、setpgrpはBSDでのように
プロセスIDを引数にとります。
このマクロはsetpgrpがあるかどうかは
全く調べません; setpgrpがない場合に
対処するには、先にAC_CHECK_FUNCを使って
setpgrpがあるかどうか調べてください。
setvbufの第2引数がバッファリングの形式で、
第3引数がバッファへのポインタの場合、
SETVBUF_REVERSEDを定義します。
SETVBUF_REVERSEDが定義されるのは、
release 3以前のSystem Vの場合です。
strcollが存在して正常動作する場合、
HAVE_STRCOLLを定義します。
このマクロはstrcollがあるかどうかを
AC_CHECK_FUNCより詳しく調べます。
一部のシステムでは、strcollの
定義が誤っているためこの関数を使うべきではないからです。
strftimeが`intl'ライブラリにあるかどうかを調べます
(これはSCO UNIXのためです)。
もしあった場合、HAVE_STRFTIMEを定義します。
HAVE_UTIME_NULLを定義します。
HAVE_VFORK_Hを定義します。
正常動作動作するvforkが発見されなかった場合、
vforkをforkに#defineします。
このマクロは、いくつかのシステムでのvforkの
バグをチェックし、バグつきの場合にはvforkが
みつからなかったかのように振舞います。
ただし、子プロセスでsignalを呼んでも
親プロセスのシグナルハンドラが変更されない場合には
これはバグつきとはみなされません。
子プロセスでシグナルハンドラを変更することは
めったにないからです。
vprintfが存在する場合、
HAVE_VPRINTFを定義します。
ない場合に_doprntが存在したら、
HAVE_DOPRNTを定義します。
ちなみに、vprintfが存在したら、
vfprintfとvsprintfも
存在すると仮定して構いません。
wait3が存在し、呼び出し時に第3引数
(`struct rusage *')の指し先の内容がきちんと
設定される場合、
HAVE_WAIT3を定義します。
ちなみに、HP-UXでは第3引数の差し先はきちんと設定されません。
以下のマクロは、チェックのための特別のマクロがないライブラリ関数について
調べるために用意されています。
ライブラリ関数がデフォルトのCライブラリに入っていない
可能性がある場合には、AC_CHECK_LIBを用いて
そのライブラリファイルがあるかどうか調べてください。
ライブラリ関数があるかどうかだけでなく、その振舞いも調べる
必要がある場合には、自前でテストを記述する必要があるでしょう
(see section Writing Tests)。
AC_CHECK_FUNCSを使ったほうがいいでしょう。
このマクロはAC_LANG_CPLUSPLUSが呼ばれているいないに関わらず
C linkageで関数を探します。
C++ではCよりもライブラリ関数がきちんと標準化されているので、
AC_CHECK_FUNCを使う機会は少なそうだからです
(環境を調べる対象の言語を選ぶやりかたについては、
see section Language Choiceを参照)。
HAVE_function(全部大文字)を定義します。
action-if-foundには、
各々の関数がみつかったときに実行したいshellスクリプトを記述します。
action-if-foundを`break'にすると、
最初に関数が見つかったところでループを抜けることができます。
action-if-not-foundには、
各関数がみつからなかったときに実行されるshellスクリプトを記述します。
LIBOBJSに`function.o'を追加します。
この動作は、
AC_CHECK_FUNCSで
action-if-not-foundに
「出力変数LIBOBJSに`function.o'を追加する」
と記述した場合と似ています。
ライブラリの置き換え用の関数を定義するときには、
プロトタイプ宣言を`#ifndef HAVE_function'で
くくっておいた方がいいでしょう。
システムにfunctionがある場合、
システム定義のincludeファイルのどこかにプロトタイプ宣言があるはずです。
定義が矛盾するかもしれないから、システムにfunctionが
あるときには再定義を避けるべきです。
以下のマクロはCヘッダファイルがあるかないか調べます。 あなたのチェックしたいヘッダファイルについて 特定ヘッダファイル向けのマクロがなくて、 しかも特殊なことを調べる必要がなければ、 汎用のヘッダファイル検査マクロを使うとよいでしょう。
以下のマクロは特定のシステムヘッダファイルを検査します。 ファイルがあるかどうか、それから必要なときには なにを定義しているかを検査します。
sys_siglistが`signal.h'または`unistd.h'で定義されているなら、
SYS_SIGLIST_DECLAREDを定義します。
AC_HEADER_DIRENTとAC_FUNC_CLOSEDIR_VOIDを呼ぶのと似ていますが、
定義するCプリプロセッサマクロが違います。
AC_DIR_HEADERは
どのヘッダファイルがみつかったのかを表すCプリプロセッサマクロを定義します。
AC_DIR_HEADER、およびこれにより定義されるCプリプロセッサマクロは
obsoleteです。
定義されるCプリプロセッサマクロは以下のとおり:
DIRENT
SYSNDIR
SYSDIR
NDIR
さらに、関数closedirの返り値に意味がない場合には
VOID_CLOSEDIRを定義します。
HAVE_DIRENT_H
HAVE_SYS_NDIR_H
HAVE_SYS_DIR_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'ライブラリも検査します。
major、minor、それから
makedevが定義されておらず、
`sys/mkdev.h'で定義されている場合、
MAJOR_IN_MKDEVを定義します。
`sys/sysmacros.h'で定義されている場合、
MAJOR_IN_SYSMACROSを定義します。
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)'を使えば大丈夫です。
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
memcpyやmemcmpなどが`string.h'で定義されておらず、
`memory.h'が存在する場合、NEED_MEMORY_Hを定義します。
このマクロはobsoleteです。
かわりにAC_CHECK_HEADERS(memory.h)を使ってください。
AC_HEADER_STDCの例参照。
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'があります。
rindexやbzeroがないシステムなら
USGを定義します。
このマクロは
`string.h'、strrchr、memset等が存在すると仮定しています。
USGはobsoleteです。
このマクロでなしに、AC_HEADER_STDCの例題をみてください。
以下のマクロは、特定のヘッダファイル用マクロが定義されていない ヘッダファイルを検査するためのものです。 ヘッダファイルがあるかないかだけでなく、中身もチェックしたい場合、 自力で検査マクロを記述しないといけません(see section Writing Tests参照)。
AC_CHECK_HEADERSを使った方がいいでしょう。
HAVE_header-file(全部大文字)を定義します。
action-if-foundには、
各々のヘッダファイルがみつかったときに実行したいshellスクリプトを記述します。
action-if-foundを`break'にすると、
最初にヘッダファイルが見つかったところでループを抜けることができます。
action-if-not-foundには、
各ヘッダファイルがみつからなかったときに実行されるshellスクリプトを記述します。
以下のマクロは特定の構造体や構造体のメンバを検査します。
ここにない構造体を検査したい場合、
AC_EGREP_CPP (see section Examining Declarations)やAC_TRY_COMPILE
(see section Examining Syntax)を使ってください。
S_ISDIRやS_ISREGなどの、`sys/stat.h'で定義されている
マクロが正しく動かない場合(返り値が嘘の場合)、
STAT_MACROS_BROKENを定義します。
Tektronix UTekV、Amdahl UTS、それからMotorola System V/88が該当します。
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
struct statにメンバst_blksizeが定義されているなら、
HAVE_ST_BLKSIZEを定義します。
struct statにメンバst_blocksが定義されているなら、
HAVE_ST_BLOCKSを定義します。
もしなければ、`fileblocks.o'を出力変数LIBOBJSに足します。
struct statにメンバst_rdevが定義されているなら、
HAVE_ST_RDEVを定義します。
struct tmが定義されていなければ、
TM_IN_SYS_TIMEを定義します。
TM_IN_SYS_TIMEは、struct tmの定義が欲しければ
`sys/time.h'をincludeせよ、という意味です(訳註: 意訳)。
struct tmにメンバtm_zoneが定義されているなら、
HAVE_TM_ZONEを定義します。
グローバル変数tznameが定義されていたら、HAVE_TZNAMEを定義します。
以下のマクロはCのtypedefを検査します。 検査したいtypedef用に特定のマクロがなくて、 しかも特殊な検査をしたいわけでないのなら、 汎用のtypedef検査マクロが使えます。
以下のマクロは、`sys/types.h'と`stdlib.h'の中のC typedefを 検査します(もしファイルがあれば、ですが)。
GETGROUPS_Tを、
getgroupsの引数の型(配列の基底型)にあわせて、
gid_tまたはintに定義します。
mode_tが定義されていない場合、
Cプリプロセッサマクロmode_tをintに#defineします。
off_tが定義されていない場合、Cプリプロセッサマクロoff_tを
longに#defineします。
pid_tが定義されていない場合、Cプリプロセッサマクロpid_tを
intに#defineします。
signalが
「返り値がvoidの関数へのポインタ(つまり、(void (*)())」を
返す場合、RETSIGTYPEをvoidに定義します。
さもなくば、RETSIGTYPEをintに定義します。
シグナルハンドラ関数を定義するときには、
返り値をRETSIGTYPEにしましょう:
RETSIGTYPE
hup_handler ()
{
...
}
size_tが定義されていなければ、Cプリプロセッサマクロsize_tを
unsignedと定義します。
uid_tが定義されていなければ、
Cプリプロセッサマクロuid_tをintに、
gid_tをintに定義します。
このマクロは、 特定のtypedef検査マクロが提供されていないtypedefについて調べるときに 使います。
#defineします。
もしヘッダファイルが存在するなら、
`stdlib.h'や`stddef.h'についても調べます。
以下のマクロはCコンパイラやマシンアーキテクチャの特性を調べます。
以下にない性質を調べたい場合、
AC_TRY_COMPILE (see section Examining Syntax) か AC_TRY_RUN
(see section Checking Run Time Behavior)を使ってください。
WORDS_BIGENDIANを定義します。
例えばMotorolaやSPARCなどのCPUがこれにあたります。
IntelやVAXは違います。
constを完全にサポートしていなければ、
constを空に#defineします。
世の中にはconstをサポートしているのに_STDC__を定義していない
Cコンパイラや、
逆にconstを完全にはサポートしていないのに_STDC__を定義している
Cコンパイラがあります。
AC_C_CONSTを使えば、プログラム中では必ずCコンパイラがconstを
サポートしているつもりで、constを書けば大丈夫です。
Cコンパイラがconstをサポートしていなければ、
constは`Makefile'またはconfiguration header fileで空にされます。
inlineをサポートしていればなにもしません。
inlineがサポートされておらず、__inline__あるいは
__inlineがサポートされていれば、
inlineを__inline__か__inlineに#defineします。
どちらもサポートされていなければ空にします。
charが符号なし(unsigned)だったら、
__CHAR_UNSIGNED__を定義します。
ただし、Cコンパイラが既に__CHAR_UNSIGNED__を
定義していたらなにもしません。
long double型をサポートしていたら、
HAVE_LONG_DOUBLEを定義します。
世の中には
_STDC__を定義していないのに
long doubleをサポートしているCコンパイラや、
_STDC__を定義しているのに
long doubleをサポートしていないCコンパイラがあります。
HAVE_STRINGIZE を定義します。文字列化演算子
`#'とは、下記のようなマクロです。
#define x(y) #y
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になります。
intが16ビットの場合、INT_16_BITSを定義します。
このマクロはobsoleteです。
かわりにより汎用的な`AC_CHECK_SIZEOF(int)'を使ってください。
long intが64ビットの場合、LONG_64_BITSを定義します。
このマクロはobsoleteです。
かわりにより汎用的な`AC_CHECK_SIZEOF(long)'を使ってください。
以下のマクロはFortran 77コンパイラの特性を調べます。
以下にない性質を調べたい場合、
AC_TRY_COMPILE (see section Examining Syntax) か AC_TRY_RUN
(see section Checking Run Time Behavior)を使ってください。
テストの前に、AC_LANG_FORTRAN77 (see section Language Choice)を使って
チェック対象コンパイラをFortran 77に切替えるのを忘れずに。
FLIBSが設定されます。
このマクロは複数言語のソースコード(例えばC++とFortran 77)をひとつの プログラムや共有ライブラリの中に混ぜないといけないときに使うものです (see section `Mixing Fortran 77 With C and C++' in 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が作られたのです。
次のマクロは OS のサービスや機能を調べるためのものです。
CYGWINを`yes'に設定します。
Cygwin環境がなければshell変数CYGWINを空にします
(訳註: Cygwin環境はあったりなかったりするものなのでしょうか?
それとも「Cygwin環境であれば」という方が適当?
コメント求む)。
EXEEXTを定義します
(訳註: substitute variableの訳語はなに?)。
通常、Unixでは空文字列、Win32では`.exe'または`.EXE'になります。
OBJEXTを定義します。
通常、Unixでは`.o'、Win32では`.obj'になります。
MINGW32を`yes'に設定します。
MingW32環境がなければshell変数MINGW32を空にします
(訳註: Cygwinに同じ)。
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'でなければ空になります。
AC_PATH_Xの拡張版です。
X_CFLAGSにXが必要とするCコンパイラのフラグを、
X_LIBSにリンカのフラグを設定します。
Xがない場合にはX_CFLAGSに`-DX_DISPLAY_MISSING'を追加します。
このマクロは、
Xを使うプログラムをコンパイルするときに特別なライブラリが必要なら、
それもチェックしてX_EXTRA_LIBSに追加します。
X11R6特有のライブラリのうち`-lX11'より前に指定しないといけない
ものがあったら、
それをX_PRE_LIBSに追加します。
configure.inの中に記述するshellスクリプトの中で、
shell変数ac_cv_sys_interpreterを使えます。
このshell変数の値はシステムが`#!'をサポートしていれば`yes'、
していなければ`no'になります。
HAVE_LONG_FILE_NAMESを定義します。
HAVE_RESTARTABLE_SYSCALLSを定義します。
以下のマクロは、ヘッダファイルやライブラリに癖があるなどの理由で、 特別な取扱が必要なOSについてチェックします。 これらのマクロは無理矢理作った逃げ道です (訳註: wartだから「目の上のたんこぶ」とか言ってもいいのだけれど、 それでは意味が通じない)。 本来はよりシステマチックに、ライブラリやヘッダファイルの内容および機能や、 OSで提供される環境について調べるべきです。
_ALL_SOURCEを定義します。
BSDの機能の一部が使えます。
Cコンパイラを実行するマクロより前に使わないといけません。
LIBSに追加します。
このマクロはobsoleteです。
かわりにAC_FUNC_GETMNTENTを使いましょう。
LIBSに追加します。
このマクロはobsoleteです。
getmntentを使いたいためにこのマクロを使っていたのなら、
AC_FUNC_GETMNTENTを使いましょう。
NISサポート入りのパスワード/gid系関数を使いたければ、
`AC_CHECK_LIB(sun, getpwnam)'を使いましょう。
_POSIX_SOURCEを定義し、`-posix'(GNU Cコンパイラ用)
または`-Xp'(他のCコンパイラ用)をCCに追加します。
AC_PROG_CCより後で、しかもCコンパイラを呼び出す他のマクロより先に
呼び出さねばなりません。
_MINIXと_POSIX_SOURCEを定義し、
_POSIX_1_SOURCEを2に定義します。
こうするとPOSIXの機能が使えます。
Cコンパイラを実行するマクロより前に使わないといけません。
LIBSに追加します。
このマクロはobsoleteです。
かわりにAC_FUNC_STRFTIMEを使いましょう。
LIBSに追加します。
また、`dirent.h'が使われていたら、`-ldir'を出力変数LIBSに
追加します。
このマクロはobsoleteです。
AC_HEADER_DIRENTを使いましょう。
あなたの必要としている検査項目が既存のマクロで実現されていない場合、 自分であたらしいマクロを書かねばなりません。 以下のマクロは、マクロの基本部品です 以下のマクロは、他のマクロ内でOS/コンパイラの機能を検査したり、 結果を出力したりするのに使われています。
この章では、推奨されるマクロの書き方、 それから既存のマクロがどうして現在あるように記述されているのかについて 述べています。 既存のマクロがどのように書かれているのか見ることで、 どうやってAutoconfのマクロを記述すべきか学べるでしょう。 Autoconfのテストでなにかがうまくいかなかったら、 マクロがなにを仮定しているのか理解するのに この章の内容が役立つかもしれません。 マクロが仮定していることを理解すれば、 マクロの問題点をどう解くべきなのかを知るにも役立つでしょう (訳註: 相当意訳)。
以下のマクロは、Cコンパイラの出力を調べます。 以下のマクロは結果をキャッシュしません(see section Caching Results)。 なぜなら、これらのマクロからは検査している内容がわからないし キャッシュ変数名も決められないからです。 Cコンパイラの特定の機能を調べるマクロは、結果をキャッシュしますし、 なにを調べているのかメッセージも出力されます。
複数のソフトウェアパッケージで利用できる検査を書いた場合、 新しいマクロを定義するのがよいでしょう。 どうやるかはSee section Writing Macros参照。
AC_TRY_CPPは特定のヘッダファイルが存在するか調べるためにあります。
ヘッダファイルひとつづつについて調べることもできますし、
ひとつの目的のために調べるのなら複数のヘッダファイルをまとめて
調べることもできます。
#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'されている他のヘッダファイルで
定義されているかもしれません。
egrepの正規表現です。
ヘッダファイルで定義されたり、Cプリプロセッサで前もって定義されている
Cプリプロセッサシンボルを調べる場合、
AC_EGREP_CPPを使いましょう。
以下に例題があります:
AC_EGREP_CPP(yes, [#ifdef _AIX yes #endif ], is_aix=yes, is_aix=no)
egrepの正規表現です。
このマクロは、もしまだ呼ばれていないなら、
AC_PROG_CPPまたはAC_PROG_CXXCPPを呼び出します。
どちらを呼ぶかはどちらの言語を選んでいるかに依存します
(see section Language Choice)。
「特定のキーワードを認識するかどうか」など、
C、C++やFortran 77コンパイラの文法的な機能を調べるためには、
AC_TRY_COMPILEを使ってそのキーワードや機能を使う小さなプログラムを
コンパイルしてみましょう。
AC_TRY_COMPILEを使うと、特定のシステムにしかない
構造体や構造体メンバを調べることもできます。
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 section 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 section Library Files)。
このためには、LIBに調べたいライブラリ名を一時的に追加し、
テストプログラムをリンクしてみます。
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を実行します。
もしファイルのコンパイルとリンクが成功すれば shellコマンド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 section Printing Messages)。
システムの機能に癖やバグがある場合など、 システムが実行時にどう振舞うのか知らないといけないことがあります。 可能なら、コンパイル時でなしにパッケージの実行時に検査しましょう。 例えば、マシンのendianをプログラムの初期化時に調べることは可能です。
実行時のふるまいをどうしてもパッケージのコンパイル前に調べたい場合、
テストプログラムを書き、AC_TRY_RUNを使ってコンパイルして
実行し、結果を調べることができます。
可能な限りこの種のテストプログラムを使うことは避けましょう。
あなたのパッケージをクロスコンパイルできなくなります。
システムが実行時にどう振舞うのかをコンパイル時に調べるためには、 以下のマクロを使いましょう。
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 section Manual Configuration)によって action-if-cross-compilingで決める値を変えることができます。 または、各ターゲットシステムにあわせた正しい値を書いた キャッシュファイルを置いておくこともできます(see section Caching Results)。
AC_TRY_RUNは、Autoconf標準添付のマクロを含めて
他のマクロ内部から呼び出されることがあります。
このような場合に、クロスコンパイル時のためのデフォルト値を設定するためには、
AC_TRY_RUNより前にAC_PROG_CCを呼んでおくとよいでしょう。
AC_PROG_CCを呼んだあと、shell変数cross_compileが
`yes'だったら、AC_TRY_RUNを呼ばず、
かわりの方法を使って設定結果の値を決めるのです。
テストプログラムは標準出力になにも書き出してはいけません。
テストが成功したら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*'を実行して
データファイルを消去します。
テストプログラム中の関数定義をするときは、 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などに返り値を変えて再定義してください
(訳註: 返り値の宣言変えて意味あるのか?)。
自分でテストマクロを記述する場合、
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 section `Utilities in Makefiles' in GNU Coding Standards, にあります。
この制限により、プログラム間の依存関係を最小限にとどめ、
ユーザがパッケージをインストールするために
前もって用意しないといけないプログラムを最小限に抑えることができます。
呼び出していい外部プログラムのリストに載っているプログラムについても、
最低限の共通な機能だけを使いましょう(訳註: すごく意訳)。
例えば、lnが`-f'をサポートしているとか
catにコマンドラインオプションがあるとか仮定してはいけません。
sedスクリプト内には、コメントや8文字以上のラベルがあってはいけません。
`grep -s'で出力を抑制しようとしてはいけません。
System Vでは`grep -s'は出力を抑制せず、エラーメッセージだけ
抑制するからです。
かわりに、grepの標準出力と標準エラー出力の両方を`/dev/null'に
リダイレクトしましょう
(標準エラー出力もリダイレクトするのは、エラー発生時に出力を出さないように
するためです)。
grepのexitステータスで、matchする文字列がみつかったかどうか
確認しましょう。
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}
です。
いくつかの操作には、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)
パッケージは C と C++ の両方のコンパイラを使って feature をテストする必
要があります。Autoconf が作成した configure スクリプトは、デフォ
ルトで C を調べます。`configure.in' に書く次のマクロは、どちらの言
語のコンパイラがテストで使われるかを決定します。
CC と
CPP を使ったコンパイルテストを行います。AC_PROG_CC が動作
すればその動作結果の値を、そうでない場合には
shell 変数 cross_compilingを空にします。
CXX と
CXXCPP を使ったコンパイルテストを行います。AC_PROG_CXX が動
作すればその動作結果の値を、そうでない場合には空を shell 変数
cross_compiling にセットします。
F77 を使ったコ
ンパイルテストを行います。AC_PROG_F77 が既に動作していた場合には、
AC_PROG_F77 の計算結果の値を、そうでない場合には空を shell 変数
cross_compiling にセットします。
AC_LANG_C、AC_LANG_CPLUSPLUSまたは
AC_LANG_FORTRAN77によってセットされているもの)
をスタック上に覚えます。どの言語を現在のものとしている
かは変化しません。このマクロと 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 の呼び出しよりも多くの回数呼んでは
いけません。
AC_PROG_CPP か
AC_PROG_CXXCPP を引数にして、AC_REQUIRE
(see section Prerequisite Macros) を呼んで下さい。
ひとたび configure が何か feature の存在を検知した時、その情報は
どのように記録すべきでしょうか? 記録の方法として、次の 4 つがあります :
C のプリプロセッサのシンボルを定義する、出力ファイル中の変数をセットする、
configure が走る時に使う cache ファイル中に結果を保存する、そして、
テストの結果をユーザに知らせるためにメッセージを出力する。
通常は 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 section Configuration Header Files を参照のこと。
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")
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")
テストの結果を記録する一つの方法は、output variables をセットする
ことでした。これは shell 変数であり、その値は configure が出力す
るファイルの内容を置き換えます。次の 2 つのマクロが新たな output
variables を作成します。See section Preset Output Variables には、常に出力可
能な output variables のリストがあります。
AC_OUTPUT が出力ファ
イル(通常1つかそれ以上の `Makefile' 中の変数 variable を置き換
えます。これは、AC_OUTPUT が、AC_OUTPUT の呼ばれた時に、入
力ファイル中にある `@variable@' を、shell 変数
variable の値で置き換えることを意味します。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@
いくつかの configure スクリプト(あるいは一つのスクリプト中だけで
も)で繰り返し同じ feature を調べなくても良いように、configure は
cache file 中にチェックの結果の多くを保存します。configure
を走らせた時に、cache file がみつかったらなら。そのスクリプトは結果を読
み込み、同じチェックを繰り返さないようにします。そのため、
configure は一度走らせれば、毎回全てのチェックをやり直すよりもずっ
と高速に動作します。
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 section Cache Variable Names には cache-id の変数の名前
をどのように選ぶべば良いかについて書いてあります。
AC_CACHE_VAL に対するラッパで、メッセージの出力を考慮しま
す。このマクロを使って書くのが、普通一番簡単に書ける方法です。
このマクロは、message に対して AC_MSG_CHECKING を呼
び出し、その後に cache-id と commands を引数にして
AC_CACHE_VAL を呼び出します。そして最後に cache-id を引数に
してAC_MSG_RESULT を呼びます。
AC_INITから自動的に呼ばれます。
AC_OUTPUT から自動的に呼ばれます。しかし、AC_CACHE_SAVE を
configure.in 中の鍵となる地点で呼びことはなかな利用できます。configure
のスクリプトが早い段階で異常終了するような場合にこれをチェックポイントと
して使えます。
キャッシュ変数名は以下のフォーマットにするべきです:
package-prefix_cv_value-type_specific-value[_additional-options]
たとえば、`ac_cv_header_stat_broken'とか、 `ac_cv_prog_gcc_traditional'などのようになります。 変数名の各部分の意味は以下のとおり:
_cv_
cache 変数として割り当てられる変数は改行を含んではいけません。通常、それ らの値は boolean (`yes' または `no') となるか、ファイルや関数 の名前になるでしょう。そのため、この制限はきついものではありません。
キャッシュファイルは、あるシステム上で実行されたconfigureのテスト結果を 蓄えるshellスクリプトです。これにより、configureスクリプト間、 または複数回のconfigureの実行の間でテスト結果を共有できます。 異なるシステム上ではキャッシュファイルは役にたちません。 もしキャッシュファイルの内容がなんらかの理由で不正になった場合、 ユーザはキャッシュファイルを削除したり編集したりできます。
デフォルトでは、configureは`./config.cache'をキャッシュファイルとして
使います。もしなければ新規に作成されます。configureは
キャッシュファイルの切替えのため、`--cache-file=file'という
オプションを受け付けます; configureがサブディレクトリにある
configureスクリプトを呼び出す際には、このオプションを使って
スクリプト間でキャッシュを共有します。
AC_CONFIG_SUBDIRSマクロを使ってサブディレクトリの設定を
する方法については、See section Configuring Other Packages in 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 section Manual Configuration 参照)。この方法は標準化されています。
あるシステム向けのキャッシュファイルは、configureスクリプトを
実行するごとに内容が追加されていきます; 初期状態では空です。
configureを実行すると、configureは新しいテスト結果と
キャッシュファイルの内容をマージします。サイト向け初期化スクリプトの中で、
デフォルトで利用されるものでない、サイト単位のキャッシュファイルを
指定することができます。サイト単位のキャッシュファイルは、
同じCコンパイラが利用されている限り、透過的に働きます
(see section Setting 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)
configureスクリプトは、configureを実行しているユーザに
各種の情報を知らせる必要があります。以下のマクロは各種の状況に適した方法で
メッセージを出力します。以下の全てのマクロの引数は、shell用に
ダブルクォートで囲まれます。このため、shellは変数とbackquoteの置換を
行います。カンマを含むメッセージは、m4のquote文字である角括弧で
メッセージを囲めば出力できます。
AC_MSG_RESULT([never mind, I found the BASIC compiler])
これらのマクロはshellコマンドのechoのwarpperです。
configureスクリプトでは、ほとんどの場合
ユーザにメッセージを出力するのにechoを直接使う必要はありません。
ここで挙げたマクロを使えば、メッセージの出力時期と出力のされかたを
簡単に変えることができます。メッセージ出力マクロの定義を変えれば、
全ての呼び出し側マクロの出力を変えられます。
configureが、ある特定のOS機能をチェックしていることをユーザに
知らせます。このマクロは`checking 'ではじまり、`...'で終る、
改行なしのメッセージを出力します。このマクロの後にはAC_MSG_RESULTを
呼び出し、チェック結果と改行を出力する必要があります。
feature-descriptionはたとえば
`whether the Fortran compiler accepts C++ comments'とか、
`for c89'とかがよいでしょう。
このマクロはconfigureが`--quiet'オプション、または
`--silent'オプションつきで実行された場合、なにも出力しません。
AC_MSG_CHECKINGに続いて
呼び出される必要があります。また、result-descriptionに
指定するメッセージはAC_MSG_CHECKINGの出力したメッセージを
終結させるさせるものでなければなりません。
このマクロはconfigureが`--quiet'オプション、または
`--silent'オプションつきで実行された場合、なにも出力しません。
configureが中断してしまうようなエラーに関して知らせます。
このマクロは標準エラー出力にエラーメッセージを出力し、
configureを終了します。exit statusは0でない値になります。
error-descriptionはたとえば`invalid value $HOME for \$HOME'
などのようなテキストがいいでしょう。
configureのユーザに問題になり得る点を知らせます。
このマクロは標準エラー出力にメッセージを出力します;
configureは以後も実行を続けます。
ので、AC_MSG_WARNを呼び出すマクロは、
警告する内容に関して、デフォルトの(代用の)ふるまいを
提供するべきです。problem-descriptionはたとえば
`ln -s seems to make hard links'のようなテキストがいいでしょう。
以下のふたつのマクロはobsoleteです。
AC_MSG_CHECKINGやAC_MSG_RESULTを使いましょう。
AC_MSG_CHECKINGと似ていますが、AC_CHECKINGは
feature-descriptionのあとに改行を出力します。
このマクロは主に、複数並んだOS機能チェックの全体としての目的を
出力するのに使えます。たとえば:
AC_CHECKING(if stack overflow is detectable)
AC_MSG_RESULTと似ています。
ただし、AC_VERBOSEはAC_MSG_CHECKINGではなく、
AC_CHECKINGに続いて呼び出される、という点だけが違います。
メッセージはtabに続いて出力されます。
このマクロはobsoleteです。
複数のソフトウェアパッケージに適用できるOS機能のテストマクロを記述 する場合、新しいマクロとして定義するのが最もよい方法です。 以下ではAutoconfマクロを記述するための手順とガイドラインを示します。
AutoconfのマクロはAC_DEFUNマクロを使って定義されます。
これはm4のdefineマクロと類似しています。
AC_DEFUNはマクロを定義する際に、マクロの呼び出し順を
制約するためのコードを加えます(see section Prerequisite Macros参照)。
Autoconfマクロの定義は以下のようになります:
AC_DEFUN(macro-name, [macro-body])
角括弧はオプショナルという意味ではありません; 角括弧はマクロ展開の 問題を避けるため、実際に字面の上でもマクロ定義に記述される必要があります (see section Quoting参照)。マクロに渡される引数は、`$1'や`$2'として 参照できます。
m4プログラム内にコメントを記述するためには、m4組み込みの
dnlを使ってください; これはm4に次の改行までのテキストを
無視させます。`acsite.m4'と`aclocal.m4'の中のマクロ定義の間には
dnlは必要ありません。AC_INITが呼び出されるまでの出力は
無視されるからです。
See section `How to define new macros' in GNU m4, for
more complete information on writing m4 macros.
Autoconfマクロの名前は、他の文字列との衝突を避けるため、 全て大文字で、`AC_'で始まっています。内部で使われるshell変数は なるべく全部小文字で、`ac_'で始まっています。 既存の/将来のAutoconfマクロと衝突しないために、 自分で定義するマクロの名前およびshell変数の名前には、 先頭に別の文字列を使うべきです。例えばあなたのイニシャル、組織名や ソフトウェアパッケージの名前の略称などが考えられます。
Autoconfマクロの名前は、ほとんどの場合構造化された名前づけ規則に したがっています。名前はチェックされるOSの機能を示しています。 マクロ名は下線で区切られたいくつかの単語からなり、各単語は 一般的なものから特殊なものへと並んでいます。マクロに対する キャッシュ変数の名前もおなじ規則を使っています(より詳しくは see section Cache Variable Names参照)。
`AC_'の次にある単語は、調べる対象のOS機能のカテゴリを示しています。 ここでは、特定のテストのマクロや、あなたが書こうと思うようなマクロのため に Autoconf が使用するカテゴリを示します。また、cache 変数も、全て小文字 でこの名前を利用します。この名前の規則が適用可能だと思ったらどこでもこれ らを使って下さい。もし適用できないようであれば、自分自身のカテゴリを発明 することです。
C
DECL
FUNC
GROUP
HEADER
LIB
PATH
PROG
STRUCT
SYS
TYPE
VAR
カテゴリ名の次には、テスト対象のOS機能の名前が来ます。
それ以降の単語はそれぞれOSの機能の持つ特定の意味を表しています。
例えば、AC_FUNC_UTIME_NULLはutime関数の引数に
NULLを与えたときのふるまいをチェックします。
あるマクロの内部サブルーチンとして動作するマクロには、
呼び元マクロ名のあとに、マクロが行うことがらを意味する
ひとつ以上の単語をつけた名前をつけるのがよいです。
たとえば、AC_PATH_XはAC_PATH_X_XMKMFと
AC_PATH_X_DIRECTを内部で呼び出すマクロとして使います。
他のマクロに呼び出されるマクロは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'を実行します。
Autoconfマクロの一部は、正常な動作のために他のマクロが先に呼ばれていることを 仮定しています。Autoconfは特定のマクロを必要な場合にだけ呼び出したり、 正常に動作しない可能性のある順でマクロが呼び出された場合に 警告したりする方法を提供しています。
一部のマクロは、他のマクロで求められた値を必要とすることがあります。
例えば、AC_DECL_YYTEXTはflexやlexの出力
結果を調べます。このため、shell変数LEXを設定するために
AC_PROG_LEXマクロが先に呼ばれている必要があります。
AC_REQUIREマクロを使う事で、ユーザにマクロ間の依存関係を
管理させずに済みます。つまり、自動化できます。AC_REQUIREを
使うと、あるマクロを必要な場合にだけ、かつ1度だけ呼び出すことができます。
m4マクロが
まだ呼び出されていなかったら、そのマクロを
(引数なしで)呼び出します。macro-nameを
角カッコでquoteするのを忘れないでください。
macro-nameに指定されるマクロは
AC_DEFUNで前もって定義されているか、
AC_PROVIDEの呼び出しを含んでいるかする
必要があります。これはmacro-nameが
呼び出されたことを検出するため必要です。
AC_DEFUNを使うかわりに、defineを使ってマクロを定義し、
中でAC_PROVIDEを呼び出すこともできます。この技法は
メッセージのネストを防ぐ事ができないので、obsoleteです。
AC_PROVIDE
マクロを呼び出すマクロの名前でなければなりません
m4の組み込み変数$0を使うと簡単に
マクロの名前を得る事ができます。たとえばこんな風:
AC_PROVIDE([$0])
あるふたつのマクロについて、両方が呼び出される場合には片方が先に 呼び出されなければならないが、どちらも他方が呼び出されることを 必須としない場合があります。たとえば、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が
既に呼ばれていた場合、ユーザに警告がでます。
m4が標準エラー出力に警告メッセージを
出力するようにします。this-macro-nameは
マクロAC_BEFOREを呼び出すマクロの名前である
必要があります。called-macro-nameに
指定されるマクロはAC_DEFUNで前もって
定義されているか、AC_PROVIDEの呼び出しを
含んでいるかする必要があります。これは
called-macro-nameが呼び出されたことを
検出するため必要です。
自動設定および移植性向上のための技法は数年かけて徐々に進化しています。
しばしば、ある問題を解決するためのよりよい方法が開発されたり、
やっつけ仕事が系統だてて整理されたりします。このような変化は
Autoconfの多くの部分で置きました。この結果、一部のマクロは
obsoleteとされるようになりました; それらのマクロは
動作はしますが、最適なやりかたではなくなりました。
AutoconfはAC_OBSOLETEマクロを用意しています。
このマクロは、configureスクリプトを作っているユーザが
obsoleteなマクロを使用した場合に警告し、あたらしいマクロに
移行するよう勧めます。使用例はこんなかんじ:
AC_OBSOLETE([$0], [; use AC_CHECK_HEADERS(unistd.h) instead])dnl
m4から標準エラー出力へ、マクロ
this-macro-nameはobsoleteだ、という
メッセージを出力させます。また、マクロが
使用されたファイル名と行番号も
出力されます。this-macro-nameは
AC_OBSOLETEを呼び出しているマクロの
名前である必要があります。もしsuggestionが
指定されていたら、警告メッセージの末尾に
指定された文字列が出力されます;
例えば、this-macro-nameのかわりに
使うべきマクロ名などがいいでしょう。
一部のOS機能は、テストプログラムを実行しても自動的に判定できません。
たとえば、オブジェクトファイルのフォーマットや、コンパイラや
リンカに渡さねばならない特殊なオプションなどがそうです。
unameの出力結果を調べたり、特定のシステムにしかない
ライブラリを調べるなどのアドホックな手段を使って、
このようなOSの機能をチェックすることができます。
Autoconfは推測することのできないOS機能の判定のために、
統一された方法を提供しています。
他の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というスクリプトを
実行します。
以下のマクロを使うと、configureスクリプトの中でシステムタイプを
知ることができます。これらのマクロはconfig.guessというshell
スクリプトを実行します。これにより、ユーザが指定しなかった、host/
target/buildシステムタイプ名などの情報を得ます。また、config.subを
実行することでユーザの指定したシステムタイプの別名を正規化します。
以下のマクロを利用する場合、これら2つのshellスクリプトをソースコードと
ともに配布する必要があります。configureがこれらの
スクリプトを探すディレクトリを指定するためのマクロ、
AC_CONFIG_AUX_DIRについてはSee section Creating Output Files参照。
以下のマクロを利用しなかった場合、configureは
指定された`--host'、`--target'および`--build'の
オプションを無視します。
AC_CANONICAL_SYSTEMの一部、ホストタイプに関する
部分だけを実行します。プログラムがコンパイラ関連の
ツールでなければ、このマクロのやることだけでことが足ります。
AC_CANONICAL_SYSTEMを呼び出すと、以下の出力変数に
システムタイプの情報が設定されます。AC_CANONICAL_HOSTの
実行語は、変数hostだけが設定されます。
build, host, targetbuild_alias, host_alias, target_aliasconfig.guessが
使われた場合には正規化されたシステム名;
build_cpu, build_vendor, build_oshost_cpu, host_vendor, host_ostarget_cpu, target_vendor, target_os
正規化されたシステムタイプをどう使いますか? たいていは、システム依存の
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
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 section Generic Program and File Checks参照。
configureスクリプトでは、パッケージがインストールされる場面ごとに
設定の一部を変えるための機能を備えています(訳註: 意訳)。
外部プログラムパッケージの置かれている場所を指定したり、
オプションの機能を含めたり外したり、プログラムを
デフォルトの名前以外でインストールしたり、
configureのオプションの既定値を定めたりするための方法が
用意されています。
ソフトウェアパッケージが他のソフトウェアパッケージを必要としたり、
あるいは特定の場合だけ利用したりすることがあります。
ユーザは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'を書くあなたまかせです。
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文字は使わないでください。 行の先頭にスペースを含めるためには、`['と`]'でくくる 必要があるでしょう。
AC_ARG_WITHの古いバージョンです。
help-stringが使えません。
ソフトウェアパッケージに
コンパイル時に使うかどうか選べる機能拡張がある場合、
ユーザは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'の作者の自由です。
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 section Working With External Software)で使われる
help-stringと同じです。
AC_ARG_ENABLEからhelp-stringのサポートを外したようなものです。
一部のソフトウェアパッケージは、インストールするサイト依存の情報を 必要とします。 例えば、ある種のサービスにはホスト名が必要です。 コンタクト先として会社名やemailアドレスを使うこともあります。 Metaconfigで生成された設定スクリプトは対話的にこのような情報を 問い合わせます。 Autoconfで生成された設定スクリプトは対話的ではないので、 Autoconfで生成された設定スクリプトではどうやればいいのだろう、と思うでしょう。
このようなサイト依存の設定情報は、プログラムが編集したものではなく、
ユーザだけによって編集されたファイルに格納されている必要があります。
ファイルを置く位置はprefix変数をもとにしたパス、または
ユーザのホームディレクトリなどの標準的な場所にします。
ファイルを置く位置を環境変数で設定してもよいでしょう。
プログラムはコンパイル時でなく実行時に、そのファイルを調べます。
このようなサイト依存の設定情報は、プログラムが編集したものではなく、
ユーザだけによって編集されたファイルに格納されている必要があります。
ファイルを置く位置はprefix変数をもとにしたパス、または
ユーザのホームディレクトリなどの標準的な場所にします。
ファイルを置く位置を環境変数で設定してもよいでしょう。
プログラムはコンパイル時でなく実行時に、そのファイルを調べます。
実行時の設定は、ユーザにとって便利であり、configure を動かして設定時の情
報を取得するよりもより簡単にすみます。See section `Variables for Installation Directories' in GNU Coding Standards, には、データファイルをどこに置くかについての詳細があります。
Autoconf にはインストール時にプログラムの名前を変更することについてのサ
ポートがあります。これらの変更機能を利用するには、`configure.in' か
らマクロ AC_ARG_PROGRAM を呼び出さねばなりません。
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 という名前になるとい
う意味でしょう)。そうでない場合には、プログラム名の変更はありません。
名前の変更を指示するために、configure に次のコマンドラインオプショ
ンを指定することができます。
--program-prefix=prefix
--program-suffix=suffix
--program-transform-name=expression
sed の置換式(expression)を作用させます。
これらの変換はクロスコンパイルの開発環境におけるプログラムに対して使うと 効果的です。たとえば、`--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', などのようにインストールすることがで きます。
ここでは `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 ページの名前
は変更することが良いでしょう。
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
configure Scripts
以下では、configureスクリプトを使ったパッケージをどうやって
自動設定するかを述べます。以下のテキストは、パッケージに添付する
`INSTALL'ファイルとしても使えます。配布可能なプレーンテキスト版の
`INSTALL'はAutoconfパッケージに含まれています。
These are generic installation instructions.
The configure shell script attempts to guess correct values for
various system-dependent variables used during compilation. It uses
those values to create a `Makefile' in each directory of the
package. It may also create one or more `.h' files containing
system-dependent definitions. Finally, it creates a shell script
`config.status' that you can run in the future to recreate the
current configuration, a file `config.cache' that saves the results
of its tests to speed up reconfiguring, and a file `config.log'
containing compiler output (useful mainly for debugging
configure).
If you need to do unusual things to compile the package, please try to
figure out how configure could check whether to do them, and mail
diffs or instructions to the address given in the `README' so they
can be considered for the next release. If at some point
`config.cache' contains results you don't want to keep, you may
remove or edit it.
The file `configure.in' is used to create `configure' by a
program called autoconf. You only need `configure.in' if
you want to change it or regenerate `configure' using a newer
version of autoconf.
The simplest way to compile this package is:
cd to the directory containing the package's source code and type
`./configure' to configure the package for your system. If you're
using csh on an old version of System V, you might need to type
`sh ./configure' instead to prevent csh from trying to
execute configure itself.
Running configure takes awhile. While running, it prints some
messages telling which features it is checking for.
configure created (so you can compile the package for a different
kind of computer), type `make distclean'. There is also a
`make maintainer-clean' target, but that is intended mainly for the
package's developers. If you use it, you may have to get all sorts of
other programs in order to regenerate files that came with the distribution.
Some systems require unusual options for compilation or linking that
the configure script does not know about. You can give
configure initial values for variables by setting them in the
environment. Using a Bourne-compatible shell, you can do that on the
command line like this:
CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
Or on systems that have the env program, you can do it like this:
env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
You can compile the package for more than one kind of computer at the
same time, by placing the object files for each architecture in their
own directory. To do this, you must use a version of make that
supports the VPATH variable, such as GNU make. cd
to the directory where you want the object files and executables to go
and run the configure script. configure automatically
checks for the source code in the directory that configure is in
and in `..'.
If you have to use a make that does not supports the VPATH
variable, you have to compile the package for one architecture at a time
in the source code directory. After you have installed the package for
one architecture, use `make distclean' before reconfiguring for
another architecture.
By default, `make install' will install the package's files in
`/usr/local/bin', `/usr/local/man', etc. You can specify an
installation prefix other than `/usr/local' by giving
configure the option `--prefix=path'.
You can specify separate installation prefixes for architecture-specific
files and architecture-independent files. If you give configure
the option `--exec-prefix=path', the package will use
path as the prefix for installing programs and libraries.
Documentation and other data files will still use the regular prefix.
In addition, if you use an unusual directory layout you can give options like `--bindir=path' to specify different values for particular kinds of files. Run `configure --help' for a list of the directories you can set and what kinds of files go in them.
If the package supports it, you can cause programs to be installed with
an extra prefix or suffix on their names by giving configure the
option `--program-prefix=PREFIX' or
`--program-suffix=SUFFIX'.
Some packages pay attention to `--enable-feature' options to
configure, where feature indicates an optional part of the
package. They may also pay attention to `--with-package'
options, where package is something like `gnu-as' or `x'
(for the X Window System). The `README' should mention any
`--enable-' and `--with-' options that the package recognizes.
For packages that use the X Window System, configure can usually
find the X include and library files automatically, but if it doesn't,
you can use the configure options `--x-includes=dir'
and `--x-libraries=dir' to specify their locations.
There may be some features configure can not figure out
automatically, but needs to determine by the type of host the package
will run on. Usually configure can figure that out, but if it
prints a message saying it can not guess the host type, give it the
`--host=type' option. type can either be a short name
for the system type, such as `sun4', or a canonical name with three
fields:
cpu-company-system
See the file `config.sub' for the possible values of each field. If `config.sub' isn't included in this package, then this package doesn't need to know the host type.
If you are building compiler tools for cross-compiling, you can also use the `--target=type' option to select the type of system they will produce code for and the `--build=type' option to select the type of system on which you are compiling the package.
If you want to set default values for configure scripts to share,
you can create a site shell script called `config.site' that gives
default values for variables like CC, cache_file, and
prefix. configure looks for
`prefix/share/config.site' if it exists, then
`prefix/etc/config.site' if it exists. Or, you can set
the CONFIG_SITE environment variable to the location of the site
script. A warning: not all configure scripts look for a site script.
configure recognizes the following options to control how it
operates.
--cache-file=file
configure.
--help
configure, and exit.
--quiet
--silent
-q
--srcdir=dir
configure can determine that directory automatically.
--version
configure
script, and exit.
configure also accepts some other, not widely useful, options.
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 section Automatic Remaking参照)
`config.status'は`--help'と`--version'のふたつの
オプションも受け付けます。
`--help'をつけると、`config.status'のオプションの
概説を出力します。`--version'をつけると、Autoconfの
バージョンと、config.statusを作るときに使われた
configureのオプションを出力します。
`config.status'は、いくつかの環境変数を参照して動作を変更します:
configureを実行する際に、
使うべきshellを指定します。Bourne shell互換である必要があります。
デフォルトは`/bin/sh'です。
configureスクリプトを
統合できない場合などに役立ちます。
以下の環境変数を使うことで、別々に配布されるパッケージが
configureで求めたテスト結果を共有することができます。
あるパッケージが他のパッケージ(たとえば共有ライブラリ)の必要とする
OS機能のsupersetを要求している場合に役立ちます。
以下の環境変数を使うと、`config.status'に`configure.in'で
指定された以外のファイルを生成させることができます。
このため、生成されたファイルを他のパッケージから使うことができるのです。
AC_OUTPUTに与えられた引数です。
#defineディレクティブの置換を行うべきファイル名。
デフォルトはAC_CONFIG_HEADERに与えられた引数です。
AC_CONFIG_HEADERマクロが使われていない場合、
`config.status'はこれを無視します。
上記の環境変数を使うことで、一部のファイルだけを再生成するような `Makefile'のルールを記述することができます。 例えば、see section 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を指定する必要はありません)
Autoconfに関しては、いくつかの質問が頻繁に出ます。 それらのいくつかにお答えしましょう。
configure ScriptsAutoconfが生成した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コンソーシアムによるもので、
著作権は放棄されています。
m4?
なんでAutoconfはGNU m4を必要とするんですか?
多くのm4の実装では、マクロの大きさや数に決め打ちの制限があって、
Autoconfはそれをオーバしてしまいます。また、いくつかの組み込みマクロが
不足している場合があり、それらのマクロなしではAutoconfのような
洗練されたアプリケーションは記述しづらくなります。たとえばこんな
マクロがない場合があります:
builtin indir patsubst __file__ __line__
ソフトウェアの管理者はAutoconfだけを使えばよいし、GNU m4は
設定やインストールが簡単です。このため、GNU m4がインストール
されていないといけない、というのは妥当と思われます。
GNUやGNU以外のフリーソフトウェアの管理者にはGNUユーティリティの
多くをインストールしている人がたくさんいます。なぜなら
彼らはGNUユーティリティが気に入っているからです。
AutoconfがGNUm4を必要としていて、GNUm4パッケージがAutoconfで 生成されたconfigureスクリプトを含んでいたら、どこから仕事をはじめたら いいんですか? 鶏と卵問題になりませんか?
それは誤解です。
確かに、GNU m4パッケージはAutoconfで生成された
configureスクリプトを含んでいます。
しかし、configureスクリプトを実行したり
GNU m4パッケージをインストールしたりするのに
Autoconfは必要ありません。
Autoconfはm4パッケージに含まれるconfigureスクリプトを
変更したい場合にだけ必要です。
ふつう、そのような変更はごく少数のひと(主にm4パッケージの
メインテナ)しか行いません。
なんで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 のセットアップ中に含まれるようなものの
ような、多くの共通事項を複製する必要がないことを意味します。
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の実装がより効率的になり、
内部状態をファイルに保存することができるため高速に再呼び出しが可能です。
もし、(特定のパッケージのソースディレクトリに置いてあるのではなくて)
Autoconfと一緒に`aclocal.m4'がインストールされていたら
ファイル名を`acsite.m4'に変更する必要があります。
See section Using autoconf to Create configure
`install.sh'をパッケージと一緒に配布する場合、
ファイル名を`install-sh'にしてください。
これは、makeの組み込みルールが勝手に`install'
というファイルを生成してしまうのを防ぐためです。
AC_PROG_INSTALLは両方のファイル名を調べますが、
新しい名前を使う方が望ましいです。
`config.h.top'または`config.h.bot'を使っている場合、
そのまま使い続けることができます。可能なら`acconfig.h'に
取り込んだ方がファイルがごみごみしなくていいでしょう。
See section Using autoheader to Create `config.h.in'
`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@
`@'が前後についていない変数を書き換えるふるまいは 削除されました。
多くのマクロがAutoconfバージョン2で改名されました。
古い名前を使うこともできますが、新しいものの方がわかりやすく、
ドキュメントとの対応もとれていて探しやすいです。
新しい名前と古い名前の対応表はSee section Old Macro Namesを参照してください。
autoupdateを使うと、古いマクロ名を含む`configure.in'を
新しいマクロ名を使うように変換できます。See section Using autoupdate to Modernize configure参照。
いくつかのマクロはよりうまく働く類似のマクロで置き換えられましたが、
呼び出し方法が互換でないものがあります。
autoconfを呼び出した際にobsoleteなマクロを呼び出している
旨警告が表示された場合、警告を無視することもできます。
しかし、警告に従って書き換えを行った方が生成される
configureスクリプトはうまく動作します。
特に、テストの結果を表示するメカニズムが変更されています。
echoや(AC_COMPILE_CHECK経由での)AC_VERBOSEなどを
使っている場合には、AC_MSG_CHECKINGとAC_MSG_RESULTに
移行した方がconfigureの出力がうまく見えます。
See section Printing Messagesを参照のこと。
これらのマクロはキャッシュとともに使うと最もうまく動きます。
See section Caching Results参照。
autoupdate to Modernize configure
autoupdateはAutoconfマクロを古い名前で呼び出している
`configure.in'を、現在のマクロ名で呼び出すように変換する
プログラムです。
Autoconfのバージョン2では、多くのマクロが統一的でわかりやすい
命名規則に従うよう改名されました。
新しい命名規則についてはSee section Macro Namesを参照。
古い名前を使うこともできますが、新しいものに移行した使った方が
`configure.in'が読みやすいですし、現在のAutoconfのドキュメントとの
対応もとれていて探しやすいです。
(新しい名前と古い名前の対応表はSee section Old Macro Namesを参照)
引数なしで呼ばれた場合、autoupdateは`configure.in'を
更新します。その際、もとのファイルはファイル名に`~'
(または環境変数SIMPLE_BACKUP_SUFFIXの内容)を追加したファイル名で
保存されます。autoupdateに引数を与えた場合、
`configure.in'のかわりにそのファイルを読み込んで標準出力に
結果を書き出します。
autoupdateは以下のオプションを受け付けます:
--help
-h
--macrodir=dir
-m dir
AC_MACRODIRに
設定しても変えられます。
オプションは環境変数より優先されます。
--version
autoupdateのバージョン番号を表示して終了します。
shell変数DEFSの値を調べることで以前のテスト結果を参照
している場合、テスト結果のキャッシュをしているshell変数を
調べるように変更する必要があります。
DEFSは出力ファイル生成時に設定されるようになったので、
configure実行中には存在しないようになりました。
バージョン1からの変更は、shell変数DEFSの
設定のたび、つまりAC_DEFINEを呼ぶたびに
正しく内容をquoteするのが面倒で非効率的であったことによります。
See section 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 section Setting Output Variables参照。
Autoconfマクロによって設定されるshell変数で真偽値をとるものは、 「真」の場合`yes'に設定されるようになりました。 マクロの多くは「偽」の場合`no'を使いますが、 バックワードコンパチビリティのために空文字列を使うものもあります。 shell変数が1とか`t'とかに設定されることを仮定している場合、 スクリプトを変更する必要があります。
自分でマクロを定義する場合、defineのかわりにAC_DEFUN
を使わねばならないようになりました。AC_DEFUNは自動的に
AC_PROVIDEを呼び出します。
これにより、AC_REQUIREに呼ばれたマクロが他のマクロを邪魔
しないようなり、`checking...'というメッセージがダブって
表示されるのを防止できます。古い方法でマクロを定義しても
実害はありませんが、不便ですしかっこわるいです。
See section Macro Definitions参照。
マクロを定義するために、Autoconfについてきたマクロの定義を 読んでらっしゃるのではないかと思います。新しいバージョンの マクロ定義を読むのはいいことだと思います。書き方が わかりやすくなっていますし、新しい機能も活用しています。
ドキュメントに書かれていないAutoconfの内部構造(マクロ、変数や 実装上の抜け道)を使ってトリッキーなことをしている場合、バージョンの 違いによる変化に影響されていないかをチェックしてください。 もしかしたら、ずるをしないでもバージョン2で用意されているやりかたで 同じ事ができるかもしれません。できないかもしれませんけど。
自分で記述したテストを高速にするために、キャッシュを使いましょう。 あなたの記述したテストが、汎用的なマクロとして一般化できるかどうか 考えましょう。
おそらくあなたは、なぜ Autoconf が書かれたのかということに興味があるでしょ う。いかにしてそれが現在の形となったのか? (どうしてそれがゴリラのツバの ようにばっちいのか?) そう思わないのでしたら、この章は無意味 なので飛ばした方が良いでしょう。もし、興味があるならば、見ていく ことにしましょう...
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' ファイルを生成した。
ユーザからのフィードバックをもらうに従い、私は多くの改良を加えた。しかし
それは、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 を使っていた。そ
のため私には新しい言語に挑戦するという楽しみもあった。
私の configure スクリプトは、ユーザの介在なしにシステムの能力を自
動的に決定するものであったので、私はこのプログラムを Autoconfig と呼んで
いた。しかし、バージョン番号を上がっていくと、この名前は古い UNIX のファ
イルシステムにとっては長くなりすぎたので、短い名前にして Autoconf とした。
1991 年の秋に、ポータビリティの Holy Grail の後に、私と探索者の仲間達(ま
あ、つまり alpha テスタ達のこと)が私が手で書いたスクリプトのかけらを
m4 マクロ中にカプセル化したり、feature を加えたり、チェックの利用
を改良するというようなフィードバックを行なってくれた。そのテスタたちの中
でも突出していたのが
Pinard である。彼は m4 を走らせ、`autoconf' shell スクリプト
を作成し、未解決のマクロの呼び出しを調べるという考えを持っていた。
Richard Pixley はより正確な結果を得るため、ファイルとシンボルをファイル
システム上で探すかわりにコンパイラを動かすことを提案した。Karl Berry は、
TeX を設定するための Autoconf を得て、ドキュメントにマクロインデック
スを追加した。Ian Taylor は彼の UUCP パッケージを Autoconf で利用するた
め、`Makefile' 中の `-D' オプションを置くかわりに C のヘッダファ
イルを生成するというサポートを加えた。alpha テスター達は Autoconf マクロ
の名前や呼び出し規約がリリースごとに変化したが、彼らのファイルを快く書き
直してくれた。彼ら全ては、多くのチェックやすばらしいアイデア、そしてバグ
の修正への貢献者である。
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++ のサポートに貢献した。
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 月にかけて私が病気の間にポータビリティの問題を
扱ってくれた。
長い、主な 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 を使うことで容易に変換でき
るよう、いくつかの補助的なユーティリティを加えた。これには、
Pinard の助けを借り、互いに他のメッセージを中断しないようなマクロを作成
した(その feature は GNU m4 におけるある性能上のボトルネックを
あらわにしました。彼はただちにそのボトルネックを修正した！)。 私はドキュメ
ント周りの問題で人々が望んでいるものを再構成した。そしてまずテストスイー
トを作成しはじめた。これはこれまでの経験から Autoconf は我々が変更しよう
とすると後戻りする傾向があると指摘されるためである。
重ねて申し上げるが、幾人かの alpha テスタからははかり知れない価値を持つ フィードバックを頂いた。特に Pinard, Jim Meyering, Karl Berry, Rob Savoye, Ken Raeburn, Mark Eichin に感謝する。
既に、version 2.0 の準備はできています。これは非常な喜びです(そして私 にはまた自由な時間ができました。多分……。そうです。確かに)。
Autoconfのバージョン2では、多くのマクロが統一的でわかりやすい 命名規則に従うよう改名されました。
以下は、改名されたマクロの古い名前と現在の名前のリストです。
バックワードコンパチビリティのためにautoconfは
古い名前を受け付けますが、古い名前はobsoleteです。
新しい命名規則についてはSee section 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
以下は、Autoconfが参照する環境変数の名前を、アルファベット順に 並べたリストです。
以下はAutoconfが(`Makefile'などの)出力ファイルを作成する際に、 置換を行う変数名のアルファベット順リストです。 置換動作に関してはSee section Setting Output Variablesを参照。
Jump to: a - b - c - d - e - f - h - i - k - l - m - n - o - p - r - s - t - x - y
以下は、Autoconfマクロが定義するCプリプロセッサシンボルの
アルファベット順リストです。
Autoconfを利用する場合、Cソースコード中の#ifディレクティブで
以下のシンボルを使う必要があります。
Jump to: _ - c - d - f - g - h - i - l - m - n - o - p - r - s - t - u - v - w - y
以下は、Autoconfマクロのアルファベット順リストです。 リストを使いやすくするため、マクロ名先頭の`AC_'は除いてあります。
Jump to: a - b - c - d - e - f - g - h - i - l - m - o - p - r - s - t - u - v - w - x - y
This document was generated on 12 November 1999 using the texi2html translator version 1.52.