Autoconfが生成した@command{configure}スクリプトは,パッケージのソース ファイルの見つけ方,そして,生成する出力ファイルといった,初期化の方法 の情報を必要とします.以下のセクションで,初期化と出力ファイルの作成に ついて述べます.
すべての@command{configure}スクリプトファイルでは,他の何よりも前に,
AC_INIT
を呼び出す必要があります.そのほかに必要なマクロは
AC_OUTPUT
だけです(see section 出力ファイルを生成する).
packageの名前とそのversionを設定します.これらは通常, @command{configure}に含まれる@option{--version}のサポートで使用されま す.オプションの引数bug-report-addressは,ユーザがバグレポートを 送る電子メールアドレスにすべきです.パッケージのtarnameは packageとは異なります.後者はパッケージの完全な名前を示します(例 えば,`GNU Autoconf')が,前者は配布物のtar ballの名前(例えば, `autoconf')を意味します.デフォルトはpackageから`GNU ' を取り除き,小文字にし,そして英数文字以外を全て`-'にしたものです.
AC_INIT
の引数は静的にすることが望ましく,すなわちシェルで演算し
て求めるべきではありませんが,M4で演算してもかまいません.
以下のM4マクロ(例えば,AC_PACKAGE_NAME
)は,AC_INIT
によっ
て,出力変数(例えば,PACKAGE_NAME
)を出力し,プリプロセッサシン
ボル(例えば,PACKAGE_NAME
)を定義します.
AC_PACKAGE_NAME
, PACKAGE_NAME
AC_PACKAGE_TARNAME
, PACKAGE_TARNAME
AC_PACKAGE_VERSION
, PACKAGE_VERSION
AC_PACKAGE_STRING
, PACKAGE_STRING
AC_PACKAGE_BUGREPORT
, PACKAGE_BUGREPORT
以下のマクロは,@command{configure}スクリプトのバージョンナンバーを管 理します.それはオプションとして使用されます.
AC_PREREQ(2.57)
このマクロは,AC_INIT
以前に使用可能な唯一のマクロですが,整合性
のためにはそうすべきではありません.
copyright-noticeは,@command{configure}の先頭と,@samp{configure --version}の両方で表示されます.
例えば,以下の行を`configure.ac'に書いたとします.
AC_REVISION($Revision: 1.30 $)
これで,@command{configure}は以下のようになります.
#! /bin/sh # From configure.ac Revision: 1.30
手動でのコンフィグレーションや,install
プログラムを使用するパッ
ケージは,デフォルトの位置でほとんど正しいのですが,
AC_CONFIG_AUX_DIR
を呼び出して,他のシェルスクリプトを探す場所
を@command{configure}に教える必要があるかもしれません.
AC_PROG_INSTALL
を使用するこ
とで,他の補助ファイルを配布する必要は自動的になくなります.また,それ
は `install.sh'も調査しますが,make
プログラムには,
`Makefile'が無い場合,それから`install'を作るルールを持ってい
るものあるので,その名前は時代遅れです.
すべてのAutoconfスクリプト,例えば`configure.ac'は,
AC_OUTPUT
の呼び出しで終えるべきです.それは,コンフィグレーショ
ンの結果生成される`Makefile'とその他のファイルを生成する,
`config.status'を生成するマクロです.AC_INIT
以外で唯一必要
とされるマクロです(see section @command{configure}の入力を見つける).
`config.status'は,全てのコンフィグレーション作業を実行します.全
ての出力ファイル(section コンフィグレーションファイルの作成とマクロ
AC_CONFIG_FILES
を参照してください),ヘッダファイル
(section 任意のコンフィグレーションコマンドの実行とマクロAC_CONFIG_COMMANDS
を参照し
てください),コマンド(section 任意のコンフィグレーションコマンドの実行とマクロ
AC_CONFIG_COMMANDS
を参照してください),リンク
(section コンフィグレーションのリンクを作成するとマクロAC_CONFIG_LINKS
を参照してくだ
さい),サブディレクトリ(section コンフィグレーションのリンクを作成するとマクロ
AC_CONFIG_LINKS
を参照してください)が尊重されます.
歴史的には,AC_OUTPUT
の使用はいくぶん異なっています.
AC_OUTPUT
がサポートする引数の記述は,See section 時代遅れのマクロ.
サブディレクトリで@command{make}を実行する場合,@command{make}を変数
MAKE
を使用して実行すべきです.たいていのバージョンの
@command{make}で,MAKE
に@command{make}プログラムと,それに与え
るあらゆるオプションを追加して設定します.(しかし,その中にコマンドラ
インで設定された値を含まないものも多いので,それらは自動的に渡されませ
ん.) 古いバージョンの@command{make}には,変数を設定しないものもありま
す.以下のマクロでそれらのバージョンでも使用可能になります.
make
がMake変数MAKE
を前もって定義する場合,出力変数
SET_MAKE
は空で定義されます.それ以外では,SET_MAKE
は
`MAKE=make'を含みます.SET_MAKE
に対してAC_SUBST
を呼
び出して下さい.
このマクロを使用する場合,MAKE
を実行する他のディレクトリのそれ
ぞれの`Makefile.in'に以下の行を書き込んで下さい.
@SET_MAKE@
`configure'は,自分が行なっていることが全部分かるように設計されて いますが,隠されている従属物も実際にはあります.それは, `config.status'です.`configure'はシステムの調査を担当してい ますが,`configure'の結果を基に適切な動作を実際に引き受けるのは, `config.status'です.`config.status'のほとんどの典型的な作業 は,ファイルを実際に作成することです.
このセクションでは,実際に何かを作成する基本的な四つのマクロの一般的な
動作を説明します.それらは,AC_CONFIG_FILES
,
AC_CONFIG_HEADERS
,AC_CONFIG_COMMANDS
,そして
AC_CONFIG_LINKS
です.それらは全て以下のものが原型となっています.
AC_CONFIG_FOOS(tag..., [commands], [init-cmds])
ここでの引数は,以下のとおりです.
... && my_foos="$my_foos fooo" ... && my_foos="$my_foos foooo" AC_CONFIG_FOOS($my_foos)この代わりに以下のようにしてください.
... && AC_CONFIG_FOOS(fooo) ... && AC_CONFIG_FOOS(foooo)マクロ
AC_CONFIG_FILES
とAC_CONFIG_HEADERS
は,特別な
tagを使用します.それらは,`output'や
`output:inputs'にすることが可能です.ファイル
outputは,そのテンプレートinputsから実際に作成されます(デ
フォルトは`output.in').
例えば,`AC_CONFIG_FILES(Makefile:boiler/top.mk:boiler/bot.mk)'は,
`boiler/top.mk'と`boiler/bot.mk'を繋げたものに,出力変数を展
開した`Makefile'を作成するよう要求します.
特殊な値`-'は,outputで使用されているときは標準出力を,
inputsで使用されているときは標準入力を示すために使用されます.お
そらく`configure.ac'でこれを使用する必要はほとんど無いと思います
が,`./config.status'のコマンドラインインターフェースを使用してい
るときは便利でしょう.詳細は,section コンフィグレーションの再生成,を参照し
てください.
inputsは,絶対パスまたは相対パスを用いたファイル名が可能です.後
者の場合,それは最初にビルドツリーで探され,その後でソースツリーで探さ
れます.
srcdir
ac_top_srcdir
ac_top_builddir
ac_srcdir
AC_CONFIG_COMMANDS([deep/dir/out:in/in.in], [...], [...])@option{--srcdir=../package}を用いると,以下の値が生成されます.
# Argument of --srcdir srcdir='../package' # Reversing deep/dir ac_top_builddir='../../' # Concatenation of $ac_top_builddir and srcdir ac_top_srcdir='../../../package' # Concatenation of $ac_top_srcdir and deep/dir ac_srcdir='../../../package/deep/dir'`in/in.in'とは無関係です.
var
の値として出力されます.init-cmdsは通常,
commands を実行するために必要な同じ変数を`config.status'に
与えるために,`configure'で使用されます.
変数名では特に注意すべきです.すべてのinit-cmdsは同じ名前空間を
共有し,それぞれ予測できない方法で上書きされるかもしれません.残念です
@enddots{}
当然ですが,すべてのこれらのマクロは,異なるtagを用いると,何回 でも呼び出すことが可能です!
きちんとこの前の章を読んでくださいね,section コンフィグレーション作業の実行.
AC_OUTPUT
でそれぞれの
`file'を作成するようにします.
このマクロは,実際に何かを作成するマクロの一つです.section コンフィグレーション作業の実行を参照してください.出力変数を使用することの詳細な情報は,
See section Makefileへの代入. それらを作成するための詳細な情報は,
See section 出力変数の設定. これらのマクロは,存在しない場合はファ
イルを配置するディレクトリを作成します.通常,`Makefile'はこの方
法で作成されますが,`.gdbinit'のようなそれ以外のファイルは,指定
されていることもあります.
一般的なAC_CONFIG_FILES
の呼び出しは,以下のようになります.
AC_CONFIG_FILES([Makefile src/Makefile man/Makefile X/Imakefile]) AC_CONFIG_FILES([autoconf], [chmod +x autoconf])
コロンで分離されている入力ファイルfileのリストを入力ファイルに追 加することで,優先可能です.例えば以下のようにします.
AC_CONFIG_FILES([Makefile:boiler/top.mk:boiler/bot.mk] [lib/Makefile:boiler/lib.mk])
こうすることで,ファイル名をMS-DOSが受け入れ可能なままにしたり,ファイ ルに常套句を前置したり後置したりすることが可能となります.
コンパイルされたりインストールされたりするものを含んでいる,配布物のそ
れぞれのサブディレクトリには,@command{configure}がそのディレクトリに
`Makefile'を作成するためのファイル`Makefile.in'を配置すべき
です.`Makefile'を作成するために,`Makefile.in'の
`@variable@'を@command{configure}が決定したその変数の値に
置換しながら,@command{configure}は単純な変数の代入を行います.このよ
うにして出力ファイルに代入される変数は,出力変数(output
variable)と呼ばれます.それらは@command{configure}で設定される普通の
シェル変数です.@command{configure}が特定の変数を出力ファイルに代入す
るように,変数名を引数としてAC_SUBST
マクロを呼び出す必要があり
ます.他の変数に対する`@variable@'が変化することはありま
せん.AC_SUBST
を用いた出力変数の作成方法の詳細は,See section 出力変数の設定.
@command{configure}スクリプトを使用しているソフトウェアパッケージは, ファイル`Makefile.in'と一緒に配布すべきですが,`Makefile'は 配布すべきではありません.つまり,ユーザはコンパイルする前にローカルシ ステムに対して,正しくパッケージをコンフィグレーションする必要がありま す.
`Makefile'に書くものの詳細はSee section `Makefile Conventions' in The @acronym{GNU Coding Standards}.
Autoconfマクロが前もって設定する出力変数もあります.追加の出力変数を設
定するAutoconfマクロもあり,それは,それらのマクロの記述で言及されてい
ます.出力変数の完全なリストは,See section 出力変数の索引. 以下は
それぞれ,それ以外のプリセットされたもののリストです.それらは全て大切
な値です(see section 出力変数の設定, AC_ARG_VAR
).
AC_PROG_CC
を呼び出すときにデフォルト値が設定されます(そうでない
場合は空になります).Cの特徴をテストするためのプログラムをコンパイルす
るとき,@command{configure}はこの変数を使用します.
AC_OUTPUT
は,それが作成するすべての
`Makefile'の最初に,この変数を含むコメント行を加えます.それ以外
のファイルは,それぞれの入力ファイルの最初のコメントで,この変数を参照
すべきです.例えば,入力シェルスクリプトの最初は以下のようにすべきです.
#! /bin/sh # @configure_input@
またその行の存在で,ファイルを編集している人は,@command{configure}を 使用して処理する必要があることを思い出します.
AC_PROG_CXX
を呼
び出したときにデフォルト値に設定されます(そうでない場合は空になります).
@command{configure}は,C++の特徴をテストするプログラムのコンパイル時に,
この変数を使用します.
AC_CONFIG_HEADER
が呼
び出されている場合,@command{configure}は`@DEFS@'の代わりに
`-DHAVE_CONFIG_H'に置換します(see section コンフィグレーションヘッダファイル).こ
の変数は,@command{configure}がテストを実行している間は定義されず,出
力ファイルを作成するときだけ定義されます.前のテストの結果を調査する方
法は,See section 出力変数の設定.
echo
に後置される改行を抑制
する方法は?これらの変数は,その方法を提供します.
echo $ECHO_N "And the winner is... $ECHO_C" sleep 100000000000 echo "${ECHO_T}dead."
古く一般的でないecho
の実装では,これを達成する意味が無いものも
あり,その場合,ECHO_T
はタブをに設定されます.そうしたくないか
もしれません.
AC_PROG_F77
を呼び出したときデフォルト値に設定されます(そうでな
い場合は空になります).@command{configure}は,Fortran 77の特徴をテスト
するプログラムのコンパイル時に,この変数を使用します.
builddir
の絶対パスです.
builddir
と同じです.
top_builddir
の絶対パスです.
srcdir
の絶対パスです.
srcdir
と同じです.
top_srcdir
の絶対パスです.
以下の変数は,パッケージがインストールされる場所を指定します.詳細は, section `Variables for Installation Directories' in The @acronym{GNU Coding Standards}を参照してください.これ らの変数を使用するときとその方法の詳細は,このセクションの終りを参照し てください.
これらの変数のほとんどは,prefix
やexec_prefix
に依存する
値になります.ディレクトリ変数の出力値が展開されないように考慮されてい
ます.典型的な例として,`@datadir@'は,`/usr/local/share'
ではなく`${prefix}/share'に置換されます.
以下の動作は,@acronym{GNU} coding standardsで示されれていて,ユーザが 実行時にそうなるようになっています.
これらの機能をサポートするために,datadir
がprefix
の現在
の値に依存する`${prefix}/share'として定義されたままになっている
ことが重要です.
当然のことですが,これらの変数を`Makefiles'で使用すべきではありま
せん.例えば,`configure'でdatadir
を評価する代わりに,
`Makefile'で,例えば`AC_DEFINE_UNQUOTED(DATADIR,
"$datadir")' としてハードコードする場合は,
`-DDATADIR="$(datadir)"'をCPPFLAGS
に加えるべきです.
同様に,datadir
とその仲間を,シェルスクリプトやその他のファイル
で置換するために,AC_OUTPUT_FILES
に頼るべきではなく,その代わり
に@command{make}にその置換を行なわせてください.例えば,Autoconfは
`.in'で終るシェルスクリプトのテンプレートを配布していて,以下のよ
うな`Makefile'の一部を使用しています.
edit = sed \ -e 's,@datadir\@,$(pkgdatadir),g' \ -e 's,@prefix\@,$(prefix),g' autoconf: Makefile $(srcdir)/autoconf.in rm -f autoconf autoconf.tmp $(edit) $(srcdir)/autoconf.in >autoconf.tmp chmod +x autoconf.tmp mv autoconf.tmp autoconf autoheader: Makefile $(srcdir)/autoheader.in rm -f autoheader autoheader.tmp $(edit) $(srcdir)/autoconf.in >autoheader.tmp chmod +x autoheader.tmp mv autoheader.tmp autoheader
注目すべきことがいくつかあります.
edit
は,コンフィグレーション特有の値(prefix
等)に依存し,
VERSION
やそれの以前のものには依存しない値を使用するので,出力は
`configure.ac'ではなく`Makefile'に依存します.
autoconf autoheader: Makefile .in: rm -f $@ $@.tmp $(edit) $< >$@.tmp chmod +x $@.tmp mv $@.tmp $@詳細は,See section Makeの制限.
同じソースコードのコピーから,同時に複数のアーキテクチャに対するソフト ウェアパッケージのコンパイルをサポートすることが可能です.それぞれのアー キテクチャに対するオブジェクトファイルは,それ自身のディレクトリに保存 されます.
これをサポートするために,@command{make}は,ソースディレクトリにあるファ
イルを見つけるためVPATH
変数を使用します.@acronym{GNU} Makeとそ
の他のほとんどの最近の@command{make}プログラムはこうすることが可能です.
もっと古い@command{make}プログラムは,VPATH
をサポートしていませ
ん.それを使用するときは,ソースコードをオブジェクトファイルと同じディ
レクトリ置く必要があります.
VPATH
をサポートするため,それぞれの`Makefile.in'には,以下
のような二行が必要です.
srcdir = @srcdir@ VPATH = @srcdir@
VPATH
の値に変数を代入しない@command{make}のバージョンもあるので,
VPATH
に他の値,例えば`VPATH = $(srcdir)'を設定しないでくだ
さい.
@command{configure}は`Makefile'を作成するとき,srcdir
に正
しい値を代入します.
暗黙のルールを期待して,(VPATH
で見つかる)ソースディレクトリのファ
イルのパス名を展開する@command{make}変数の$<
を使用しないでくだ
さい.(暗黙のルールとは,`.c'ファイルから`.o'ファイルを作成す
る方法を教える`.c.o'の様なものです.)暗黙のルールで$<
を設定
しないバージョンの@command{make}もあり,それは,空の値で展開します.
その代わり,`Makefile'コマンドラインは,ソースファイルを `$(srcdir)/'を前置して参照します.例えば以下のようにします.
time.info: time.texinfo $(MAKEINFO) $(srcdir)/time.texinfo
コンフィグレーションファイルを変更したとき自動的にコンフィグレーション 情報を更新するため,パッケージに対するトップレベルの`Makefile.in' に以下のようなルールを書くことが可能でます.以下の例には, `aclocal.m4'やそれらが関連するるコンフィグレーションヘッダファイ ルのような,全てのオプションのファイルが含まれています.パッケージで使 用しないこれらのファイルに対する`Makefile.in'ルールは削除してくださ い.
`${srcdir}/'プレフィクスはVPATH
メカニズムの制限のため含
まれています.
`config.h.in'と`config.h'のタイムスタンプは,内容が変化しな
い場合には変化しないので,`stamp-'ファイルが必要です.この機能は
不必要な再コンパイルを避けます.パッケージの配布物に`stamp-h.in'
を含めるべきで,そうすることでmake
は`config.h.in'が最新だ
ということを考慮します.@command{touch} (see section 通常のツールの制限)を使用せず,代わりに@command{echo}を使用してください
(@command{date}を使用すると不必要な差異を生じ,@acronym{CVS}で矛盾した
りするでしょう).
$(srcdir)/configure: configure.ac 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.ac aclocal.m4 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
この行を直接`Makefile'にコピーするときは,インデントされた行がタ ブ文字で始まるように置換する必要があるので注意してください.)
更に,`AC_CONFIG_FILES([stamp-h], [echo timestamp > stamp-h])'を
使用すべきで,そうすることで`config.status'は`config.h'が最
新であることを確かめます.AC_OUTPUT
の詳細は,See section 出力ファイルを生成する.
依存性に関係するコンフィグレーションの例は,See section コンフィグレーションの再生成.
パッケージに二,三個以上のCプリプロセッサのシンボルのテストが含まれて
いるとき,コマンドラインでコンパイラに渡す`-D'オプションはかなり
長くなります.これは二つの問題があります.一つは,@command{make}の出力
のエラーを探すとき,見て分からなくなることです.更に深刻な問題は,コマ
ンドラインがいくつかのオペレーティングシステムの長さの制限を越えること
です.コンパイラに`-D'オプションを渡す代わりに,
@command{configure}スクリプトで`#define'ディレクティブを含んでい
るCヘッダファイルを作成することが可能です.AC_CONFIG_HEADER
マク
ロで,この出力を選択します.それは,AC_INIT
の直後に呼び出します.
(例えば,const
を再定義する場合)宣言の不一致を防ぐために,パッケー
ジでは,あらゆる他のヘッダの前で,コンフィグレーションヘッダファイルを
`#include'すべきです.`#include "config.h"'の代わりに
`#include <config.h>'を使用し,Cコンパイラに`-I.'オプション
(または`-I..'.`config.h'がある方)を渡してください.そうする
ことで,(おそらく配布物を作成するときに)ソースディレクトリがコンフィグ
レーションされても,他のビルドディレクトリは,ソースディレクトリから
`config.h'を探すことなく,コンフィグレーション可能になります.
AC_OUTPUT
は,
#define
宣言のCプリプロセッサを含んでいるheaderの空白で区
切られたリストを作成し,生成されたファイルの`@DEFS@'を,
DEFS
の値の代わりに,@option{-DHAVE_CONFIG_H}で置換します.通常,
headerの名前は`config.h'です.
headerがすでに存在していて,その内容がAC_OUTPUT
が書き込む
ものと同じ場合は,そのまま残ります.こうすることで,ヘッダファイルに依
存するオブジェクトファイルを不必要に再コンパイルする必要がなく,コンフィ
グレーション時に変更を行なうことが可能になります.
通常,入力ファイルは`header.in'と命名されます.しかし,入力 ファイルをコロンで分けた入力ファイルのリストにheaderを加えること で優先可能です.例えば,以下のようにします.
AC_CONFIG_HEADERS([config.h:config.hin]) AC_CONFIG_HEADERS([defines.h:defs.pre:defines.h.in:defs.post])
こうすることで,MS-DOSでアクセスできるままにしたり,常套句をファイルに 前置したり,後置したりすることが可能になります.
headerの詳細は,See section コンフィグレーション作業の実行.
最終的なヘッダファイルが見つかるように,コメントとフックとして使用され
る#undef
宣言を含んでいるテンプレートファイルを,配布物に含める
べきです.例えば,`configure.ac'で以下のように呼び出します.
AC_CONFIG_HEADERS([conf.h]) AC_CHECK_HEADERS([unistd.h])
`conf.h.in'で以下のようなコードを書きます.`unistd.h'がある システムでは,@command{configure}は`#define' `HAVE_UNISTD_H' を1にします.それ以外のシステムでは,行全体がコメントアウトされます(そ のシステムの場合,シンボルは前もって定義されません).
/* Define as 1 if you have unistd.h. */ #undef HAVE_UNISTD_H
`#undef'が最初の列にあり,`HAVE_UNISTD_H'の後に空白すらない ことに注意してください.その後で,プリプロセッサ命令を使用しているコン フィグレーションヘッダをデコードすることが可能です.
#include <conf.h> #if HAVE_UNISTD_H # include <unistd.h> #else /* We are in trouble. */ #endif
`#undef'の代わりに`#define'を用いている,古い形式のテンプレー トの使用は,強く反対します.`#undef'と同じ行にコメントがある古い テンプレートも同様です.とにかく,プロセッサマクロにコメントを書くのは, 決してよい考えではありません.
テンプレートヘッダを更新し続けることは退屈な作業なので,それを生成する ために@command{autoheader}してもかまいません.section @file{config.h.in}を生成するため@command{autoheader}を使用する を参照してください.
@command{autoheader}プログラムは,@command{configure}が使用するためのC
の`#define'宣言のテンプレートファイルを作成することが可能です.
`configure.ac'でAC_CONFIG_HEADERS(file)
を呼び出す場
合,@command{autoheader}は`file.in'を作成します.複数のファ
イルが引数で与えられている場合,最初のファイルを使用します.それ以外の
場合,@command{autoheader}は`config.h.in'を作成します.
この作業を行なうために,使用する可能性がある全てのシンボルを記述するこ
とを@command{autoheader}は必要とします.すなわち,少なくとも,一つの
AC_DEFINE
かAC_DEFINE_UNQUOTED
が,それぞれのシンボルに対
して三番目の引数を用いて呼び出されている必要があります(see section Cプリプロセッサシンボルの定義).更に,AC_DEFINE
の最初の引数をリテラルにする必要があ
るという制約があります.Autoconfの組み込みテストで定義されている全ての
シンボルは,既に適切に記述されているということに注意してください.独自
に定義したものだけ記述する必要があります.
@command{autoheader}がなぜ必要か不思議に思うかもしれません.つまり,な ぜ@command{configure}は,スクラッチから`config.h'を作成する代わり に,`config.h'を生成するために`config.h.in'への"patch"を必 要とするのでしょうか?さて,全てがロックされたとき, @command{autoheader}を管理している時間が無駄になるというのが答えです. 直接`config.h'を生成することが,必要なことの全てです.しかし,う まくいかないときは,@command{autoheader}の存在に感謝することになるでしょ う.
シンボルが記述されているという事実は,`config.h'に意味があること
を調査するために重要です.#define
される(またはされない)
シンボルがうまく定義されているリストがあるという事実もまた,
@command{configure}が実行不可能な環境にパッケージを移植している人には
重要です.彼らは,空白で埋め尽くす必要しかありません.
では,要点に戻りましょう.@command{autoheader}の呼び出し...
引数を@command{autoheader}に与えた場合,`configure.ac'の代わりに そのファイルを使用し,`config.h.in'の代わりに標準出力にヘッダファ イルを書き出します.`-'引数を@command{autoheader}に与えた場合, `configure.ac'の代わりに標準入力から読み込み,標準出力にヘッダファ イルを書き出します.
@command{autoheader}は以下のオプションを受け入れます.
@command{autoheader}は`configure.ac'を調査し,定義されているCプリ
プロセッサシンボルを判定します.それは,AC_CHECK_HEADERS
や
AC_CHECK_FUNCS
等が定義しているシンボルに対するテンプレートを生
成する方法は知っていますが,あらゆる追加のシンボルをAC_DEFINE
し
ている場合,それに対するテンプレートを定義する必要があります.テンプレー
トが無い場合,@command{autoheader}はエラーメッセージとともに失敗します.
symbolに対するテンプレートを作成する最も簡単な方法は, `AC_DEFINE(symbol)'の引数にdescriptionを与えることで す.section Cプリプロセッサシンボルの定義を参照してください.以下のマクロの一つを使用 することも可能です.
AC_DEFINE
されることが可能
なシンボルにすべきです.
例えば以下のようにします.
AH_VERBATIM([_GNU_SOURCE], [/* Enable GNU extensions on systems that have them. */ #ifndef _GNU_SOURCE # define _GNU_SOURCE #endif])
AC_DEFINE
のような,標準的なテンプレートを生成します.
例えば,以下のようにします.
AH_TEMPLATE([CRAY_STACKSEG_END], [Define to one of _getb67, GETB67, getb67 for Cray-2 and Cray-YMP systems. This function is required for alloca.c support on those systems.])
これは,適切に正当化された記述を用いて,以下のテンプレートを生成します.
/* Define to one of _getb67, GETB67, getb67 for Cray-2 and Cray-YMP systems. This function is required for alloca.c support on those systems. */ #undef CRAY_STACKSEG_END
`config.status'の実行前,実行中,そして実行後のいずれかに任意のコ
マンドを実行することが可能です.以下の三つのマクロは,複数回呼び出され
たとき,実行するコマンドを累積していきます.AC_CONFIG_COMMANDS
は時代遅れのマクロAC_OUTPUT_COMMANDS
の置換物です.詳細は,
section 時代遅れのマクロを参照してください.
非現実的な例ですが,以下のようにします.
fubar=42 AC_CONFIG_COMMANDS([fubar], [echo this is extra $fubar, and so on.], [fubar=$fubar])
以下はましなものです.
AC_CONFIG_COMMANDS([time-stamp], [date >time-stamp])
テストの結果によって,対象物へのリンクを作成することが便利だと分かるで
しょう.AC_CONFIG_COMMANDS
を使用することも可能ですが,相対的な
シンボリックリンクを作成することで,パッケージがソースディレクトリとは
異なるディレクトリでビルドされるときに決定することが可能です.
AC_OUTPUT
で,それぞれの既存のファイルsourceから対応するリ
ンク名destにリンクを作成します.可能な場合はシンボリックリンクを
作成し,それ以外ではハードリンクを作成し,それ以外ではコピーします.
destとsourceの名前は,ソースやビルドディレクトリのトップレ
ベルからの相対的なものにすべきです.このマクロは,実際にファイルを作成
するマクロの一つです.section コンフィグレーション作業の実行を参照してください.
例えば,以下のように呼び出します.
AC_CONFIG_LINKS(host.h:config/$machine.h object.h:config/$obj_format.h)
これで,現在のディレクトリに`srcdir/config/$machine.h'への リンク`host.h'と,`srcdir/config/$obj_format.h'へのリ ンク`object.h'を作成します.
destに対して使用したい値`.'は有効ではありません.そうすると, `config.status'で作成するリンクを推定することが不可能になります.
すると,以下のように実行できるでしょう.
./config.status host.h object.h
これでリンクを作成します.
ほとんどの場合,AC_OUTPUT
を呼び出すことで,サブディレクトリの
`Makefile'を作成するためには十分です.しかし,一つ以上の独立した
パッケージを制御する@command{configure}スクリプトで,サブディレクトリ
の他のパッケージの@command{configure}スクリプトを実行するために
AC_CONFIG_SUBDIRS
を使用することが可能です.
AC_OUTPUT
に@command{configure}を実行させます.それ
ぞれのdirはリテラルにすべきです.すなわち,以下のように使用しな
いでください.
if test "$package_foo_enabled" = yes; then $my_subdirs="$my_subdirs foo" fi AC_CONFIG_SUBDIRS($my_subdirs)
これは`./configure --help=recursive'でのパッケージfoo
のオ
プション表示を妨げるためです.その代わりに以下のように書くべきです.
if test "$package_foo_enabled" = yes; then AC_CONFIG_SUBDIRS(foo) fi
該当するdirが見つからない場合でもエラーを報告しません.サブディ レクトリがオプションの場合,以下のように書いてください.
if test -d $srcdir/foo; then AC_CONFIG_SUBDIRS(foo) fi
該当するdirに`configure.gnu'が含まれている場合,
@command{configure}の代わりにそれを実行します.これは,Autoconfスクリ
プトではない@command{Configure}を使用しているパッケージに対するもので,
大文字小文字を識別しないファイルシステムでは同じファイルになるので,そ
れを@command{configure}のラッパーとして呼び出すことは不可能です.同様
に,dirが`configure.ac'を含んでいて@command{configure}が無
い場合,AC_CONFIG_AUXDIR
で見つかるCygnusの@command{configure}ス
クリプトが使用されます.
サブディレクトリの@command{configure}スクリプトには,この @command{configure}スクリプトに与えられたものと同じコマンドラインオプ ションが渡され,必要場合は少し変更され,変更されるものには以下のものが 含まれます.
$prefix
の値を,トップレベルとサブ
ディレクトリの`configure'のデフォルト値が異なっている場合でも伝搬
させます.
このマクロは,出力変数subdirs
も,ディレクトリのリスト
`dir...'に設定します.`Makefile'のルールは,この値を
サブディレクトリの定義に再帰的に使用することが可能です.
このマクロは何度でも呼び出し可能です.
@command{configure}はデフォルトで,ファイルをインストールするプレフィ クスを`/usr/local'に設定します.@command{configure}のユーザは,異 なるディレクトリを,`--prefix'と`--exec-prefix'オプションで 選択することが可能です.デフォルトを変更する方法は二つあります. @command{configure}を作成するときと,実行するときです.
デフォルトで,`/usr/local'以外のディレクトリにインストールしたい,
ソフトウェアパッケージもあります.そうするために,
AC_PREFIX_DEFAULT
マクロを使用してください.
ユーザが既にインストールしている関連するプログラムの場所から,
@command{configure}がインストールプレフィクスを推測すると便利かもしれ
ません.そうしたい場合,AC_PREFIX_PROGRAM
を呼び出します.
PATH
でprogramを探し,
その値を推測します.programが見つかった場合,プレフィクスを
programを含むディレクトリの親に設定します.そうでない場合,上記
のもの(`/usr/local'やAC_PREFIX_DEFAULT
)がデフォルトのプレ
フィクスになります.例えば,programがgcc
で,PATH
が
`/usr/local/gnu/bin/gcc' を含んでいる場合,プレフィクスを
`/usr/local/gnu'に設定します.
Go to the first, previous, next, last section, table of contents.