4. 出力ファイルの初期化

Autoconfが生成したconfigureスクリプトは，パッケージのソースファ イルの見つけ方，そして，生成する出力ファイルといった，初期化の方法の情報 を必要とします．以下のセクションで，初期化と出力ファイルの作成について述 べます．

4.1 configureの初期化

すべてのconfigureスクリプトファイルでは，他の何よりも前に， AC_INITを呼び出す必要があります．そのほかに必要なマクロは AC_OUTPUTだけです(see section 出力ファイルを生成する)．

Macro: AC_INIT (package, version, [bug-report], [tarname])

あらゆるコマンドライン引数を処理し，様々な初期化と検証を実行します．

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

そのままpackageになります．

AC_PACKAGE_TARNAME, PACKAGE_TARNAME

そのままtarnameになります．

AC_PACKAGE_VERSION, PACKAGE_VERSION

そのままversionになります．

AC_PACKAGE_STRING, PACKAGE_STRING

そのまま`package version'になります．

AC_PACKAGE_BUGREPORT, PACKAGE_BUGREPORT

そのままbug-reportになります．

4.2 configureの注意事項

以下のマクロは，configureスクリプトのバージョンナンバーを管理 します．それはオプションとして使用されます．

Macro: AC_PREREQ (version)

使用しているAutoconfのバージョンが十分新しいことを保証します． configureの作成に使用されるAutoconfのバージョンが， version以前の場合，標準エラー出力にエラーメッセージを出力し，異常 終了します(終了ステータスは63です)．例えば以下のようにします．

AC_PREREQ(2.59)

このマクロは，AC_INIT以前に使用可能な唯一のマクロですが，整合性の ためにはそうすべきではありません．

Macro: AC_COPYRIGHT (copyright-notice)

AutoconfマクロへのFree Software Foundationの著作権に加えて， configureについてcopyright-noticeでカバーしたい部分を宣 言してください．

copyright-noticeは，configureの先頭と，`configure --version'の両方で表示されます．

Macro: AC_REVISION (revision-info)

リビジョンスタンプrevision-infoを，ドル記号やダブルクォートを削除 して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

4.3 configureの入力を見つける

Macro: AC_CONFIG_SRCDIR (unique-file-in-source-dir)

unique-file-in-source-dirは，パッケージのソースディレクトリにある ファイルです．configureは，伝えられたディレクトリに実際にソー スコードが含まれていることを確認するために，このファイルの存在を調査しま す．`--srcdir'で間違ったディレクトリを指定してしまう人もいます． これは安全性の調査です．詳細は，See section configureの呼び出し.

手動でのコンフィグレーションや，installプログラムを使用するパッケー ジは，デフォルトの位置でほとんど正しいのですが，AC_CONFIG_AUX_DIR を呼び出して，他のシェルスクリプトを探す場所をconfigureに教え る必要があるかもしれません．

Macro: AC_CONFIG_AUX_DIR (dir)

ディレクトリdirにある補助的なビルドツール(例えば， `install-sh'，`config.sub'， `config.guess'，そしてCygnus configureスクリプト)を使用します．dirは，絶対パスまたは `srcdir'の相対パスが可能です．デフォルトは `srcdir'または`srcdir/..'または `srcdir/../..'で，`install-sh'を含んでいる最初にところで す．他のファイルは調査しないので，AC_PROG_INSTALLを使用することで， 他の補助ファイルを配布する必要は自動的になくなります．また，それは `install.sh'も調査しますが，makeプログラムには， `Makefile'が無い場合，それから`install'を作るルールを持ってい るものあるので，その名前は時代遅れです．

同様に，aclocalを使用しているパッケージでは，ローカルマクロが 見つかる場所をAC_CONFIG_MACRO_DIRを使用して宣言すべきです．

Macro: AC_CONFIG_MACRO_DIR (dir)

将来のバージョンのautopoint，libtoolize， aclocal，そしてautoreconfは，ディレクトリdirを， 追加のローカルなAutoconfマクロがある場所として使用します．このマクロを， aclocalに対してインストールされているマクロがあるツールで， `--trace'が安全に呼び出される前に宣言が見つかるように，直接 `configure.ac'から確実に呼び出して下さい．

4.4 出力ファイルを生成する

