Go to the first, previous, next, last section, table of contents.


出力ファイルの初期化

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

@command{configure}の初期化

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

Macro: AC_INIT (package, version, @ovar{bug-report}, @ovar{tarname})
あらゆるコマンドライン引数を処理し,様々な初期化と検証を実行します.

packageの名前とそのversionを設定します.これらは通常, @command{configure}に含まれる@option{--version}のサポートで使用されま す.オプションの引数bug-report-addressは,ユーザがバグレポートを 送る電子メールアドレスにすべきです.パッケージのtarnamepackageとは異なります.後者はパッケージの完全な名前を示します(例 えば,`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になります.

@command{configure}の注意事項

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

Macro: AC_PREREQ (version)
使用しているAutoconfのバージョンが十分新しいことを保証します. @command{configure}の作成に使用されるAutoconfのバージョンが, version以前の場合,標準エラー出力にエラーメッセージを出力し, @command{configure}を作成しません.例えば以下のようにします.
AC_PREREQ(2.57)

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

Macro: AC_COPYRIGHT (copyright-notice)
AutoconfマクロへのFree Software Foundationの著作権に加えて, @command{configure}についてcopyright-noticeでカバーしたい部分を 宣言してください.

copyright-noticeは,@command{configure}の先頭と,@samp{configure --version}の両方で表示されます.

Macro: AC_REVISION (revision-info)
リビジョンスタンプrevision-infoを,ドル記号やダブルクォートを削 除して@command{configure}スクリプトにコピーします.このマクロは, @command{configure}をチェックインしたときに@acronym{RCS}や @acronym{CVS}がリビジョンスタンプを変えなくても,`configure.ac'か ら@command{configure}にそれを書き込みます.そうすることで,特定の @command{configure}に対応する`configure.ac'のリビジョンが簡単に決 定可能になります.

例えば,以下の行を`configure.ac'に書いたとします.

AC_REVISION($Revision: 1.30 $)

これで,@command{configure}は以下のようになります.

#! /bin/sh
# From configure.ac Revision: 1.30

@command{configure}の入力を見つける

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

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

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

出力ファイルを生成する

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

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

`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}には,変数を設定しないものもありま す.以下のマクロでそれらのバージョンでも使用可能になります.

Macro: AC_PROG_MAKE_SET
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_FILESAC_CONFIG_HEADERSAC_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_FILESAC_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は,絶対パスまたは相対パスを用いたファイル名が可能です.後 者の場合,それは最初にビルドツリーで探され,その後でソースツリーで探さ れます.
commands
`config.status'にそのまま出力されるシェルコマンドで,実行するコマ ンドを`config.status'に伝えるためにユーザが使用することが可能な tagに関連付けされています.tagの要求が`config.status' に与えられるたびにコマンドが実行され,通常はファイル`tag'が 作成されるたびになります. @command{configure}の実行中に設定される変数は,ここでは利用@emph{不可 能} です.それらを最初にinit-cmdsで設定する必要があります.それ にもかかわらず,以下の変数は前もって求められます.
srcdir
ビルドディレクトリのトップからソースディレクトリのトップへのパスです. これは,@command{configure}のオプション@option{--srcdir}で設定されるも のです.
ac_top_srcdir
現在のビルドディレクトリからソースディレクトリのトップへのパスです.
ac_top_builddir
現在のビルドディレクトリからビルドディレクトリのトップへのパスです.連 結できるように,それを空にしたり,スラッシュで終えることが可能です.
ac_srcdir
現在のビルドディレクトリから対応するソースディレクトリへのパスです.
現在の(current)ディレクトリは,tagsの一部の入力が含まれる ディレクトリ(または疑似ディレクトリ)を参照します.例えば以下を実行した とします.
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'とは無関係です.
init-cmds
`config.status'の先頭付近に引用符で囲まれることなく出力さ れるシェルコマンドで,`config.status'が実行されるたびに(tag に関係なく)実行されます.引用符で囲まれていないので,例えば, `$var'varの値として出力されます.init-cmdsは通常, commands を実行するために必要な同じ変数を`config.status'に 与えるために,`configure'で使用されます. 変数名では特に注意すべきです.すべてのinit-cmdsは同じ名前空間を 共有し,それぞれ予測できない方法で上書きされるかもしれません.残念です @enddots{}

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

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

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

