一度@command{configure}で特徴の存在を定義すると,その情報を記録するた めに何ができるのでしょうか?そうする方法は四種類あります.Cプリプロセッ サシンボルの定義,出力ファイルで変数を設定,@command{configure}実行時 のキャッシュファイルに結果を保存,そして,テスト結果をユーザに知らせる メッセージの出力です.
特徴テストからの応答を受けとる通常の動作は,テストの結果を示すCプリプ
ロセッサシンボルを定義することです.それはAC_DEFINE
や
AC_DEFINE_UNQUOTED
と呼ばれるもので行います.
デフォルトで,AC_OUTPUT
はマクロが定義したシンボルを,出力変数
DEFS
に配置し,それはそれぞれのシンボルに対する
@option{-Dsymbol=value}を含んでいます.Autoconfバージョン1
と異なり,@command{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 コンフィグレーションヘッダファイル.
AC_CONFIG_HEADERS
を使用しない場合,@command{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
を分けるために,セミコロ
ンを使用しないでください.そうすると,@command{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)を設定することで,それは,@command{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@
異なる環境変数で@command{configure}を実行することは非常に危険です.例 えば,ユーザが`CC=bizarre-cc ./configure'を実行した場合,キャッ シュ,`config.h',そして多くの出力ファイルは,Cコンパイラが @command{bizarre-cc}だということに依存します.理由があって,ユーザが再 び@command{./configure}を実行した場合や,@samp{./config.status --recheck}でそれが実行される場合(See section 自動的なリメイク. see section コンフィグレーションの再生成),コンフィグレーションは矛盾し,二つ の異なるコンパイラに依存した結果で構成されます.
上記の`CC'のように,この状況に影響する環境変数は貴重な変数
(precious variables)と命名されていて,AC_ARG_VAR
のようなもので
宣言することが可能です.
貴重とは,以下のことを意味します.
AC_SUBST
'd.
CC
の定義に注目できますが,`CC=bizarre-cc
./configure'のものには注意できません.そして,残念ながらほとんどのユー
ザがそうしています.
それは,保存されるvariableの初期値ですが,
@command{configure}の実行中は見つからないことを強調しておきます.実際,
`./configure FOO=foo'と指定することと,`./configure'に
FOO
がfoo
だと分からせることは,かなり違った結果になるはず
です.
$ ./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そして,それは変数を未設定にする場合や,その内容が変更される場合も似た ようなものです.
$ 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
様々な@command{configure}スクリプトで,同じ特徴を繰り返し調査する(ある いは何度も一つのスクリプトを実行する)ことを避けるため, @command{configure}は,多くの調査結果を@dfn{キャッシュファイル(cache file)}に保存します(see section キャッシュファイル).キャッシュ可能な状態で @command{configure} スクリプトを実行していてキャッシュファイルが見つかっ た場合,前回の実行結果をキャッシュから読み込み,これらの調査の再実行を 避けます.結果として,@command{configure}は,毎回全ての調査を実行する より早くなります.
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
の呼び出しの前にしてください.
キャッシュ変数の名前は以下の書式にすべきです.
package-prefix_cv_value-type_specific-value_@ovar{additional-options}
例えば,`ac_cv_header_stat_broken'や `ac_cv_prog_gcc_traditional'です.変数名の一部は以下のようにしま す.
_cv_
キャッシュ変数に割り当てられた値には,改行を含めてはなりません.通常, それらの値は真偽値(`yes'や`no'),あるいはファイルや関数の名 前です.そのため,これは重要な制限ではありません.
キャッシュファイルは,コンフィグレーションスクリプトとコンフィグレーショ ンの実行の間で結果を共有できるように,一つのシステムでコンフィグレーショ ンテストの結果をキャッシュしているシェルスクリプトです.他のシステムで は役に立ちません.その内容が,何らかの理由で無効な場合,ユーザは削除し たり編集したりしてもかまいません.
デフォルトでは,古いキャッシュファイルの使用で偶然生じる問題を避けるた め,@command{configure}はキャッシュファイルを使用しません(技術的には, @option{--cache-file=/dev/null}を使用します).
キャッシュを利用可能にするために,@command{configure}は結果をファイル
`config.cache'にキャッシュする@option{--config-cache}(または,
@option{-C})を受け入れます.代わり方法として,
@option{--cache-file=file}でfileキャッシュファイルにを指定
します.@command{configure}がサブディレクトリの@command{configure}スク
リプトを呼び出すとき,同じキャッシュファイルを共有するように,
@option{--cache-file}引数を使用します.AC_CONFIG_SUBDIRS
マクロ
を用いてサブディレクトリでコンフィグレーションすることの情報は,
See section サブディレクトリで他のパッケージをコンフィグレーションする.
`config.status'は,@command{configure}を再実行する @option{--recheck}オプションが与えられている場合のみ,キャッシュファイ ルに注意を払います.
特定のシステム形式に対してキャッシュファイルを配布しようとすることは間 違いです.そうすることによるエラーに対する機会が非常に多くなり,メンテ ナンス時の管理上のオーバーヘッドが非常に多くなります.自動的に推測でき ない特徴に対して,標準的なシステムの形式とリンクファイルの標準的な方法 を使用してください (see section 手動のコンフィグレーション).
サイトの初期化スクリプトで,通常のプログラムごとのキャッシュの代わりに, 使用するサイト全体のキャッシュファイルを指定することが可能になります. この場合,キャッシュファイルは,新しい@command{configure}スクリプトを 実行する度に,情報がどんどん蓄積されていきます.(@command{configure}を 実行すると,既存のキャッシュファイルを用いて新しい結果をマージします.) しかし,システムのコンフィグレーションが(例えば,ライブラリやコンパイ ラをインストールされて)変化し,古いキャッシュファイルが削除されない場 合,これは問題になるかもしれません.
@command{configure}スクリプトや`configure.ac'から呼び出されるマク
ロがコンフィグレーション処理を中断する場合,二,三回
AC_CACHE_SAVE
を使用して,キーポイントでキャッシュのチェックポイ
ントにすることが役に立ちます.そうすると,(おそらく)前に異常終了を引き
起こしたエラーを修正することで,@command{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. ...
@command{configure}スクリプトは,それらを実行しているユーザに,何種類 かの情報を与える必要があります.以下のマクロは,それぞれの種類に対して 適切な方法でメッセージを出力します.全ての引数は,シェルのダブルクオー トで囲まれているので,シェルは変数とバッククオートの代入を実行します.
これらのマクロは,echo
シェルコマンドを全てラップします.
@command{configure}スクリプトは,ユーザに対してメッセージを出力するた
め,直接echo
を実行する必要は滅多にありません.これらのマクロを
使用すると,出力されるそれぞれのメッセージの種類を,いつでもどのように
でも簡単に変更できます.そのような変更にはマクロ定義の変更だけが必要で,
呼び出し側は自動的に変更されます.
静的な問題を診断するため,例えば@command{autoconf}が実行されるときは, section メッセージの報告を参照してください.
AC_MSG_RESULT
を続けて呼び出す
必要があります.feature-descriptionは`Fortranコンパイラが
C++のコメントを受け入れるかどうか(whether the Fortran compiler accepts
C++ comments)'や`c89の調査(for c89)'のようなものです.
@command{configure}が`--quiet'や`--silent'オプションを用いて 実行されている場合,このマクロは何も出力しません.
AC_MSG_CHECKING
の呼び出しに
続けるべきで,result-descriptionは,AC_MSG_CHECKING
の呼び
出しで出力されるメッセージを完成するものにするべきです.
@command{configure}が`--quiet'や`--silent'オプションで実行さ れる場合,このマクロは何も出力しません.
AC_MSG_NOTICE([checking if stack overflow is detectable])
@command{configure}が`--quiet'や`--silent'オプションで実行さ れる場合,このマクロは何も出力しません.
error-descriptionは小文字で開始すべきで,"can't"より"cannot" のほうが好ましいでしょう.
AC_MSG_ERROR
のラッパーで,@command{configure}が終了する
のを妨げるエラーをユーザに告知し,そして詳細を`config.log'
に追加します.これは通常,コンパイル時に異常な結果が見つかったときに使
用されます.
AC_MSG_WARN
を呼
び出すマクロでは,警告するような状態に対してデフォルト(バックアップ)の
動作を提供すべきです. problem-descriptionは`ln -s はハード
リンクされます(ln -s seems to make hard links)'のようなものにすべきで
す.
Go to the first, previous, next, last section, table of contents.