すべてのAutoconfスクリプト，例えば`configure.ac'は， AC_OUTPUTの呼び出しで終えるべきです．それは，コンフィグレーション の結果生成される`Makefile'とその他のファイルを生成する， `config.status'を生成し実行するマクロです．AC_INIT以外で唯一 必要とされるマクロです(see section configureの入力を見つける)．

Macro: AC_OUTPUT

`config.status'を生成し，その実行を開始します．`configure.ac' の最後にこのマクロを一度呼び出してください．

`config.status'は，全てのコンフィグレーション作業を実行します．全て の出力ファイル(コンフィグレーションファイルの作成とマクロAC_CONFIG_FILESを 参照してください)，ヘッダファイル(任意のコンフィグレーションコマンドの実行とマクロ AC_CONFIG_COMMANDSを参照してください)，コマンド (任意のコンフィグレーションコマンドの実行とマクロAC_CONFIG_COMMANDSを参照して ください)，リンク(コンフィグレーションのリンクを作成するとマクロ AC_CONFIG_LINKSを参照してください)，サブディレクトリ (コンフィグレーションのリンクを作成するとマクロAC_CONFIG_LINKSを参照してくださ い)が尊重されます．

AC_OUTPUTを呼び出す場所が，コンフィグレーションの実行をする場所に なります．それ以降のコードは，config.statusが実行された後に， configureによって一度実行されます．動作を(configure が 実行されているかどうかに依存しないように)config.status自身に組 み込みたい場合，Running Arbitrary Configuration Commandsを参照して下さい．

歴史的には，AC_OUTPUTの使用はいくぶん異なっています． AC_OUTPUTがサポートする引数の記述は，See section 時代遅れのマクロ.

サブディレクトリでmakeを実行する場合，makeを変数 MAKEを使用して実行すべきです．たいていのバージョンの makeで，MAKEにmakeプログラムと，それに与える あらゆるオプションを追加して設定します．(しかし，その中にコマンドライン で設定された値を含まないものも多いので，それらは自動的に渡されません．) 古いバージョンのmakeには，変数を設定しないものもあります．以下 のマクロでそれらのバージョンでも使用可能になります．

Macro: AC_PROG_MAKE_SET

makeがMake変数MAKEを前もって定義している場合，出力変数 SET_MAKEは空で定義されます．それ以外では，SET_MAKEは `MAKE=make'を含みます．SET_MAKEに対してAC_SUBSTを呼び 出して下さい．

このマクロを使用する場合，MAKEを実行する他のディレクトリのそれぞ れの`Makefile.in'に以下の行を書き込んで下さい．

@SET_MAKE@

4.5 コンフィグレーション作業の実行

`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])

ここでの引数は，以下のとおりです．

tag…

空白で分けられたタグのリストで，それらは通常，実際に作成されるファイル名 です．

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'のコマンドラインインターフェースを使用しているとき は便利でしょう．詳細は，コンフィグレーションの再生成,を参照してくださ い．

inputsは，絶対パスまたは相対パスを用いたファイル名が可能です．後者 の場合，それは最初にビルドツリーで探され，その後でソースツリーで探されま す．

commands

`config.status'にそのまま出力されるシェルコマンドで，実行するコマン ドを`config.status'に伝えるためにユーザが使用することが可能な tagに関連付けされています．tagの要求が`config.status' に与えられるたびにコマンドが実行され，通常はファイル`tag'が作 成されるたびになります．

configureの実行中に設定される変数は，ここでは利用不可能 です．それらを最初にinit-cmdsで設定する必要があります．それにもか かわらず，以下の変数は前もって求められます．

srcdir

ビルドディレクトリのトップからソースディレクトリのトップへのパスです．こ れは，configureのオプション`--srcdir'で設定されるもので す．

ac_top_srcdir

現在のビルドディレクトリからソースディレクトリのトップへのパスです．

ac_top_builddir

現在のビルドディレクトリからビルドディレクトリのトップへのパスです．連結 できるように，それを空にしたり，スラッシュで終えることが可能です．

ac_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'とは無関係です．

init-cmds

`config.status'の先頭付近に引用符で囲まれることなく出力され るシェルコマンドで，`config.status'が実行されるたびに(tag に 関係なく)実行されます．引用符で囲まれていないので，例えば，`$var'は varの値として出力されます．init-cmdsは通常，commands を実行するために必要な同じ変数を`config.status'に与えるために， `configure'で使用されます．

変数名では特に注意すべきです．すべてのinit-cmdsは同じ名前空間を共 有し，それぞれ予測できない方法で上書きされるかもしれません．残念です ....

