| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
一度configureで特徴の存在を定義すると，その情報を記録するため
に何ができるのでしょうか？そうする方法は四種類あります．Cプリプロセッサ
シンボルの定義，出力ファイルで変数を設定，configure実行時のキャッ
シュファイルに結果を保存，そして，テスト結果をユーザに知らせるメッセージ
の出力です．
| 7.1 Cプリプロセッサシンボルの定義 | Defining C preprocessor symbols | |
| 7.2 出力変数の設定 | Replacing variables in output files | |
| 7.3 結果のキャッシュ | Speeding up subsequent configure runs
| |
| 7.4 メッセージの出力 | Notifying configure users
|
特徴テストからの応答を受けとる通常の動作は，テストの結果を示すCプリプロ
セッサシンボルを定義することです．それはAC_DEFINEや
AC_DEFINE_UNQUOTEDと呼ばれるもので行います．
デフォルトで，AC_OUTPUTはマクロが定義したシンボルを，出力変数
DEFSに配置し，それはそれぞれのシンボルに対する
`-Dsymbol=value'を含んでいます．Autoconfバージョン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_HEADERSが呼び出された場合，DEFSを作成する代わり
に，AC_OUTPUTでテンプレートファイルに#define文で正しい値を
代入したヘッダファイルを作成します．この種類の出力の詳細は，
See section コンフィグレーションヘッダファイル.
Cプリプロセッサ変数variableをvalueに(そのまま)定義します．
valueは改行のリテラルを含むべきではなく， AC_CONFIG_HEADERS
を使用しない場合，makeが処理してしまうので，`#'文字を含め
るべきではありません．シェル変数(M4の引用符文字`['や`]'を含む
定義値が必要なもの)を使用するために，代わりにAC_DEFINE_UNQUOTEDを
使用してください．descriptionは， AC_CONFIG_HEADERを使用す
る場合だけ役に立ちます．この場合， descriptionは，生成された
`config.h.in'に，マクロ定義前のコメントとして書き込まれます．以下の
例は，Cプリプロセッサ変数EQUATION を文字定数`"$a > $b"'と定
義します．
AC_DEFINE(EQUATION, "$a > $b") |
valueもdescriptionも与えられていない場合，valueのデフォ ルトは空の文字列ではなく1になります．これは古いバージョンのAutoconfの下 位互換性のためですが，この使用方法は時代遅れで，Autoconfの将来のバージョ ンでは無くなるかもしれません．
AC_DEFINEに似ていますが，variableとvalueで，三つのシェ
ル展開が -- 一度に -- 実行されます．変数の展開(`$')，コマンドの置
換(``')，そしてバックスラッシュエスケープ(`\')です．値の中のシ
ングルクオートとダブルクオートの文字列，特別な意味を持ちません．
variableや valueがシェル変数のときは，AC_DEFINEの代わ
りにこのマクロを使用してください．以下がその例です．
AC_DEFINE_UNQUOTED(config_machfile, "$machfile") AC_DEFINE_UNQUOTED(GETGROUPS_T, $ac_cv_type_getgroups) AC_DEFINE_UNQUOTED($ac_tr_hdr) |
Bourneシェルの構文の特異性のため，他のマクロから呼び出しやシェルコードと
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)
を設定することで，それは，configureが出力したファイルの中に，
シェル変数の値を代入することです．以下の二つのマクロで新しい出力変数を作
ります．利用可能な出力変数のリストは，See section 出力変数のプリセット.
シェル変数から出力変数を作成します．AC_OUTPUTは，出力ファイルの変
数variableに代入します(通常，一つ以上の`Makefile'です)．これ
は，AC_OUTPUTが呼び出されたとき，入力ファイルの
`@variable@'のインスタンスをシェル変数variableが持つ
値でAC_OUTPUTが置換することを意味します．variableのこの値は
改行のリテラルを含むべきではありません．
valueが与えられている場合，さらにそれもvariableに渡されます．
シェル変数から出力ファイルを作成するもう一つの方法です．AC_OUTPUT
で，シェル変数variableで名付けられたファイルの内容を出力ファイルに
挿入します(代入ではありません)．これは，AC_OUTPUTが呼び出されたと
き，シェル変数variableの名前のファイルの内容で，
(`Makefile.in')のような出力ファイルの`@variable@'のイ
ンスタンスを，AC_OUTPUTが置換することを意味します．挿入するファイ
ルがない場合には，変数`/dev/null' に設定します．
このマクロは，`Makefile'に特別な依存を含むフラグを挿入したり，特定
のホストやターゲットのためのmakeディレクティブを`Makefile'に
挿入するとき役に立ちます．例えば，`configure.ac' に以下を含ませます．
AC_SUBST_FILE(host_frag) host_frag=$srcdir/conf/sun4.mh |
そして`Makefile.in'に以下を含ませます．
@host_frag@ |
異なる環境変数でconfigureを実行することは非常に危険です．例え
ば，ユーザが`CC=bizarre-cc ./configure'を実行した場合，キャッシュ，
`config.h'，そして多くの出力ファイルは，Cコンパイラが
bizarre-ccだということに依存します．理由があって，ユーザが再び
./configureを実行した場合や，`./config.status --recheck'
でそれが実行される場合(See section 自動的なリメイク. see section コンフィグレーションの再生成)，コンフィグレーションは矛盾し，二つの異なるコンパイラに依存
した結果で構成されます．
上記の`CC'のように，この状況に影響する環境変数は貴重な変数
(precious variables)と命名されていて，AC_ARG_VARのようなもので宣
言することが可能です．
variableを貴重な変数として宣言し，`./configure --help'の可変 部分にそのdescriptionを含めます．
貴重とは，以下のことを意味します．
variableがAC_SUBSTされていること．
configureが開始されたとき，variableの値は，コマンドライ
ンで指定されておらず環境変数で指定されている場合も含めて，キャッシュに保
存されません．実際，configureは`./configure
CC=bizarre-cc'のCCの定義に注目できますが，`CC=bizarre-cc
./configure'のものには注意できません．そして，残念ながらほとんどのユーザ
がそうしています．
それは，保存されるvariableの初期値ですが，
configureの実行中は見つからないことを強調しておきます．実際，
`./configure FOO=foo'と指定することと，`./configure'に
FOOがfooだと分からせることは，かなり違った結果になるはずで
す．
variableは二回のconfigureの実行の間の整合性を調査されま
す．例えば，以下のようにします．
$ ./configure --silent --config-cache $ CC=cc ./configure --silent --config-cache configure: error: `CC' was not set in the previous run configure: error: changes in the environment can compromise \ the build configure: error: run `make distclean' and/or \ `rm config.cache' and start over |
そして，それは変数を未設定にする場合や，その内容が変更される場合も似たよ うなものです．
variableは，自動的な再コンフィグレーションの間，コマンド引数として 渡されているかのように保存され，キャッシュを使用していないときもそうなり ます．
$ CC=/usr/bin/cc ./configure undeclared_var=raboof --silent $ ./config.status --recheck running /bin/sh ./configure undeclared_var=raboof --silent \ CC=/usr/bin/cc --no-create --no-recursion |
様々なconfigureスクリプトで，同じ特徴を繰り返し調査する(あるい
は何度も一つのスクリプトを実行する)ことを避けるため，configure
は，多くの調査結果をキャッシュファイル(cache file)に保存します
(see section キャッシュファイル)．キャッシュ可能な状態でconfigure スクリ
プトを実行していてキャッシュファイルが見つかった場合，前回の実行結果を
キャッシュから読み込み，これらの調査の再実行を避けます．結果として，
configureは，毎回全ての調査を実行するより早くなります．
cache-idで識別した調査結果が，利用可能だということを保証します．調
査結果が読み込まれたキャッシュファイルにあり，configureに，
`--quiet'や`--silent'オプションが与えられていない場合，結果が
キャッシュされていることを示すメッセージを出力します．それ以外では，シェ
ルコマンドcommands-to-set-itを実行します．シェルコマンドを値を決定
するために実行する場合，configureが出力ファイルを作成する直前
に，値をキャッシュファイルに保存します．cache-id変数の名前を選択す
る方法は，See section キャッシュ変数名.
commands-to-set-itは，設定された変数cache-id以外に副作 用がないはずです．以下を参照してください．
メッセージ出力に注意が必要なAC_CACHE_VALのラッパーです．このマク
ロは，これらのマクロを使用する最も一般的な方法に対して，便利な略記法を提
供します．それは，messageに対してAC_MSG_CHECKINGを呼び出し，
その後で，cache-idとcommands引数を伴うAC_CACHE_VALと，
cache-idを伴うAC_MSG_RESULTを呼び出します．
commands-to-set-itは，設定された変数cache-id以外に副作 用がないはずです．以下を参照してください．
commands-to-set-itでAC_DEFINEの呼び出しを試みるため，
AC_CACHE_VALやAC_CACHE_CHECKを使用しているバグの多いマクロ
を発見することはよくあります．その代わりに，AC_CACHE_VALを呼び出
している以下のようなコードでは，キャッシュ変数の値を調べることで，
AC_DEFINEを呼び出すべきです．例えば，以下のマクロは駄目です．
AC_DEFUN([AC_SHELL_TRUE],
[AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
[ac_cv_shell_true_works=no
true && ac_cv_shell_true_works=yes
if test $ac_cv_shell_true_works = yes; then
AC_DEFINE([TRUE_WORKS], 1
[Define if `true(1)' works properly.])
fi])
])
|
これは，キャッシュが利用可能な場合，失敗します．このマクロの二回目の実行
で，TRUE_WORKSは定義されていないでしょう．適切な実装は以下
のようになります．
AC_DEFUN([AC_SHELL_TRUE],
[AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works],
[ac_cv_shell_true_works=no
true && ac_cv_shell_true_works=yes])
if test $ac_cv_shell_true_works = yes; then
AC_DEFINE([TRUE_WORKS], 1
[Define if `true(1)' works properly.])
fi
])
|
また，commands-to-set-itでは，例えばAC_MSG_CHECKINGを用いて
メッセージを出力すべきではありません．調査の結果がキャッシュから取り出さ
れるか，シェルコマンドの実行で決定されるかに依存せずメッセージが出力され
るので，AC_CACHE_VALの呼び出しの前にしてください．
| 7.3.1 キャッシュ変数名 | Shell variables used in caches | |
| 7.3.2 キャッシュファイル | Files configure uses for caching
| |
| 7.3.3 キャッシュのチェックポイント方法 | Loading and saving the cache file |
キャッシュ変数の名前は以下の書式にすべきです．
package-prefix_cv_value-type_specific-value_[additional-options] |
例えば，`ac_cv_header_stat_broken'や `ac_cv_prog_gcc_traditional'です．変数名の一部は以下のようにします．
パッケージや組織の省略です．小文字の慣習以外は，ローカルなAutoconfマクロ と同じプレフィクスで開始します．配布されているAutoconfマクロで使用される キャッシュ値に対して，この値は`ac'になっています．
_cv_シェル変数がキャッシュ値であることを示します．この文字列は，前置されるア ンダースコアを含め，変数名に存在する必要があります．
合理的な命名システムを生成するため，キャッシュ値の分類のための慣習です． Autoconfで使用する値は，マクロ名にリストがあります．
このテストが適応しているキャッシュ値のクラスのメンバーです．例えば，関数 (`alloca')，プログラム(`gcc')，または，出力変数 (`INSTALL')です．
このテストが適応している特定のメンバーの特定の動作です．例えば， `broken'や`set'です．適応されない場合，名前のこの部分は省略さ れます．
キャッシュ変数に割り当てられた値には，改行を含めてはなりません．通常，そ れらの値は真偽値(`yes'や`no')，あるいはファイルや関数の名前で す．そのため，これは重要な制限ではありません．
キャッシュファイルは，コンフィグレーションスクリプトとコンフィグレーショ ンの実行の間で結果を共有できるように，一つのシステムでコンフィグレーショ ンテストの結果をキャッシュしているシェルスクリプトです．他のシステムでは 役に立ちません．その内容が，何らかの理由で無効な場合，ユーザは削除したり 編集したりしてもかまいません．
デフォルトでは，古いキャッシュファイルの使用で偶然生じる問題を避けるため，
configureはキャッシュファイルを使用しません(技術的には，
`--cache-file=/dev/null'を使用します)．
キャッシュを利用可能にするために，configureは結果をファイル
`config.cache'にキャッシュする`--config-cache'(または，
`-C')を受け入れます．代わり方法として，
`--cache-file=file'でfileキャッシュファイルにを指定し
ます．configureがサブディレクトリのconfigureスクリプ
トを呼び出すとき，同じキャッシュファイルを共有するように，
`--cache-file'引数を使用します．AC_CONFIG_SUBDIRSマクロを
用いてサブディレクトリでコンフィグレーションすることの情報は，
See section サブディレクトリで他のパッケージをコンフィグレーションする.
`config.status'は，configureを再実行する
`--recheck'オプションが与えられている場合のみ，キャッシュファイル
に注意を払います．
特定のシステム形式に対してキャッシュファイルを配布しようとすることは間違 いです．そうすることによるエラーに対する機会が非常に多くなり，メンテナン ス時の管理上のオーバーヘッドが非常に多くなります．自動的に推測できない特 徴に対して，標準的なシステムの形式とリンクファイルの標準的な方法を使用し てください (see section 手動のコンフィグレーション)．
サイトの初期化スクリプトで，通常のプログラムごとのキャッシュの代わりに，
使用するサイト全体のキャッシュファイルを指定することが可能になります．こ
の場合，キャッシュファイルは，新しいconfigureスクリプトを実行
する度に，情報がどんどん蓄積されていきます．(configureを実行す
ると，既存のキャッシュファイルを用いて新しい結果をマージします．) しかし，
システムのコンフィグレーションが(例えば，ライブラリやコンパイラをインス
トールされて)変化し，古いキャッシュファイルが削除されない場合，これは問
題になるかもしれません．
configureスクリプトや`configure.ac'から呼び出されるマクロ
がコンフィグレーション処理を中断する場合，二，三回AC_CACHE_SAVEを
使用して，キーポイントでキャッシュのチェックポイントにすることが役に立ち
ます．そうすると，(おそらく)前に異常終了を引き起こしたエラーを修正するこ
とで，configureスクリプトを再実行する時間が大幅に削減されます．
既存のキャッシュファイルから値をロードしたり，キャッシュファイルがない場
合は新しいキャッシュファイルを作成したりします．自動的にAC_INITか
ら呼び出されます．
キャッシュファイルに全てのキャッシュ値を書き込みます．自動的に
AC_OUTPUTから呼び出されますが，`configure.ac'のキーポイント
でAC_CACHE_SAVEを呼び出すことは，大変役に立つはずです．
例えば，以下のようにします．
… AC_INIT, etc. … # Checks for programs. AC_PROG_CC AC_PROG_GCC_TRADITIONAL … more program checks … AC_CACHE_SAVE # Checks for libraries. AC_CHECK_LIB(nsl, gethostbyname) AC_CHECK_LIB(socket, connect) … more lib checks … AC_CACHE_SAVE # Might abort… AM_PATH_GTK(1.0.2,, [AC_MSG_ERROR([GTK not in path])]) AM_PATH_GTKMM(0.9.5,, [AC_MSG_ERROR([GTK not in path])]) … AC_OUTPUT, etc. … |
configureスクリプトは，それらを実行しているユーザに，何種類か
の情報を与える必要があります．以下のマクロは，それぞれの種類に対して適切
な方法でメッセージを出力します．全ての引数は，シェルのダブルクオートで囲
まれているので，シェルは変数とバッククオートの代入を実行します．
これらのマクロは，echoシェルコマンドを全てラップします．
configureスクリプトは，ユーザに対してメッセージを出力するため，
直接echoを実行する必要は滅多にありません．これらのマクロを使用す
ると，出力されるそれぞれのメッセージの種類を，いつでもどのようにでも簡単
に変更できます．そのような変更にはマクロ定義の変更だけが必要で，呼び出し
側は自動的に変更されます．
静的な問題を診断するため，例えばautoconfが実行されるときは，
メッセージの報告を参照してください．
configureが調査している特徴を，ユーザに通知します．このマクロ
は`checking 'で始まり`...'で終る，改行無しのメッセージを出力し
ます．調査の結果と改行のため，AC_MSG_RESULTを続けて呼び出す必要が
あります．feature-descriptionは`FortranコンパイラがC++のコメ
ントを受け入れるかどうか(whether the Fortran compiler accepts C++
comments)'や`c89の調査(for c89)'のようなものです．
configureが`--quiet'や`--silent'オプションを用いて実
行されている場合，このマクロは何も出力しません．
調査結果をユーザに通知します．result-descriptionは，ほとんどいつも
調査に対するキャッシュ変数の値で，普通は`yes'，`no'，またはファ
イル名になります．このマクロはAC_MSG_CHECKINGの呼び出しに続けるべ
きで，result-descriptionは，AC_MSG_CHECKINGの呼び出しで出力
されるメッセージを完成するものにするべきです．
configureが`--quiet'や`--silent'オプションで実行され
る場合，このマクロは何も出力しません．
messageをユーザに伝えます．特徴を調査しているグループ全体の特徴に ついて，例えば以下のような，一般的な記述を出力するときに主に役に立ちます．
AC_MSG_NOTICE([checking if stack overflow is detectable]) |
configureが`--quiet'や`--silent'オプションで実行され
る場合，このマクロは何も出力しません．
configureの完了を妨げるエラーをユーザに通知します．このマクロ
は，エラーメッセージを標準エラー出力に出力し，configureは
exit-status(デフォルトは1)で終了します．error-description は
`\$HOMEに対し$HOMEは無効な値です(invalid value $HOME for \$HOME)'の
ようにすべきです．
error-descriptionは小文字で開始すべきで，"can't"より"cannot" のほうが好ましいでしょう．
これは，AC_MSG_ERRORのラッパーで，configureが終了するの
を妨げるエラーをユーザに告知し，そして詳細を`config.log' に
追加します．これは通常，コンパイル時に異常な結果が見つかったときに使用さ
れます．
可能性のある問題をconfigureを実行しているユーザに通知します．
このマクロは，標準エラー出力にメッセージを出力します．
configureはその後も実行を続けるので，AC_MSG_WARNを呼び
出すマクロでは，警告するような状態に対してデフォルト(バックアップ)の動作
を提供すべきです． problem-descriptionは`ln -s はハードリンク
されます(ln -s seems to make hard links)'のようなものにすべきです．
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.