Macro: AC_CONFIG_FILES (file..., @ovar{cmds}, @ovar{init-cmds})
出力変数の値を置換しながら入力ファイル(デフォルトは `file.in')をコピーすることで,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が受け入れ可能なままにしたり,ファイ ルに常套句を前置したり後置したりすることが可能となります.

Makefileへの代入

コンパイルされたりインストールされたりするものを含んでいる,配布物のそ れぞれのサブディレクトリには,@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).

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

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

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

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

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

Variable: DEFS
Cコンパイラに渡す`-D'オプションです.AC_CONFIG_HEADERが呼 び出されている場合,@command{configure}は`@DEFS@'の代わりに `-DHAVE_CONFIG_H'に置換します(see section コンフィグレーションヘッダファイル).こ の変数は,@command{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: FFLAGS
Fortran 77コンパイラの,デバッグと最適化オプションです. @command{configure}を実行するときに環境変数で設定されていない場合, AC_PROG_F77を呼び出したときデフォルト値に設定されます(そうでな い場合は空になります).@command{configure}は,Fortran 77の特徴をテスト するプログラムのコンパイル時に,この変数を使用します.

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

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

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の絶対パスです.

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

以下の変数は,パッケージがインストールされる場所を指定します.詳細は, section `Variables for Installation Directories' in The @acronym{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
読み込み専用の,シングルマシンのデータをインストールするディレクトリで す.

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

以下の動作は,@acronym{GNU} coding standardsで示されれていて,ユーザが 実行時にそうなるようになっています.

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

これらの機能をサポートするために,datadirprefixの現在 の値に依存する`${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

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

`@datadir\@'
バックスラッシュで@command{configure}が`@datadir@'をsedの式自身 に置換することを妨げます.
`$(pkgdatadir)'
`@pkgdatadir@'を使用しないでください! 代わりに,makefile変数の マッチングを使用してください.
`,'
`$(pkgdatadir)'のように`/'を含んでいる変数を使用することもあ るので,@command{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)''
ソースへのパスを確実に指定し,そうしない場合はパッケージは分割ビルドを サポートしないでしょう.

ビルドディレクトリ

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

これをサポートするために,@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'を探すことなく,コンフィグレーション可能になります.

Macro: AC_CONFIG_HEADERS (header ..., @ovar{cmds}, @ovar{init-cmds})
このマクロは,実際にファイルを作成するマクロの一つです. section コンフィグレーション作業の実行を参照してください.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}を使用する を参照してください.

`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_DEFINEAC_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}は以下のオプションを受け入れます.

@option{--help}
@option{-h}
コマンドラインオプションの概要を出力して終了します.
@option{--version}
@option{-V}
Autoconfのバージョンナンバーを出力して終了します.
@option{--verbose}
@option{-v}
処理しているステップを報告します.
@option{--debug}
@option{-d}
一時的なファイルを削除しません.
@option{--force}
@option{-f}
入力ファイルよりテンプレートファイルが新しい場合でも,それを再生成しま す.
@option{--include=dir}
@option{-I dir}
dirをインクルードパスの後に追加します.複数回の呼び出しで累積さ れます.
@option{--prepend-include=dir}
@option{-B dir}
dirをインクルードパスの前に追加します.複数回の呼び出しで累積さ れます.
@option{--warnings=category}
@option{-W category}
category(実際にはカンマで分けられたリスト)に関連する警告を報告し ます.現在のカテゴリには,以下のものが含まれています.
`obsolete'
時代遅れの構成物の使用を報告します.
`all'
全ての警告を報告します.
`none'
何も報告しません.
`error'
警告をエラーとして扱います.
`no-category'
categoryに分類されている警告を利用不可能にします.

autoheaderのマクロ

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

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

Macro: AH_VERBATIM (key, template)
@command{autoheader}に,templateをそのままヘッダテンプレートファ イルに含めるよう伝えます.このtemplatekeyに関連付けされ ていて,それは全ての異なるテンプレートを並べ替えし,それらのユニーク性 を保証するために使用されます.それは,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)
@command{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をヘッダテンプレートファイルの最後に含めます.

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

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

Macro: AC_CONFIG_COMMANDS (tag..., @ovar{cmds}, @ovar{init-cmds})
`config.status'の終りに実行するシェルコマンドと, @command{configure}からのあらゆる変数を初期化するためのシェルコマンド をを追加します.コマンドをtagに関連付けます.通常,cmdsは ファイルを作成するので,tagは自ずからファイル名にすべきでしょう. このマクロは,実際にファイルを作成するマクロです.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])

Macro: AC_CONFIG_COMMANDS_PRE (cmds)
`config.status'を作成する直前にcmdsを実行します.

Macro: AC_CONFIG_COMMANDS_POST (cmds)
`config.status'を作成した直後にcmdsを実行します.

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

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

Macro: AC_CONFIG_LINKS (dest:source..., @ovar{cmds}, @ovar{init-cmds})
AC_OUTPUTで,それぞれの既存のファイルsourceから対応するリ ンク名destにリンクを作成します.可能な場合はシンボリックリンクを 作成し,それ以外ではハードリンクを作成し,それ以外ではコピーします. destsourceの名前は,ソースやビルドディレクトリのトップレ ベルからの相対的なものにすべきです.このマクロは,実際にファイルを作成 するマクロの一つです.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を使用することが可能です.

Macro: AC_CONFIG_SUBDIRS (dir ...)
空白で区切られたリストで与えられているそれぞれのサブディレクトリ dirで,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}スクリプトに与えられたものと同じコマンドラインオプ ションが渡され,必要場合は少し変更され,変更されるものには以下のものが 含まれます.

このマクロは,出力変数subdirsも,ディレクトリのリスト `dir...'に設定します.`Makefile'のルールは,この値を サブディレクトリの定義に再帰的に使用することが可能です.

このマクロは何度でも呼び出し可能です.

デフォルトプレフィクス

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

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

Macro: AC_PREFIX_DEFAULT (prefix)
デフォルトのインストールプレフィクスを,`/usr/local'の代わりに prefixに設定します.

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

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


Go to the first, previous, next, last section, table of contents.