当然ですが，すべてのこれらのマクロは，異なるtagを用いると，何回で も呼び出すことが可能です！

4.6 コンフィグレーションファイルの作成

きちんとこの前の章を読んでくださいね，コンフィグレーション作業の実行．

Macro: AC_CONFIG_FILES (file…, [cmds], [init-cmds])

出力変数の値を置換しながら入力ファイル(デフォルトは`file.in') をコピーすることで，AC_OUTPUTでそれぞれの`file'を作成 するようにします． このマクロは，実際に何かを作成するマクロの一つです．コンフィグレーション作業の実行を参照してください．出力変数を使用することの詳細な情報は， 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が受け入れ可能なままにしたり，ファイル に常套句を前置したり後置したりすることが可能となります．

4.7 Makefileへの代入

コンパイルされたりインストールされたりするものを含んでいる，配布物のそれ ぞれのサブディレクトリには，configureがそのディレクトリに `Makefile'を作成するためのファイル`Makefile.in'を配置すべきで す．`Makefile'を作成するために，`Makefile.in'の `@variable@'をconfigureが決定したその変数の値に置 換しながら，configureは単純な変数の代入を行います．このように して出力ファイルに代入される変数は，出力変数(output variable)と呼 ばれます．それらはconfigureで設定される普通のシェル変数です． configureが特定の変数を出力ファイルに代入するように，変数名を 引数としてAC_SUBSTマクロを呼び出す必要があります．他の変数に対す る`@variable@'が変化することはありません．AC_SUBSTを 用いた出力変数の作成方法の詳細は，See section 出力変数の設定.

configureスクリプトを使用しているソフトウェアパッケージは，ファ イル`Makefile.in'と一緒に配布すべきですが，`Makefile'は配布す べきではありません．つまり，ユーザはコンパイルする前にローカルシステムに 対して，正しくパッケージをコンフィグレーションする必要があります．

`Makefile'に書くものの詳細はSee (standards)Makefile Conventions section `Makefile Conventions' in The GNU Coding Standards.

4.7.1 出力変数のプリセット

Autoconfマクロが前もって設定する出力変数もあります．追加の出力変数を設定 するAutoconfマクロもあり，それは，それらのマクロの記述で言及されています． 出力変数の完全なリストは，See section 出力変数の索引. 以下はそれぞれ， それ以外のプリセットされたもののリストです．それらは全て大切な値です (see section 出力変数の設定, AC_ARG_VAR)．

Variable: CFLAGS

Cコンパイラに対する，デバッグと最適化のオプションです． configureを実行するときに環境変数で設定されていない場合， AC_PROG_CCを呼び出すときにデフォルト値が設定されます(そうでない場 合は空になります)．Cの特徴をテストするためのプログラムをコンパイルすると き，configureはこの変数を使用します．

Variable: configure_input

configureによって自動的に生成されるファイルを告げ，入力ファイ ル名を与えるコメントです．AC_OUTPUTは，それが作成するすべての `Makefile'の最初に，この変数を含むコメント行を加えます．それ以外の ファイルは，それぞれの入力ファイルの最初のコメントで，この変数を参照すべ きです．例えば，入力シェルスクリプトの最初は以下のようにすべきです．

#! /bin/sh # @configure_input@

またその行の存在で，ファイルを編集している人は，configureを使 用して処理する必要があることを思い出します．

Variable: CPPFLAGS

ヘッダファイルを探すディレクトリ(`-Idir')と，Cプリプロセッサ とCコンパイラに対する，その他の雑多なオプションです．configure を実行するときに環境変数で設定されていない場合，デフォルト値は空になりま す． configureは，Cの特徴をテストするプログラムのコンパイルや プリプロセス時にこの変数を使用します．

Variable: CXXFLAGS

C++コンパイラの，デバッグと最適化のオプションです．configure を実行するときに環境変数で設定されていない場合，AC_PROG_CXXを呼び 出したときにデフォルト値に設定されます(そうでない場合は空になります)． configureは，C++の特徴をテストするプログラムのコンパイル時に， この変数を使用します．

Variable: DEFS

Cコンパイラに渡す`-D'オプションです．AC_CONFIG_HEADERが呼び 出されている場合，configureは`@DEFS@'の代わりに `-DHAVE_CONFIG_H'に置換します(see section コンフィグレーションヘッダファイル)．この 変数は，configureがテストを実行している間は定義されず，出力ファ イルを作成するときだけ定義されます．前のテストの結果を調査する方法は， See section 出力変数の設定.

Variable: ECHO_C

Variable: ECHO_N

Variable: ECHO_T

質問と回答のメッセージの組に対して，echoに後置される改行を抑制す る方法は？これらの変数は，その方法を提供します．

echo $ECHO_N "And the winner is... $ECHO_C" sleep 100000000000 echo "${ECHO_T}dead."

古く一般的でないechoの実装では，これを達成する意味が無いものもあ り，その場合，ECHO_Tはタブをに設定されます．そうしたくないかもし れません．

Variable: FCFLAGS

Fortranコンパイラに対するデバッグと最適化のオプションです． configureの実行時に環境変数で設定されていない場合， AC_PROG_FCの予備出し時デフォルト値が設定されます(またはそうなけれ ば空になります)．configureは，Fortranの特徴を調査するプログラ ムをコンパイルするとき，この変数を使用します．

Variable: FFLAGS

Fortran 77コンパイラの，デバッグと最適化オプションです． configureを実行するときに環境変数で設定されていない場合， AC_PROG_F77を呼び出したときデフォルト値に設定されます(そうでない 場合は空になります)．configureは，Fortran 77の特徴をテストする プログラムのコンパイル時に，この変数を使用します．

Variable: LDFLAGS

strip(`-s')，パス(`-L')，その他のあらゆる雑多なリンカに対す るオプションです．configureを実行するときに環境変数で設定され ていない場合，デフォルト値は空になります．configureは，C，C++， そしてFortranの特徴をテストするプログラムのリンク時に，この変数を使用し ます．

Variable: LIBS

リンカに渡す`-l'オプションです．デフォルト値は空ですが，ライブラリ が見つかり，必要な関数を提供する場合，Autoconfマクロはこの変数に追加のラ イブラリを前置するかもしれません．ライブラリファイルを参照してください． configureは，C，C++，そしてFortranの特徴をテストするプログラム のリンク時に，この変数を使用します．

Variable: builddir

`.'と厳密に等価です．対称性のために追加されました．

Variable: abs_builddir

builddirの絶対パスです．

Variable: top_builddir

現在のビルドツリーのトップレベルへの相対パスです．トップレベルのディレク トリは，ここではbuilddirと同じです．

Variable: abs_top_builddir

top_builddirの絶対パスです．

Variable: srcdir

`Makefile'に対するソースコードを含んでいるディレクトリへの相対パス です．

Variable: abs_srcdir

srcdirの絶対パスです．

Variable: top_srcdir

パッケージのためのソースコードのトップレベルのディレクトリへの相対パスで す．トップレベルのディレクトリは，ここではsrcdirと同じです．

Variable: abs_top_srcdir

top_srcdirの絶対パスです．

4.7.2 インストールディレクトリの変数

以下の変数は，パッケージがインストールされる場所を指定します．詳細は， (standards)Directory Variables section `Variables for Installation Directories' in The GNU Coding Standardsを参照してください．これら の変数を使用するときとその方法の詳細は，このセクションの終りを参照してく ださい．

Variable: bindir

ユーザが実行する実行形式をインストールするディレクトリです．

Variable: datadir

読み込み専用のアーキテクチャに依存しないデータをインストールするディレク トリです．

Variable: exec_prefix

アーキテクチャに依存するファイルをインストールするプレフィクスです．デフォ ルトはprefixと同じです．exec_prefixにいろいろなものを直接イ ンストールすることは避けた方が良いでしょう．しかし，アーキテクチャに依存 するファイルを含むディレクトリに対するデフォルト値は，exec_prefix から相対的なものにすべきです．

Variable: includedir

Cヘッダファイルをインストールするディレクトリです．

Variable: infodir

Info形式のドキュメントをインストールするディレクトリです．

Variable: libdir

オブジェクトコードライブラリをインストールするディレクトリです．

Variable: libexecdir

他のプログラムが実行する，実行可能なプログラムをインストールするディレク トリです．

Variable: localstatedir

修正可能なシングルマシンのデータをインストールするディレクトリです．

Variable: mandir

man形式のドキュメントをインストールするトップレベルのディレクトリです．

Variable: oldincludedir

GCCコンパイラ以外のためのCヘッダファイルをインストールするディレクトリで す．

Variable: prefix

全てのファイルに対する共通のインストールプレフィクスです． exec_prefixが異なる値で定義されている場合，prefixはアーキテ クチャ非依存ファイルに対してのみ使用されます．

Variable: sbindir

システム管理者が実行する実行形式をインストールするディレクトリです．

Variable: sharedstatedir

修正可能な，アーキテクチャに依存しないデータをインストールするディレクト リです．

Variable: sysconfdir

読み込み専用の，シングルマシンのデータをインストールするディレクトリです．

これらの変数のほとんどは，prefixやexec_prefixに依存する値 になります．ディレクトリ変数の出力値が展開されないように考慮されています． 典型的な例として，`@datadir@'は，`/usr/local/share' ではなく `${prefix}/share'に置換されます．

以下の動作は，GNU coding standardsで示されれていて，ユーザが実 行時にそうなるようになっています．

` make'

configureに指定されるものとは異なるプレフィクスを指定すること がまだ可能で，その場合に必要があれば，パッケージはmakeで指定されているプ レフィクスに対応するように依存性がハードコード化されます．

` make install'

異なるインストール位置を指定することが可能で，その場合，パッケージはコン パイルで指定した場所に，まだ依存しているはずです(すなわち， `make install'を実行するときは再コンパイルされません)．お互いにグルー プ化された全てのファイルを，インストール時に決定する人も多いので，これは 非常に重要な特徴で，そこからインストール後に最終的な場所にリンクが張られ ます．

これらの機能をサポートするために，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

注目すべきことがいくつかあります．

` @datadir\@'

バックスラッシュでconfigureが`@datadir@'をsedの式自身に 置換することを妨げます．

` $(pkgdatadir)'

`@pkgdatadir@'を使用しないでください！ 代わりに，makefile変数のマッ チングを使用してください．

` ,'

`$(pkgdatadir)'のように`/'を含んでいる変数を使用することもある ので，sedの式で`/'を使用しないでください．

` `Makefile'への依存性'

editは，コンフィグレーション特有の値(prefix等)に依存し， VERSIONやそれの以前のものには依存しない値を使用するので，出力は `configure.ac'ではなく`Makefile'に依存します．

` 依存性の分割と単一のサフィックスルール'

それらを使用することは不可能です！上記の断片を，(おそらく)以下のように書 き換えることは不可能です.

autoconf autoheader: Makefile .in: rm -f $@ $@.tmp $(edit) $< >$@.tmp chmod +x $@.tmp mv $@.tmp $@

詳細は，See section Makeの制限.

` `$(srcdir)''

ソースへのパスを確実に指定し，そうしない場合はパッケージは分割ビルドをサ ポートしないでしょう．

4.7.3 ビルドディレクトリ

同じソースコードのコピーから，同時に複数のアーキテクチャに対するソフトウェ アパッケージのコンパイルをサポートすることが可能です．それぞれのアーキテ クチャに対するオブジェクトファイルは，それ自身のディレクトリに保存されま す．

これをサポートするために，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

4.7.4 自動的なリメイク

コンフィグレーションファイルを変更したとき自動的にコンフィグレーション情 報を更新するため，パッケージに対するトップレベルの`Makefile.in' に 以下のようなルールを書くことが可能でます．以下の例には， `aclocal.m4'やそれらが関連するるコンフィグレーションヘッダファイル のような，全てのオプションのファイルが含まれています．パッケージで使用し ないこれらのファイルに対する`Makefile.in'ルールは削除してください．

`${srcdir}/'プレフィクスはVPATHメカニズムの制限のため含ま れています．

`config.h.in'と`config.h'のタイムスタンプは，内容が変化しない 場合には変化しないので，`stamp-'ファイルが必要です．この機能は不必 要な再コンパイルを避けます．パッケージの配布物に`stamp-h.in' を含め るべきで，そうすることでmakeは`config.h.in'が最新だというこ とを考慮します．touch (see section 通常のツールの制限)を使 用せず，代わりに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 section 出力ファイルを生成する.

依存性に関係するコンフィグレーションの例は，See section コンフィグレーションの再生成.

4.8 コンフィグレーションヘッダファイル

パッケージに二，三個以上のCプリプロセッサのシンボルのテストが含まれてい るとき，コマンドラインでコンパイラに渡す`-D'オプションはかなり長く なります．これは二つの問題があります．一つは，makeの出力のエラー を探すとき，見て分からなくなることです．更に深刻な問題は，コマンドライン がいくつかのオペレーティングシステムの長さの制限を越えることです．コンパ イラに`-D'オプションを渡す代わりに， configureスクリプト で`#define'ディレクティブを含んでいるCヘッダファイルを作成すること が可能です．AC_CONFIG_HEADERマクロで，この出力を選択します．それ は，AC_INITの直後に呼び出します．

(例えば，constを再定義する場合)宣言の不一致を防ぐために，パッケー ジでは，あらゆる他のヘッダの前で，コンフィグレーションヘッダファイルを `#include'すべきです．`#include "config.h"'の代わりに `#include <config.h>'を使用し，Cコンパイラに`-I.'オプション(ま たは`-I..'．`config.h'がある方)を渡してください．そうすること で，(おそらく配布物を作成するときに)ソースディレクトリがコンフィグレーショ ンされても，他のビルドディレクトリは，ソースディレクトリから `config.h'を探すことなく，コンフィグレーション可能になります．

Macro: AC_CONFIG_HEADERS (header …, [cmds], [init-cmds])

このマクロは，実際にファイルを作成するマクロの一つです． コンフィグレーション作業の実行を参照してください．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 section コンフィグレーション作業の実行.

4.8.1 コンフィグレーションヘッダのテンプレート

最終的なヘッダファイルが見つかるように，コメントとフックとして使用される #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 <conf.h>

#if HAVE_UNISTD_H
# include <unistd.h>
#else
/* We are in trouble.  */
#endif

`#undef'の代わりに`#define'を用いている，古い形式のテンプレー トの使用は，強く反対します．`#undef'と同じ行にコメントがある古いテ ンプレートも同様です．とにかく，プロセッサマクロにコメントを書くのは，決 してよい考えではありません．

テンプレートヘッダを更新し続けることは退屈な作業なので，それを生成するた めにautoheaderしてもかまいません．`config.h.in'を生成するためautoheaderを使用する を参照してください．

4.8.2 `config.h.in'を生成するため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 section 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は以下のオプションを受け入れます．

` --help'

` -h'

コマンドラインオプションの概要を出力して終了します．

` --version'

` -V'

Autoconfのバージョンナンバーを出力して終了します．

` --verbose'

` -v'

処理しているステップを報告します．

` --debug'

` -d'

一時的なファイルを削除しません．

` --force'

` -f'

入力ファイルよりテンプレートファイルが新しい場合でも，それを再生成します．

` --include=dir'

` -I dir'

dirをインクルードパスの後に追加します．複数回の呼び出しで累積され ます．

` --prepend-include=dir'

` -B dir'

dirをインクルードパスの前に追加します．複数回の呼び出しで累積され ます．

` --warnings=category'

` -W category'

category(実際にはカンマで分けられたリスト)に関連する警告を報告しま す．現在のカテゴリには，以下のものが含まれています．

` obsolete'

時代遅れの構成物の使用を報告します．

` all'

全ての警告を報告します．

` none'

何も報告しません．

` error'

警告をエラーとして扱います．

` no-category'

categoryに分類されている警告を利用不可能にします．

4.8.3 autoheaderのマクロ

autoheaderは`configure.ac'を調査し，定義されているCプリプ ロセッサシンボルを判定します．それは，AC_CHECK_HEADERSや AC_CHECK_FUNCS等が定義しているシンボルに対するテンプレートを生成 する方法は知っていますが，あらゆる追加のシンボルをAC_DEFINEしてい る場合，それに対するテンプレートを定義する必要があります．テンプレートが 無い場合，autoheaderはエラーメッセージとともに失敗します．

symbolに対するテンプレートを作成する最も簡単な方法は， `AC_DEFINE(symbol)'の引数にdescriptionを与えることです． Cプリプロセッサシンボルの定義を参照してください．以下のマクロの一つを使用するこ とも可能です．

Macro: AH_VERBATIM (key, template)

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])

Macro: AH_TEMPLATE (key, description)

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

Macro: AH_TOP (text)

textをヘッダテンプレートファイルの最初に含めます．

Macro: AH_BOTTOM (text)

textをヘッダテンプレートファイルの最後に含めます．

4.9 任意のコンフィグレーションコマンドの実行

`config.status'の実行前，実行中，そして実行後のいずれかに任意のコマ ンドを実行することが可能です．以下の三つのマクロは，複数回呼び出されたと き，実行するコマンドを累積していきます．AC_CONFIG_COMMANDS は時代 遅れのマクロAC_OUTPUT_COMMANDSの置換物です．詳細は，時代遅れのマクロを参照してください．

Macro: AC_CONFIG_COMMANDS (tag…, [cmds], [init-cmds])

`config.status'の終りに実行するシェルコマンドと， configureからのあらゆる変数を初期化するためのシェルコマンドを を追加します．コマンドをtagに関連付けます．通常，cmdsはファ イルを作成するので，tagは自ずからファイル名にすべきでしょう．実際， tagに書かれているディレクトリが作製されます．このマクロは，実際に ファイルを作成するマクロです．コンフィグレーション作業の実行を参照してくだ さい．

非現実的な例ですが，以下のようにします．

fubar=42 AC_CONFIG_COMMANDS([fubar], [echo this is extra $fubar, and so on.], [fubar=$fubar])

以下はましなものです．

AC_CONFIG_COMMANDS([time-stamp], [date >time-stamp])

Macro: AC_CONFIG_COMMANDS_PRE (cmds)

`config.status'を作成する直前にcmdsを実行します．

Macro: AC_CONFIG_COMMANDS_POST (cmds)

`config.status'を作成した直後にcmdsを実行します．

4.10 コンフィグレーションのリンクを作成する

テストの結果によって，対象物へのリンクを作成することが便利だと分かるでしょ う．AC_CONFIG_COMMANDSを使用することも可能ですが，相対的なシンボ リックリンクを作成することで，パッケージがソースディレクトリとは異なるディ レクトリでビルドされるときに決定することが可能です．

Macro: AC_CONFIG_LINKS (dest:source…, [cmds], [init-cmds])

AC_OUTPUTで，それぞれの既存のファイルsourceから対応するリン ク名destにリンクを作成します．可能な場合はシンボリックリンクを作成 し，それ以外ではハードリンクを作成し，それ以外ではコピーします． destとsourceの名前は，ソースやビルドディレクトリのトップレベ ルからの相対的なものにすべきです．このマクロは，実際にファイルを作成する マクロの一つです．コンフィグレーション作業の実行を参照してください．

例えば，以下のように呼び出します．

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

これでリンクを作成します．

4.11 サブディレクトリで他のパッケージをコンフィグレーションする

ほとんどの場合，AC_OUTPUTを呼び出すことで，サブディレクトリの `Makefile'を作成するためには十分です．しかし，一つ以上の独立したパッ ケージを制御するconfigureスクリプトで，サブディレクトリの他の パッケージのconfigureスクリプトを実行するために AC_CONFIG_SUBDIRSを使用することが可能です．

Macro: AC_CONFIG_SUBDIRS (dir …)

空白で区切られたリストで与えられているそれぞれのサブディレクトリ dirで，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'のルールは，この値を サブディレクトリの定義に再帰的に使用することが可能です．

このマクロは何度呼び出してもかまいません．

4.12 デフォルトプレフィクス

configureはデフォルトで，ファイルをインストールするプレフィク スを`/usr/local'に設定します．configureのユーザは，異なる ディレクトリを，`--prefix'と`--exec-prefix'オプションで選択す ることが可能です．デフォルトを変更する方法は二つあります． configureを作成するときと，実行するときです．

デフォルトで，`/usr/local'以外のディレクトリにインストールしたい， ソフトウェアパッケージもあります．そうするために， AC_PREFIX_DEFAULTマクロを使用してください．

Macro: AC_PREFIX_DEFAULT (prefix)

デフォルトのインストールプレフィクスを，`/usr/local'の代わりに prefixに設定します．

ユーザが既にインストールしている関連するプログラムの場所から， configureがインストールプレフィクスを推測すると便利かもしれま せん．そうしたい場合，AC_PREFIX_PROGRAMを呼び出します．

Macro: AC_PREFIX_PROGRAM (program)

ユーザが(`--prefix'オプションを使用して)インストールプレフィクスを 指定しない場合，シェルが行うように，PATHでprogramを探し，そ の値を推測します．programが見つかった場合，プレフィクスを programを含むディレクトリの親に設定します．そうでない場合，上記の もの(`/usr/local'やAC_PREFIX_DEFAULT)がデフォルトのプレフィ クスになります．例えば，programがgccで，PATHが `/usr/local/gnu/bin/gcc' を含んでいる場合，プレフィクスを `/usr/local/gnu'に設定します．

This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.