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)