| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Autoconfが生成したconfigureスクリプトは，パッケージのソースファ イルの見つけ方，そして，生成する出力ファイルといった，初期化の方法の情報 を必要とします．以下のセクションで，初期化と出力ファイルの作成について述 べます．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
configureの初期化configureの初期化"へのコメント(無し)
すべてのconfigureスクリプトファイルでは，他の何よりも前に， AC_INITを呼び出す必要があります．そのほかに必要なマクロは AC_OUTPUTだけです(see 節 4.4 出力ファイルを生成する)．
packageの名前とそのversionを設定します．これらは通常， configureに含まれる`--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
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
configureの注意事項configureの注意事項"へのコメント(無し)
以下のマクロは，configureスクリプトのバージョンナンバーを管理 します．それはオプションとして使用されます．
configureの作成に使用されるAutoconfのバージョンが， version以前の場合，標準エラー出力にエラーメッセージを出力し，異常 終了します(終了ステータスは63です)．例えば以下のようにします．
AC_PREREQ(2.59) |
このマクロは，AC_INIT以前に使用可能な唯一のマクロですが，整合性の ためにはそうすべきではありません．
configureについてcopyright-noticeでカバーしたい部分を宣 言してください．
copyright-noticeは，configureの先頭と，`configure --version'の両方で表示されます．
configureスクリプトにコピーします．このマクロは， configureをチェックインしたときにRCSやCVS がリビジョンスタンプを変えなくても，`configure.ac'から configureにそれを書き込みます．そうすることで，特定の configureに対応する`configure.ac'のリビジョンが簡単に決定 可能になります．
例えば，以下の行を`configure.ac'に書いたとします．
AC_REVISION($Revision: 1.30 $) |
これで，configureは以下のようになります．
#! /bin/sh # From configure.ac Revision: 1.30 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
configureの入力を見つけるconfigureの入力を見つける"へのコメント(無し)
configureは，伝えられたディレクトリに実際にソー スコードが含まれていることを確認するために，このファイルの存在を調査しま す．`--srcdir'で間違ったディレクトリを指定してしまう人もいます． これは安全性の調査です．詳細は，See 節 13.9 configureの呼び出し.手動でのコンフィグレーションや，installプログラムを使用するパッケー ジは，デフォルトの位置でほとんど正しいのですが，AC_CONFIG_AUX_DIR を呼び出して，他のシェルスクリプトを探す場所をconfigureに教え る必要があるかもしれません．
configureスクリプト)を使用します．dirは，絶対パスまたは `srcdir'の相対パスが可能です．デフォルトは `srcdir'または`srcdir/..'または `srcdir/../..'で，`install-sh'を含んでいる最初にところで す．他のファイルは調査しないので，AC_PROG_INSTALLを使用することで， 他の補助ファイルを配布する必要は自動的になくなります．また，それは `install.sh'も調査しますが，makeプログラムには， `Makefile'が無い場合，それから`install'を作るルールを持ってい るものあるので，その名前は時代遅れです．同様に，aclocalを使用しているパッケージでは，ローカルマクロが 見つかる場所をAC_CONFIG_MACRO_DIRを使用して宣言すべきです．
autopoint，libtoolize， aclocal，そしてautoreconfは，ディレクトリdirを， 追加のローカルなAutoconfマクロがある場所として使用します．このマクロを， aclocalに対してインストールされているマクロがあるツールで， `--trace'が安全に呼び出される前に宣言が見つかるように，直接 `configure.ac'から確実に呼び出して下さい．| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
すべてのAutoconfスクリプト，例えば`configure.ac'は， AC_OUTPUTの呼び出しで終えるべきです．それは，コンフィグレーション の結果生成される`Makefile'とその他のファイルを生成する， `config.status'を生成し実行するマクロです．AC_INIT以外で唯一 必要とされるマクロです(see 節 4.3 configureの入力を見つける)．
`config.status'は，全てのコンフィグレーション作業を実行します．全て の出力ファイル(4.6 コンフィグレーションファイルの作成とマクロAC_CONFIG_FILESを 参照してください)，ヘッダファイル(4.9 任意のコンフィグレーションコマンドの実行とマクロ AC_CONFIG_COMMANDSを参照してください)，コマンド (4.9 任意のコンフィグレーションコマンドの実行とマクロAC_CONFIG_COMMANDSを参照して ください)，リンク(4.10 コンフィグレーションのリンクを作成するとマクロ AC_CONFIG_LINKSを参照してください)，サブディレクトリ (4.10 コンフィグレーションのリンクを作成するとマクロAC_CONFIG_LINKSを参照してくださ い)が尊重されます．
AC_OUTPUTを呼び出す場所が，コンフィグレーションの実行をする場所に なります．それ以降のコードは，config.statusが実行された後に， configureによって一度実行されます．動作を(configure が 実行されているかどうかに依存しないように)config.status自身に組 み込みたい場合，Running Arbitrary Configuration Commandsを参照して下さい．
歴史的には，AC_OUTPUTの使用はいくぶん異なっています． AC_OUTPUTがサポートする引数の記述は，See 節 15.4 時代遅れのマクロ.
サブディレクトリでmakeを実行する場合，makeを変数 MAKEを使用して実行すべきです．たいていのバージョンの makeで，MAKEにmakeプログラムと，それに与える あらゆるオプションを追加して設定します．(しかし，その中にコマンドライン で設定された値を含まないものも多いので，それらは自動的に渡されません．) 古いバージョンのmakeには，変数を設定しないものもあります．以下 のマクロでそれらのバージョンでも使用可能になります．
makeがMake変数MAKEを前もって定義している場合，出力変数 SET_MAKEは空で定義されます．それ以外では，SET_MAKEは `MAKE=make'を含みます．SET_MAKEに対してAC_SUBSTを呼び 出して下さい．このマクロを使用する場合，MAKEを実行する他のディレクトリのそれぞ れの`Makefile.in'に以下の行を書き込んで下さい．
@SET_MAKE@ |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
`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]) |
ここでの引数は，以下のとおりです．
tagsとして，リテラルを使用することを勧めます．特に，以下は避けた方 が良いでしょう．
... && 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'のコマンドラインインターフェースを使用しているとき は便利でしょう．詳細は，14. コンフィグレーションの再生成,を参照してくださ い．
inputsは，絶対パスまたは相対パスを用いたファイル名が可能です．後者 の場合，それは最初にビルドツリーで探され，その後でソースツリーで探されま す．
configureの実行中に設定される変数は，ここでは利用不可能 です．それらを最初にinit-cmdsで設定する必要があります．それにもか かわらず，以下の変数は前もって求められます．
srcdirconfigureのオプション`--srcdir'で設定されるもので す．
ac_top_srcdirac_top_builddirac_srcdir現在の(current)ディレクトリは，tagsの一部の入力が含まれるディ レクトリ(または疑似ディレクトリ)を参照します．例えば以下を実行したとしま す．
AC_CONFIG_COMMANDS([deep/dir/out:in/in.in], [...], [...]) |
`--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は同じ名前空間を共 有し，それぞれ予測できない方法で上書きされるかもしれません．残念です ....
当然ですが，すべてのこれらのマクロは，異なるtagを用いると，何回で も呼び出すことが可能です！
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
きちんとこの前の章を読んでくださいね，4.5 コンフィグレーション作業の実行．
AC_OUTPUTでそれぞれの`file'を作成 するようにします． このマクロは，実際に何かを作成するマクロの一つです．4.5 コンフィグレーション作業の実行を参照してください．出力変数を使用することの詳細な情報は， See 節 4.7 Makefileへの代入. それらを作成するための詳細な情報は， See 節 7.2 出力変数の設定. これらのマクロは，存在しない場合はファ イルを配置するディレクトリを作成します．通常，`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が受け入れ可能なままにしたり，ファイル に常套句を前置したり後置したりすることが可能となります．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
コンパイルされたりインストールされたりするものを含んでいる，配布物のそれ ぞれのサブディレクトリには，configureがそのディレクトリに `Makefile'を作成するためのファイル`Makefile.in'を配置すべきで す．`Makefile'を作成するために，`Makefile.in'の `@variable@'をconfigureが決定したその変数の値に置 換しながら，configureは単純な変数の代入を行います．このように して出力ファイルに代入される変数は，出力変数(output variable)と呼 ばれます．それらはconfigureで設定される普通のシェル変数です． configureが特定の変数を出力ファイルに代入するように，変数名を 引数としてAC_SUBSTマクロを呼び出す必要があります．他の変数に対す る`@variable@'が変化することはありません．AC_SUBSTを 用いた出力変数の作成方法の詳細は，See 節 7.2 出力変数の設定.
configureスクリプトを使用しているソフトウェアパッケージは，ファ イル`Makefile.in'と一緒に配布すべきですが，`Makefile'は配布す べきではありません．つまり，ユーザはコンパイルする前にローカルシステムに 対して，正しくパッケージをコンフィグレーションする必要があります．
`Makefile'に書くものの詳細はSee 節 `Makefile Conventions' in
4.7.1 出力変数のプリセット Output variables that are always set 4.7.2 インストールディレクトリの変数 Other preset output variables 4.7.3 ビルドディレクトリ Supporting multiple concurrent compiles 4.7.4 自動的なリメイク Makefile rules for configuring
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Autoconfマクロが前もって設定する出力変数もあります．追加の出力変数を設定 するAutoconfマクロもあり，それは，それらのマクロの記述で言及されています． 出力変数の完全なリストは，See 節 B.2 出力変数の索引. 以下はそれぞれ， それ以外のプリセットされたもののリストです．それらは全て大切な値です (see 節 7.2 出力変数の設定, AC_ARG_VAR)．
configureを実行するときに環境変数で設定されていない場合， AC_PROG_CCを呼び出すときにデフォルト値が設定されます(そうでない場 合は空になります)．Cの特徴をテストするためのプログラムをコンパイルすると き，configureはこの変数を使用します．configureによって自動的に生成されるファイルを告げ，入力ファイ ル名を与えるコメントです．AC_OUTPUTは，それが作成するすべての `Makefile'の最初に，この変数を含むコメント行を加えます．それ以外の ファイルは，それぞれの入力ファイルの最初のコメントで，この変数を参照すべ きです．例えば，入力シェルスクリプトの最初は以下のようにすべきです．
#! /bin/sh # @configure_input@ |
またその行の存在で，ファイルを編集している人は，configureを使 用して処理する必要があることを思い出します．
configure を実行するときに環境変数で設定されていない場合，デフォルト値は空になりま す． configureは，Cの特徴をテストするプログラムのコンパイルや プリプロセス時にこの変数を使用します．configure を実行するときに環境変数で設定されていない場合，AC_PROG_CXXを呼び 出したときにデフォルト値に設定されます(そうでない場合は空になります)． configureは，C++の特徴をテストするプログラムのコンパイル時に， この変数を使用します．AC_CONFIG_HEADERが呼び 出されている場合，configureは`@DEFS@'の代わりに `-DHAVE_CONFIG_H'に置換します(see 節 4.8 コンフィグレーションヘッダファイル)．この 変数は，configureがテストを実行している間は定義されず，出力ファ イルを作成するときだけ定義されます．前のテストの結果を調査する方法は， See 節 7.2 出力変数の設定.echoに後置される改行を抑制す る方法は？これらの変数は，その方法を提供します．
echo $ECHO_N "And the winner is... $ECHO_C"
sleep 00
echo "${ECHO_T}dead."
|
古く一般的でないechoの実装では，これを達成する意味が無いものもあ り，その場合，ECHO_Tはタブをに設定されます．そうしたくないかもし れません．
configureの実行時に環境変数で設定されていない場合， AC_PROG_FCの予備出し時デフォルト値が設定されます(またはそうなけれ ば空になります)．configureは，Fortranの特徴を調査するプログラ ムをコンパイルするとき，この変数を使用します．configureを実行するときに環境変数で設定されていない場合， AC_PROG_F77を呼び出したときデフォルト値に設定されます(そうでない 場合は空になります)．configureは，Fortran 77の特徴をテストする プログラムのコンパイル時に，この変数を使用します．configureを実行するときに環境変数で設定され ていない場合，デフォルト値は空になります．configureは，C，C++， そしてFortranの特徴をテストするプログラムのリンク時に，この変数を使用し ます．configureは，C，C++，そしてFortranの特徴をテストするプログラム のリンク時に，この変数を使用します．builddirの絶対パスです．builddirと同じです．top_builddirの絶対パスです．srcdirの絶対パスです．srcdirと同じです．top_srcdirの絶対パスです．| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
以下の変数は，パッケージがインストールされる場所を指定します．詳細は， 節 `Variables for Installation Directories' in
これらの変数のほとんどは，prefixやexec_prefixに依存する値 になります．ディレクトリ変数の出力値が展開されないように考慮されています． 典型的な例として，`@datadir@'は，`/usr/local/share' ではなく `${prefix}/share'に置換されます．
以下の動作は，GNU coding standardsで示されれていて，ユーザが実 行時にそうなるようになっています．
configureに指定されるものとは異なるプレフィクスを指定すること がまだ可能で，その場合に必要があれば，パッケージはmakeで指定されているプ レフィクスに対応するように依存性がハードコード化されます．
これらの機能をサポートするために，datadirがprefixの現在の 値に依存する`${prefix}/share'として定義されたままになっていること が重要です．
当然のことですが，これらの変数を`Makefiles'で使用すべきではありませ ん．例えば，`configure'でdatadirを評価する代わりに， `Makefile'で，例えば`AC_DEFINE_UNQUOTED(DATADIR, "$datadir")' としてハードコードする場合は，`-DDATADIR="$(datadir)"'を CPPFLAGSに加えるべきです．
同様に，datadirとその仲間を，シェルスクリプトやその他のファイルで 置換するために，AC_OUTPUT_FILESに頼るべきではなく，その代わりに 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
|
注目すべきことがいくつかあります．
configureが`@datadir@'をsedの式自身に 置換することを妨げます．
sedの式で`/'を使用しないでください．
editは，コンフィグレーション特有の値(prefix等)に依存し， VERSIONやそれの以前のものには依存しない値を使用するので，出力は `configure.ac'ではなく`Makefile'に依存します．
autoconf autoheader: Makefile
.in:
rm -f $@ [email protected]
$(edit) $< >[email protected]
chmod +x [email protected]
mv [email protected] $@
|
詳細は，See 節 10.11 Makeの制限.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
同じソースコードのコピーから，同時に複数のアーキテクチャに対するソフトウェ アパッケージのコンパイルをサポートすることが可能です．それぞれのアーキテ クチャに対するオブジェクトファイルは，それ自身のディレクトリに保存されま す．
これをサポートするために，makeは，ソースディレクトリにあるファ イルを見つけるためVPATH変数を使用します．GNU Makeとその 他のほとんどの最近のmakeプログラムはこうすることが可能です．もっ と古いmakeプログラムは，VPATHをサポートしていません．そ れを使用するときは，ソースコードをオブジェクトファイルと同じディレクトリ 置く必要があります．
VPATHをサポートするため，それぞれの`Makefile.in'には，以下の ような二行が必要です．
srcdir = @srcdir@ VPATH = @srcdir@ |
VPATHの値に変数を代入しないmakeのバージョンもあるので， VPATHに他の値，例えば`VPATH = $(srcdir)'を設定しないでくださ い．
configureは`Makefile'を作成するとき，srcdirに正し い値を代入します．
暗黙のルールを期待して，(VPATHで見つかる)ソースディレクトリのファ イルのパス名を展開するmake変数の$<を使用しないでくださ い．(暗黙のルールとは，`.c'ファイルから`.o'ファイルを作成する 方法を教える`.c.o'の様なものです．)暗黙のルールで$<を設定し ないバージョンのmakeもあり，それは，空の値で展開します．
その代わり，`Makefile'コマンドラインは，ソースファイルを `$(srcdir)/'を前置して参照します．例えば以下のようにします．
time.info: time.texinfo
$(MAKEINFO) $(srcdir)/time.texinfo
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
コンフィグレーションファイルを変更したとき自動的にコンフィグレーション情 報を更新するため，パッケージに対するトップレベルの`Makefile.in' に 以下のようなルールを書くことが可能でます．以下の例には， `aclocal.m4'やそれらが関連するるコンフィグレーションヘッダファイル のような，全てのオプションのファイルが含まれています．パッケージで使用し ないこれらのファイルに対する`Makefile.in'ルールは削除してください．
`${srcdir}/'プレフィクスはVPATHメカニズムの制限のため含ま れています．
`config.h.in'と`config.h'のタイムスタンプは，内容が変化しない 場合には変化しないので，`stamp-'ファイルが必要です．この機能は不必 要な再コンパイルを避けます．パッケージの配布物に`stamp-h.in' を含め るべきで，そうすることでmakeは`config.h.in'が最新だというこ とを考慮します．touch (see 節 10.10 通常のツールの制限)を使 用せず，代わりにechoを使用してください(dateを使用す ると不必要な差異を生じ，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 節 4.4 出力ファイルを生成する.
依存性に関係するコンフィグレーションの例は，See 節 14. コンフィグレーションの再生成.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
パッケージに二，三個以上のCプリプロセッサのシンボルのテストが含まれてい るとき，コマンドラインでコンパイラに渡す`-D'オプションはかなり長く なります．これは二つの問題があります．一つは，makeの出力のエラー を探すとき，見て分からなくなることです．更に深刻な問題は，コマンドライン がいくつかのオペレーティングシステムの長さの制限を越えることです．コンパ イラに`-D'オプションを渡す代わりに， configureスクリプト で`#define'ディレクティブを含んでいるCヘッダファイルを作成すること が可能です．AC_CONFIG_HEADERマクロで，この出力を選択します．それ は，AC_INITの直後に呼び出します．
(例えば，constを再定義する場合)宣言の不一致を防ぐために，パッケー ジでは，あらゆる他のヘッダの前で，コンフィグレーションヘッダファイルを `#include'すべきです．`#include "config.h"'の代わりに `#include
AC_OUTPUTは， #define宣言のCプリプロセッサを含んでいるheaderの空白で区切 られたリストを作成し，生成されたファイルの`@DEFS@'を，DEFS の値の代わりに，`-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 節 4.5 コンフィグレーション作業の実行.
4.8.1 コンフィグレーションヘッダのテンプレート Input for the configuration headers 4.8.2 `config.h.in'を生成するため autoheaderを使用するHow to create configuration templates 4.8.3 autoheaderのマクロ How to specify CPP templates
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
最終的なヘッダファイルが見つかるように，コメントとフックとして使用される #undef宣言を含んでいるテンプレートファイルを，配布物に含めるべき です．例えば，`configure.ac'で以下のように呼び出します．
AC_CONFIG_HEADERS([conf.h]) AC_CHECK_HEADERS([unistd.h]) |
`conf.h.in'で以下のようなコードを書きます．`unistd.h'があるシ ステムでは，configureは`#define' `HAVE_UNISTD_H' を1 にします．それ以外のシステムでは，行全体がコメントアウトされます(そのシ ステムの場合，シンボルは前もって定義されません)．
/* Define as 1 if you have unistd.h. */ #undef HAVE_UNISTD_H |
`#undef'が最初の列にあり，`HAVE_UNISTD_H'の後に空白すらないこ とに注意してください．その後で，プリプロセッサ命令を使用しているコンフィ グレーションヘッダをデコードすることが可能です．
#include |
`#undef'の代わりに`#define'を用いている，古い形式のテンプレー トの使用は，強く反対します．`#undef'と同じ行にコメントがある古いテ ンプレートも同様です．とにかく，プロセッサマクロにコメントを書くのは，決 してよい考えではありません．
テンプレートヘッダを更新し続けることは退屈な作業なので，それを生成するた めにautoheaderしてもかまいません．4.8.2 `config.h.in'を生成するためautoheaderを使用する を参照してください．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
autoheaderを使用するautoheaderを使用する"へのコメント(無し)
autoheaderプログラムは，configureが使用するためのC の`#define'宣言のテンプレートファイルを作成することが可能です． `configure.ac'でAC_CONFIG_HEADERS(file)を呼び出す場合， autoheaderは`file.in'を作成します．複数のファイルが 引数で与えられている場合，最初のファイルを使用します．それ以外の場合， autoheaderは`config.h.in'を作成します．
この作業を行なうために，使用する可能性がある全てのシンボルを記述すること をautoheaderは必要とします．すなわち，少なくとも，一つの AC_DEFINEかAC_DEFINE_UNQUOTEDが，それぞれのシンボルに対し て三番目の引数を用いて呼び出されている必要があります(see 節 7.1 Cプリプロセッサシンボルの定義)．更に，AC_DEFINEの最初の引数をリテラルにする必要がある という制約があります．Autoconfの組み込みテストで定義されている全てのシン ボルは，既に適切に記述されているということに注意してください．独自に定義 したものだけ記述する必要があります．
autoheaderがなぜ必要か不思議に思うかもしれません．つまり，なぜ configureは，スクラッチから`config.h'を作成する代わりに， `config.h'を生成するために`config.h.in'への"patch"を必要とす るのでしょうか？さて，全てがロックされたとき，autoheaderを管理 している時間が無駄になるというのが答えです．直接`config.h'を生成す ることが，必要なことの全てです．しかし，うまくいかないときは， autoheaderの存在に感謝することになるでしょう．
シンボルが記述されているという事実は，`config.h'に意味があることを 調査するために重要です．#defineされる(またはされない) シン ボルがうまく定義されているリストがあるという事実もまた， configureが実行不可能な環境にパッケージを移植している人には重 要です．彼らは，空白で埋め尽くす必要しかありません．
では，要点に戻りましょう．autoheaderの呼び出し...
引数をautoheaderに与えた場合，`configure.ac'の代わりにそ のファイルを使用し，`config.h.in'の代わりに標準出力にヘッダファイル を書き出します．`-'引数をautoheaderに与えた場合， `configure.ac'の代わりに標準入力から読み込み，標準出力にヘッダファ イルを書き出します．
autoheaderは以下のオプションを受け入れます．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
autoheaderは`configure.ac'を調査し，定義されているCプリプ ロセッサシンボルを判定します．それは，AC_CHECK_HEADERSや AC_CHECK_FUNCS等が定義しているシンボルに対するテンプレートを生成 する方法は知っていますが，あらゆる追加のシンボルをAC_DEFINEしてい る場合，それに対するテンプレートを定義する必要があります．テンプレートが 無い場合，autoheaderはエラーメッセージとともに失敗します．
symbolに対するテンプレートを作成する最も簡単な方法は， `AC_DEFINE(symbol)'の引数にdescriptionを与えることです． 7.1 Cプリプロセッサシンボルの定義を参照してください．以下のマクロの一つを使用するこ とも可能です．
autoheaderに，templateをそのままヘッダテンプレートファイ ルに含めるよう伝えます．このtemplateはkeyに関連付けされてい て，それは全ての異なるテンプレートを並べ替えし，それらのユニーク性を保証 するために使用されます．それは，AC_DEFINEされることが可能なシンボ ルにすべきです．
例えば以下のようにします．
AH_VERBATIM([_GNU_SOURCE], [/* Enable GNU extensions on systems that have them. */ #ifndef _GNU_SOURCE # define _GNU_SOURCE #endif]) |
autoheaderに，keyに対するテンプレートを生成するように伝 えます．このマクロは，descriptionが与えられたときの 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 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
`config.status'の実行前，実行中，そして実行後のいずれかに任意のコマ ンドを実行することが可能です．以下の三つのマクロは，複数回呼び出されたと き，実行するコマンドを累積していきます．AC_CONFIG_COMMANDS は時代 遅れのマクロAC_OUTPUT_COMMANDSの置換物です．詳細は，15.4 時代遅れのマクロを参照してください．
configureからのあらゆる変数を初期化するためのシェルコマンドを を追加します．コマンドをtagに関連付けます．通常，cmdsはファ イルを作成するので，tagは自ずからファイル名にすべきでしょう．実際， tagに書かれているディレクトリが作製されます．このマクロは，実際に ファイルを作成するマクロです．4.5 コンフィグレーション作業の実行を参照してくだ さい．
非現実的な例ですが，以下のようにします．
fubar=42
AC_CONFIG_COMMANDS([fubar],
[echo this is extra $fubar, and so on.],
[fubar=$fubar])
|
以下はましなものです．
AC_CONFIG_COMMANDS([time-stamp], [date >time-stamp]) |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
テストの結果によって，対象物へのリンクを作成することが便利だと分かるでしょ う．AC_CONFIG_COMMANDSを使用することも可能ですが，相対的なシンボ リックリンクを作成することで，パッケージがソースディレクトリとは異なるディ レクトリでビルドされるときに決定することが可能です．
AC_OUTPUTで，それぞれの既存のファイルsourceから対応するリン ク名destにリンクを作成します．可能な場合はシンボリックリンクを作成 し，それ以外ではハードリンクを作成し，それ以外ではコピーします． destとsourceの名前は，ソースやビルドディレクトリのトップレベ ルからの相対的なものにすべきです．このマクロは，実際にファイルを作成する マクロの一つです．4.5 コンフィグレーション作業の実行を参照してください．
例えば，以下のように呼び出します．
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 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
ほとんどの場合，AC_OUTPUTを呼び出すことで，サブディレクトリの `Makefile'を作成するためには十分です．しかし，一つ以上の独立したパッ ケージを制御するconfigureスクリプトで，サブディレクトリの他の パッケージのconfigureスクリプトを実行するために AC_CONFIG_SUBDIRSを使用することが可能です．
AC_OUTPUTに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'が含まれている場合， configureの代わりにそれを実行します．これは，Autoconfスクリプ トではないConfigureを使用しているパッケージに対するもので，大 文字小文字を識別しないファイルシステムでは同じファイルになるので，それを configureのラッパーとして呼び出すことは不可能です．同様に， dirが`configure.ac'を含んでいてconfigureが無い場合， AC_CONFIG_AUXDIRで見つかるCygnusのconfigureスクリプトが 使用されます．
サブディレクトリのconfigureスクリプトには，この configureスクリプトに与えられたものと同じコマンドラインオプショ ンが渡され，必要場合は少し変更され，変更されるものには以下のものが含まれ ます．
$prefixの値を，トップレベルとサブディ レクトリの`configure'のデフォルト値が異なっている場合でも伝搬させま す．このマクロは，出力変数subdirsも，ディレクトリのリスト `dir...'に設定します．`Makefile'のルールは，この値を サブディレクトリの定義に再帰的に使用することが可能です．
このマクロは何度呼び出してもかまいません．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
configureはデフォルトで，ファイルをインストールするプレフィク スを`/usr/local'に設定します．configureのユーザは，異なる ディレクトリを，`--prefix'と`--exec-prefix'オプションで選択す ることが可能です．デフォルトを変更する方法は二つあります． configureを作成するときと，実行するときです．
デフォルトで，`/usr/local'以外のディレクトリにインストールしたい， ソフトウェアパッケージもあります．そうするために， AC_PREFIX_DEFAULTマクロを使用してください．
ユーザが既にインストールしている関連するプログラムの場所から， configureがインストールプレフィクスを推測すると便利かもしれま せん．そうしたい場合，AC_PREFIX_PROGRAMを呼び出します．
PATHでprogramを探し，そ の値を推測します．programが見つかった場合，プレフィクスを programを含むディレクトリの親に設定します．そうでない場合，上記の もの(`/usr/local'やAC_PREFIX_DEFAULT)がデフォルトのプレフィ クスになります．例えば，programがgccで，PATHが `/usr/local/gnu/bin/gcc' を含んでいる場合，プレフィクスを `/usr/local/gnu'に設定します．| [ << ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |