@command{configure}スクリプトは,何種類かのローカルコンフィグレーショ ンの宣言をサポートします.ユーザが外部ソフトウェアパッケージの場所を指 定したり,追加の特徴を含めたり排除したり,編集された名前でプログラムを インストールしたり,@command{configure}オプションに対してデフォルト値 を設定したりする方法があります.
既にインストールしてある他のソフトウェアパッケージを要求したり,追加で 使用していたりしているパッケージもあります.ユーザは,使用するそのよう な外部ソフトの指定するために,@command{configure}のコマンドラインオプ ションを与えることが可能です.オプションは以下の形式うちの一つです.
--with-package[=arg] --without-package
例えば,@option{--with-gnu-ld}は,他のリンカの代わりに@acronym{GNU}リ ンカで動作することを意味します.@option{--with-x}はX Window Systemで動 作することを意味します.
ユーザはパッケージ名に続く引数を,`='とその引数で与えることが可能 です.`no'引数を与えるとパッケージはデフォルトを使用します.つま り,パッケージを使用しません.`yes'も`no'もない引数は, このプログラムで動作すると予想される他のパッケージをより正確に指定する ために,他のパッケージの名前やバージョンナンバーを含ることが可能です. 引数が与えられていない場合,デフォルトは`yes'です. @option{--without-package}は,@option{--with-package=no}と 同じです.
@command{configure}スクリプトは,サポートしていない @option{--with-package}オプションに文句を言いません.これにより, 複数のパッケージを含むソースツリーにおいて,パッケージが異なるオプショ ンをサポートするとき,パッケージによってはサポートするものもあるオプショ ンで深刻なエラーメッセージを出力すること無く,トップレベルの @command{configure}スクリプトでのコンフィグレーションが可能になります. 残念な副作用として,オプションのスペルエラーは診断されません.この問題 のより良い手法はまだ提案されていません.
使用される可能性のあるそれぞれの外部ソフトウェアパッケージに対して,
@command{configure}のユーザがそれの使用を依頼したかどうかを検出するた
め,`configure.ac'でAC_ARG_WITH
を呼び出すべきです.それぞ
れのパッケージでデフォルトで使用するかどうかと,有効な引数については,
好きにしてください.
オプションの引数は,`-'文字を`_'に変更したシェル変数
with_package
の実際の値となる,シェル変数withval
内
のシェルコマンドaction-if-givenが利用可能です.望むなら,変わり
にその値を使用してもかまいません.
引数help-stringは以下のような,オプションの説明です.
--with-readline support fancy command line editing
詳細が必要な場合,help-stringは一行以上でもかまいません. `configure --help'で行が整列していることを確認してください.ヘル プ文字列でのタブの使用は避けてください.前置するスペースを生成するため, ヘルプ文字列を`['と`]'で囲む必要があるでしょう.
help-stringは,マクロAC_HELP_STRING
で書式化すべきです
(see section ヘルプ文字列を小奇麗にする).
AC_ARG_WITH
の時代
遅れのバージョンです.
ソフトウェアパッケージに追加のコンパイル時の特徴がある場合,それらをコ ンパイルするかどうか指定するため,ユーザは@command{configure}コマンド ラインオプションを与えることが可能です.オプションは以下の書式の一つに なります.
--enable-feature[=arg] --disable-feature
これらのオプションで,ビルドしインストールする追加の機能を,ユーザが選 択することが可能になります.@option{--enable-feature}オプション で,ある機能に異なる動作をさせたり,ある機能を他の機能で置換させたりす るべきではありません.それらは,プログラムの部分をビルドする,または削 除するためだけにすべきです.
ユーザは,機能の名前に続く引数を`='とその引数で与えることが可能で す.`no'引数を与えるとその機能は利用できません.機能とは, @option{--enable-debug=stabs}のような引数です.引数が与えられていない 場合は,デフォルトで`yes'です.@option{--disable-feature}は, @option{--enable-feature=no}と同じです.
@command{configure}スクリプトは,サポートしていない @option{--enable-feature}オプションに文句を言いません.これによ り,複数のパッケージを含むソースツリーにおいて,パッケージが異なるオプ ションをサポートするとき,パッケージによってはサポートするものもあるオ プションで深刻なエラーメッセージを出力すること無く,トップレベルの @command{configure} スクリプトでのコンフィグレーションが可能になります. 残念な副作用として,オプションのスペルエラーは診断されません.この問題 のより良い手法はまだ提案されていません.
使用される可能性のあるそれぞれの追加の機能に対して,
@command{configure} のユーザがそれを含めることを依頼したかどうかを検出
するため,`configure.ac'でAC_ARG_ENABLE
を呼び出すべきです.
それぞれの機能をデフォルトで使用するかどうかと,有効な引数については,
好きにしてください.
オプションの引数は,`-'文字を`_'に変更したシェル変数
enable_package
の実際の値となる,シェル変数
enableval
内のシェルコマンドaction-if-givenが利用可能です.
望むなら,変わりにその値を使用してもかまいません.help-string引
数は,AC_ARG_WITH
と同様にしてください(see section 外部ソフトウェアとともに動作する).
help-stringは,マクロAC_HELP_STRING
で書式化すべきです
(see section ヘルプ文字列を小奇麗にする).
AC_ARG_ENABLE
の時代遅れ
のバージョンです.
AC_ARG_WITH
(see section 外部ソフトウェアとともに動作する)とAC_ARG_ENABLE
(see section パッケージオプションの選択)で使用する`help strings'を正しく書式化す
ることに挑戦してみましょう.具体的には,独自の`help strings'を,
標準的なAutoconfの`help strings'のように,`configure --help'
で列に適切に並ぶようにしたいと思うでしょう.AC_HELP_STRING
マク
ロの目的はここにあります.
ユーザが`configure --help'を実行したとき,小奇麗なヘルプ文字列に
展開します.通常は,AC_ARG_WITH
(see section 外部ソフトウェアとともに動作する)や
AC_ARG_ENABLE
(see section パッケージオプションの選択)で使用します.以下の例で
より分かり易くなるでしょう.
AC_DEFUN([TEST_MACRO], [AC_ARG_WITH([foo], AC_HELP_STRING([--with-foo], [use foo (default is NO)]), [ac_cv_use_foo=$withval], [ac_cv_use_foo=no]) AC_CACHE_CHECK([whether to use foo], [ac_cv_use_foo], [ac_cv_use_foo=no])])
AC_HELP_STRING
の呼び出しは引用符で囲まないことに注意し
てください.`configure --help'の最後の数行に,以下のような行が現
れます.
--enable and --with options recognized: --with-foo use foo (default is NO)
AC_HELP_STRING
マクロは,以下の例のように,left-hand-side
そして/またはright-hand-sideがマクロ引数で構成される時,特に役に
立ちます.
AC_DEFUN(MY_ARG_WITH, [AC_ARG_WITH([$1], AC_HELP_STRING([--with-$1], [use $1 (default is $2)]), ac_cv_use_$1=$withval, ac_cv_use_$1=no), AC_CACHE_CHECK(whether to use $1, ac_cv_use_$1, ac_cv_use_$1=$2)])
複雑なサイト指定の情報が必要となるソフトウェアパッケージもあります.例 えば,特定のサービスで使用する,ホスト名,会社名,そして連絡先の電子メー ルアドレスがあげられます.Metaconfigが生成したコンフィグレーションスク リプトには,そのような情報を対話的に尋ねるものもあるので,Autoconfが生 成した対話的でないコンフィグレーションスクリプトが,どうやってその情報 を得るのかと不思議に思うこともあるでしょう.
そのようなサイトコンフィギュレーション情報は,プログラムではなく
ユーザだけが編集するファイルに書き込むべきです.ファイルの場所
は,prefix
変数に基づくところか,ユーザのホームディレクトリのよ
うな,標準的な場所が可能です.それは環境変数で指定するべきでしょう.プ
ログラムでは,コンパイル時ではなく実行時にファイルを調査するべきです.
実行時のコンフィグレーションはユーザにとって便利で,コンフィグレーショ
ン時に情報を得るよりコンフィグレーション処理が簡単になります.データファ
イルを書き込む場所の詳細は,See section `Variables for Installation Directories' in @acronym{GNU Coding Standards}.
Autoconfは,インストール時にプログラム名を変更することをサポートします.
これらの変換を使用するため,`configure.ac'でマクロ
AC_ARG_PROGRAM
を呼び出す必要があります.
program_transform_name
に,インストールするプログラムの
名前を変更するため,sed
コマンドのシーケンスを配置します.
下記のオプションのいずれかが@command{configure}に与えれらている場合,
プログラム名は適宜変換されます.それ以外では,
AC_CANONICAL_SYSTEM
が呼び出されて,`--target'の値が与えら
れている場合,ダッシュが続いているターゲットタイプがプレフィクスとして
使用されます.それ以外ではプログラム名は変換されません.
@command{configure}に以下のコマンドラインオプションを与えることで,名 前変換を指定することが可能です.
sed
のexpressionで名前への代入を実行します.
これらの変換は,クロスコンパイル開発環境の一部となるプログラムで役に立 ちます.例えば,@option{--target=i960-vxworks}オプションでコンフィグレー ションされたSun 4でクロスアセンブラの実行では,通常,`as'ではなく `i960-vxworks-as'がインストールされるので,ネイティブのSun 4アセ ンブラと混在できます.
@acronym{GNU}プログラムを,他のプログラムを隠してしまうような同じ名前
でシステムにインストールしたくない場合,プログラム名を`g'から始め
ることができます.例えば,@acronym{GNU} diff
を
@option{--program-prefix=g}でコンフィグレーションする場合,@samp{make
install}時に`/usr/local/bin/gdiff'としてインストールされます.
より洗練された例として,以下を使用することができます.
--program-transform-name='s/^/g/; s/^gg/g/; s/^gless/less/'
これは,ソースツリーで,`g'をほとんどのプログラム名に前置し,
gdb
のように既に持っているものと,less
とlesskey
の
ように@acronym{GNU}プログラムでないものは例外とすることができます.(こ
の機能を使用するために,セットアップされたプログラムを含むソースツリー
を持っていることが仮定されます.)
同時にいくつかのプログラムの複数のバージョンをインストールする方法の一 つとして,一つあるいは両方の名前にバージョンナンバーを追加することです. 例えば,しばらくの間Autoconfバージョン1を保持したい場合,Autoconfバー ジョン2を,`/usr/local/bin/autoconf2'や `/usr/local/bin/autoheader2'等としてプログラムをインストールする ため,@option{--program-suffix=2}を使用してコンフィグレーションするこ とが可能です.それにもかかわらず,バイナリのみ名前が変更されることに注 意してください.そのため,オーバーラップする可能性のあるライブラリファ イルは問題になるでしょう.
`Makefile.in'で変数program_transform_name
を使用する方法は
以下のようになります.
PROGRAMS = cp ls rm transform = @program_transform_name@ install: for p in $(PROGRAMS); do \ $(INSTALL_PROGRAM) $$p $(DESTDIR)$(bindir)/`echo $$p | \ sed '$(transform)'`; \ done uninstall: for p in $(PROGRAMS); do \ rm -f $(DESTDIR)$(bindir)/`echo $$p | sed '$(transform)'`; \ done
program_transform_name
が空ではなく,無意味なセパレータがないこ
とが保証されます.そのため,`;'使用しているsed
プログラムに
program_transform_name
を安全に埋め込むことができます.
transform = @program_transform_name@ transform_exe = s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/
ドキュメントファイル(Texinfoやman
)で変換するどうかは,慎重を要
する質問です.名前を変える理由がいくつかあるため,完全な答えがあるとは
思われません.ドキュメントは通常,特定のアーキテクチャ特有のものではな
く,Texinfoファイルはシステムドキュメントと衝突しません.しかし,それ
らは同じファイルの前のバージョンと衝突したり,man
ページはシステ
ムドキュメントと衝突することがあるかもしれません.妥協案として,
man
ページは名前を変換してTexinfoマニュアルは変換しないのがおそ
らく最善でしょう.
Autoconfが生成した@command{configure}スクリプトで,コンフィグレーショ ンの値に対して,サイトのデフォルト値を供給できるものもあります.これは, サイト全体と システム全体の初期化ファイルを作成することで可能となりま す.
環境変数CONFIG_SITE
が設定されている場合,@command{configure}は,
その値を読み込むシェルスクリプトの名前として使用します.それ以外では,
シェルスクリプト`prefix/share/config.site'があればそれを読
み込み, 次に`prefix/etc/config.site'があればそれを読み込み
ます.このため,それらが衝突する状況では,マシン特有のファイルでの設定
がマシン非依存の設定に優先します.
サイトファイルは任意のシェルスクリプトが可能ですが,本来なら特定の種類
のコードだけがその中にあるのが適切です.@command{configure}はサイトファ
イルを読み込んだ後でキャッシュファイルを読み込むので,サイトファイルは,
そのシステムで実行されるAutoconfが生成した全ての@command{configure}ス
クリプト間で,デフォルトのキャッシュファイルを共有することが可能になっ
ています(see section キャッシュファイル).キャッシュファイルは特定のコンパイラに
対してのみで有効ですが,システムの多くは複数の利用可能なコンパイラがあ
るので,デフォルトのキャッシュファイルをサイトファイルに設定した場合,
サイトファイルで出力変数CC
を設定するのは良い考えです.
@command{configure}へのコマンドラインオプションで,サイトファイルで設
定された値を調査したり優先したりすることが可能です.オプションは,ダッ
シュをアンダースコアに変更した,オプションと同じ名前のシェル変数を設定
します.例外は,`--without-'と`--disable-'オプションが,対応
する`--with-'や`--enable-'オプションに値`no'を与えたも
のに似ていることです.このため,@option{--cache-file=localcache}は,変
数 cache_file
を値`localcache'に設定し,
@option{--enable-warnings=no}や@option{--disable-warnings}は,変数
enable_warnings
を値`no'に設定しします.
@option{--prefix=/usr}は,変数prefix
を値`/usr'に設定します.
といったようになっています.
デフォルトでない値を与える必要がある場合,サイトファイルは
CFLAGS
のような他の出力変数に対しデフォルト値を設定するための良
い場所です.通常コマンドラインで繰り返し行っていることならなんでもでき
ます.prefix やexec_prefixに対してデフォルト値ではないもの
を使用したい場合(サイトファイルの場所がどこであれ),CONFIG_SITE
を用いて指定すると,サイトファイルで設定できます.
サイトファイル自身でキャッシュ値を設定することもできます.こうすること で,テストプログラムの実行が必要な特徴の調査が不可能なクロスコンパイル で役に立ちます.システムに対して`prefix/etc/config.site' で これらの値を正しく設定することで,"キャッシュの用意"が可能です.設定 する必要があるキャッシュ変数名を見つけるため,影響を受けた @command{configure}スクリプトやこれらのマクロに対するAutoconf M4ソース コードで,名前に`_cv_'を伴うシェル変数を探してください.
キャッシュファイルは,サイトファイルで設定した変数を無効にしないよう注
意深く実行します.また,サイトファイルでコマンドラインオプションを無効
にするべきではありません.コードでは,prefix
とcache_file
のような変数を変更する前に,(@command{configure}の最初の方で設定される)
デフォルト値をがあるかどうかを調査するべきです.
サンプルファイル`/usr/share/local/gnu/share/config.site'が以下の
ようになります.コマンド`configure --prefix=/usr/share/local/gnu'
は,(CONFIG_SITE
で異なるファイルを設定していない場合)このファイ
ルを読み込みます.
# 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" = /dev/null; then cache_file="$prefix/var/config.cache" # A cache file is only valid for one C compiler. CC=gcc fi
Go to the first, previous, next, last section, table of contents.