| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Autoconfで生成されたconfigureスクリプトは、初期化や結果出力の
ための情報を必要します。たとえば、パッケージのソースファイルは
どこにあるのかとか、どのような出力ファイルを生成すべきか、などです。
以下の節では、初期化と結果出力について説明します。
3.1 Finding configure Input | Where Autoconf should find files. | |
| 3.2 Creating Output Files | Creating output files. | |
| 3.3 Substitutions in Makefiles | Using output variables in `Makefile's. | |
| 3.4 Configuration Header Files | Creating a configuration header file. | |
| 3.5 Configuring Other Packages in Subdirectories | Configuring independent packages together. | |
| 3.6 Default Prefix | Changing the default installation prefix. | |
3.7 Version Numbers in configure | Version numbers in configure. |
configure Input
configureスクリプトは他の全てのマクロより先に、AC_INIT
マクロを呼び出さねばなりません。必ず呼び出されなければならないマクロは
AC_INITとAC_OUTPUTだけです(see section 3.2 Creating Output Files)。
configureは、指定された
ディレクトリにソースコードが実際あるかどうか、
そのファイルが存在するかどうかを調べることで判断します。
ときには、ユーザはコマンドラインオプション`--srcdir'で
間違ったディレクトリを指定するかもしれません; この判定は、
安全のためのチェックです。詳しくはSee section 10. Running configure Scriptsを
参照してください。
手動で設定を行うパッケージや、installプログラムを
利用するパッケージでは、AC_CONFIG_AUX_DIRを使って、
configureに他のshellスクリプトがどこにあるかを
知らせる必要があるかもしれません。たいていはデフォルトで
調べにいく場所で正しいのですが。
configureスクリプトを利用することを
指定します。dirは絶対パス、または
`srcdir'からの相対パスで指定します。
デフォルトは`srcdir'または
`srcdir/..'または
`srcdir/../..'のうち、
`install-sh'が最初にみつかった場所です。
他のファイルの置き場所についてはチェックが
行われません。これはAC_PROG_INSTALLを
使っただけで他のファイルを配布しなければ
ならなくなるのを防ぐためです。
このマクロは`install.sh'もチェックしますが、
このファイル名はobsoleteです。なぜなら、
`Makefile'がない場合、makeが組み込み
ルールを使って`install.sh'から`install'を
生成しようとするからです。
Autoconfで生成されたconfigureスクリプトは、
最後にAC_OUTPUTを呼び出さねばなりません。
このマクロは、`Makefile'や他のファイルを自動設定結果にしたがって
生成します。configure.inに必ず含まれなければならない
マクロは、AC_OUTPUTの他にはAC_INITだけです(see section 3.1 Finding configure Input)。
AC_CONFIG_HEADER、AC_LINK_FILES、または
AC_CONFIG_SUBDIRSマクロが呼び出されていた場合、
AC_OUTPUTは各マクロの引数に指定されたファイルも
生成します。
たいてい、AC_OUTPUTは以下のように呼び出されます:
AC_OUTPUT(Makefile src/Makefile man/Makefile X/Imakefile) |
入力ファイルの名前は、fileのあとにコロンをつけて、 そのあとに入力ファイル名を繋げることで変更できます。 たとえば:
AC_OUTPUT(Makefile:templates/top.mk lib/Makefile:templates/lib.mk) AC_OUTPUT(Makefile:templates/vars.mk:Makefile.in:templates/rules.mk) |
extra-cmdsを指定した場合、指定された
コマンドは他の処理の後に実行されるように
`config.status'に追加されます。
init-cmdsが指定された場合、それは
shell変数、コマンド、backslashの
置き換えが行われた後、extra-cmdsの
直前に挿入されます。init-cmdsを
使うことで、configureから
extra-cmdsに変数を引き渡すことが
できます。AC_OUTPUT_COMMANDSマクロが
呼び出されていた場合、AC_OUTPUT_COMMANDSに
指定されたコマンドは、AC_OUTPUTに指定された
コマンドの直前に実行されます。
configureで行うべき変数初期化
手続きを指定します。このマクロは複数回呼び出しても
構いません。実用的でない例題はこんなかんじ:
fubar=27 AC_OUTPUT_COMMANDS([echo this is extra $fubar, and so on.], fubar=$fubar) AC_OUTPUT_COMMANDS([echo this is another, extra, bit], [echo init bit]) |
makeをサブディレクトリで実行する場合には、
変数MAKEを使ってmakeを呼び出さねば
なりません。ほとんどのmakeでは、変数
MAKEはmakeプログラムと与えられた
オプションに設定されます(が、多くの場合
コマンドラインでの変数値設定は含まれません)。
一部の古いmakeでは、変数MAKEは
設定されません。以下のマクロを使うと、そのような
古いmakeでも変数MAKEを使うことができます。
makeが変数MAKEを設定しているなら、
変数SET_MAKEを空にします。
そうでない場合、SET_MAKEを`MAKE=make'に
設定します。内部でAC_SUBSTを
SET_MAKEを置換するように呼び出します。
このマクロを利用する場合、MAKEを利用する
各々のMakefile.inに以下のような行を置いてください:
@SET_MAKE@ |
配布パッケージの各サブディレクトリのうちでコンパイルやインストールが
必要なディレクトリには、`Makefile.in'を置きます。
configureは`Makefile.in'から`Makefile'を生成します。
`Makefile'を生成する際には、configureは単純な
変数置換を行います。これは、`Makefile.in'中に登場する
`@variable@'をconfigureが求めた変数値で
置き換えることによって行われます。このようにして出力ファイルで
置換される変数のことをoutput variables(出力変数)と呼びます。
通常、出力変数はconfigureが設定するshell変数です。
configureにある変数値で置換を行わせる場合、変数名を
引数にしてマクロAC_SUBSTを呼び出す必要があります。
AC_SUBSTの呼び出されていない変数については、
`@variable@'はそのまま出力されます。
AC_SUBSTを使って出力変数を決める方法については
See section 6.2 Setting Output Variablesを参照してください。
configureスクリプトを用いるソフトウェアパッケージは、
`Makefile'ではなくて`Makefile.in'と一緒に配布される
必要があります; こうすれば、ユーザはコンパイルの前に必ず
configureスクリプトを実行して、各々のシステムにあわせた
設定を行うことになります。
`Makefile'に何かを書くことに関するより多くの情報のために See section `Makefile Conventions' in The GNU Coding Standards, を参照してください。
| 3.3.1 Preset Output Variables | Output variables that are always set. | |
| 3.3.2 Build Directories | Supporting multiple concurrent compiles. | |
| 3.3.3 Automatic Remaking | Makefile rules for configuring. |
Autoconfマクロでいくつかの出力変数が前もって設定されています。 Autoconfマクロの一部では、追加の出力変数を設定します。これについては 各マクロの説明のところで述べられています。 出力変数の完全なリストをみるにはSee section Output Variable Indexを 参照してください。前もって設定される出力変数の意味を以下に示します。 `dir'で終る出力変数については、 See section `Variables for Installation Directories' in The GNU Coding Standards, を参照してください。
configureによって
自動生成されました」というコメントと、
入力ファイル名を含んだコメント文字列です。
AC_OUTPUTは、生成する`Makefile'の
先頭に、この文字列を含むコメント行を
付け加えます。他のファイルについては、
この変数を各入力ファイル先頭のコメント
領域の中で参照しましょう。たとえば、
shellスクリプトである入力ファイルの先頭は
以下のようになります:
#! /bin/sh # @configure_input@ |
また、この行を置いておくことで、ファイルを
編集するひとにconfigureを使って
処理しないといけない、ということを
思い出させることができます。
srcdirとおなじです。
configureが
実行された環境で指定されていなかった場合、
AC_PROG_CCを呼び出したときの
デフォルト値(または、呼び出さなかったら空)が
設定されます。configureはこの変数の
値を使って、Cコンパイラの機能チェックのための
コンパイルを行います。
configureが実行された
環境でこの変数が指定されなかった場合、
デフォルト値は空になります。
configureはこの変数の
値を使って、Cコンパイラの機能チェック
のためのコンパイル、または
プリプロセスを行います。
configureが
実行された環境で指定されていなかった場合、
AC_PROG_CXXを呼び出したときの
デフォルト値(または、呼び出さなかったら空)が
設定されます。configureはこの変数の
値を使って、C++コンパイラの機能チェックのための
コンパイルを行います。
configureを実行するとき環境変数に設定されていなければ
AC_PROG_F77を呼ぶときにデフォルト値が設定されます。(または、
AC_PROG_F77を呼ばなければ空になります) configureはFortran
77 の特徴をテストするプログラムをコンパイルするときにこの変数を使用しま
す。
AC_CONFIG_HEADERマクロが呼び出された
場合、configureは`@DEFS@'を
`-D'群でなく、`-DHAVE_CONFIG_H'で
置き換えます(see section 3.4 Configuration Header Files
参照)。この変数はconfigureがテストを
行っている間は定義されません。出力ファイルを
生成するときにだけ定義されます。
既に行われてたテストの結果を参照する
場合には、See section 6.2 Setting Output Variablesを
参照してください。
configureが実行された環境で
指定されていなかった場合、
デフォルト値の空文字列が
設定されます。
configureはこの変数の値を
使って、Cコンパイラの機能チェックの
際のリンクを行います。
ソフトウェアパッケージを展開した単一のソースコードツリー上で、 同時に複数のアーキテクチャのためのコンパイルを行うことができます。 オブジェクトファイルは各アーキテクチャ別のディレクトリに格納されます。
このためには、makeはソースコードをみつけるために
make変数VPATHを使用します。GNU makeと
最近のmakeのほとんどはこの機能をサポートしています。
古いmakeはVPATHをサポートしていません;
古いmakeを使う場合、ソースコードとオブジェクトファイルは
同じディレクトリに置かれていなければなりません。
VPATHをサポートするために、各`Makefile.in'には
以下ような行が含まれている必要があります:
srcdir = @srcdir@ VPATH = @srcdir@ |
VPATHを他の変数の値を使って設定しないでください(たとえば
`VPATH = $(srcdir)'のように)。一部のmakeはVPATHの
値を設定する場合に変数置換を行います。
configureは`Makefile'を生成する際に、
srcdirを正しい値に設定し置換します。
make変数$<(VPATHを使ってみつけたソースディレクトリ中の
ファイルのパス名)は、暗黙的ルールの中以外では使わないでください
(暗黙的ルールとは、例えば`.c'ファイルから`.o'ファイルを
生成するための手順を定義する`.c.o'のルールのことです)。
一部のmakeは明示的ルール(訳中: 暗黙的ルールでないルール)の中では、
$<定義しません; $<は空になります。
そのかわりに、`Makefile'に記述するコマンドラインはソースファイルを `$(srcdir)/'で始めるようにしてください。例えば:
time.info: time.texinfo
$(MAKEINFO) $(srcdir)/time.texinfo
|
以下に示すようなルールをトップレベルの`Makefile.in'に含めると、 設定ファイルを変更したら自動的に設定情報を更新させることができます。 この例題には`aclocal.m4'やconfiguration header fileのような、 使っても使わなくてもいいファイルが全て含まれています。 `Makefile.in'にルールを追加するときには、パッケージ中で 実際使わないものは省略してください。
`${srcdir}/'プレフィックスはVPATHの制限を回避するために
記述されています。
`config.h.in'と`config.h'の内容に変化がない場合、
これらのファイルのタイムスタンプは変わりません。
`stamp-'で始まる名前のファイルは、このせいで用いられています。
このようにすることで、余計な再設定を防ぐことができます。
この手法を使う場合、makeが`config.h.in'が更新済みだと
思うように、`stamp-h.in'をパッケージの配布に含める必要があります。
古いBSD系のシステムでは、touchや他のファイルで空ファイルが
作成される場合、タイムスタンプが変わりません。
このため、逃げ道としてechoを使っています。
${srcdir}/configure: configure.in 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.in aclocal.m4 acconfig.h \
config.h.top config.h.bot
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
|
さらに、`echo timestamp > stamp-h'をAC_OUTPUTの
引数extra-cmdsに指定する必要があります。
config.statusを実行したときに、`config.h'が更新されたという
ことがわかるようにするためです。AC_OUTPUTの詳細については
See section 3.2 Creating Output Filesを参照。
設定ファイルにまつわる依存関係については、See section 11. Recreating a Configurationを 参照。
パッケージの移植性テストで、Cプリプロセッサシンボルをいくつか以上
使う場合、コンパイラを起動するときのコマンドラインは、`-D'オプションを
渡さなければならないので非常に長くなります。
この手法にはふたつの問題があります。まずmakeの出力を眺めて間違いを
みつけるのが難しくなります。もっと深刻なのは、一部のOSのコマンドライン
長の制限を越えてしまう可能性がある、ということです。
`-D'オプションを使うかわりに、configureスクリプトは
`#define'ディレクティブを含んだCヘッダファイルを生成することができます。
AC_CONFIG_HEADERマクロでこのような出力ファイルを選択します。
このマクロはAC_INITの直後に呼び出す必要があります。
パッケージ中のソースコードでは、`#include'ディレクティブを使って、
configuration header fileを他のどのヘッダファイルよりも前に
読み込む必要があります。
一番最初に読み込むのは、定義の一貫性を保つためです(例えば、constを
再定義するヘッダを先に読み込んだりしたら困ります)。
`#include "config.h"'でなしに、`#include <config.h>'を使い、
Cコンパイラに`-I.'オプションを渡しましょう
(あるいは`-I..'などと、`config.h'のあるディレクトリを
指定しましょう)。このようにすることで、ソースファイルのあるディレクトリに
`config.h'がある状態でも、他のビルドディレクトリを作成して
そちらの`config.h'を使ってパッケージをコンパイルすることができます
(訳註: 結構意訳)。
AC_OUTPUTにCプリプロセッサ向けの
#defineディレクティブ入りの
ファイルを作成させ、`@DEFS@'を
(shell変数DEFSの値でなく)
`-DHAVE_CONFIG_H'に置換させます。
出力ファイル名はheader-to-createに、
スペースで区切って指定します。
通常、header-to-createに使う
ファイル名は`config.h'です。
もしheader-to-createに指定された
ファイルが既に存在していて、AC_OUTPUTが
出力しようとしている内容と同じ内容だったら、
ファイルは更新されずそのままになります。
このようにすることで、パッケージの設定の
一部を変更したとき、header-to-createに
指定されたヘッダファイルに依存している
ファイルを余計に再コンパイルしなくて済みます。
通常、入力ファイルは `header-to-create.in'という名前です; が、もし名前を変えたい場合には header-to-createにコロンで区切った 名前の列を繋げることで変えられます。 たとえば:
AC_CONFIG_HEADER(defines.h:defines.hin) AC_CONFIG_HEADER(defines.h:defs.pre:defines.h.in:defs.post) |
| 3.4.1 Configuration Header Templates | Input for the configuration headers. | |
3.4.2 Using autoheader to Create `config.h.in' | How to create configuration templates. |
配布パッケージには、ヘッダファイルのテンプレートを含める必要があります。
テンプレートは出力がこうあってほしいと思うとおりに書き、
コメントと、デフォルト値を含めた#defineディレクティブを
書いておく必要があります。
例えば、`configure.in'が以下のマクロ呼び出しを含んでいる場合:
AC_CONFIG_HEADER(conf.h) AC_CHECK_HEADERS(unistd.h) |
以下のような行が`conf.h.in'に含まれている必要があります。
`unistd.h'があるシステムでは、configureは
`#define'の行の0を1に変えて出力します。ないシステムでは、
そのまま出力します。
/* Define as 1 if you have unistd.h. */ #define HAVE_UNISTD_H 0 |
あなたのプログラムが#ifでなく#ifdefで
設定オプションを調べている場合、入力ファイルにデフォルト値を設定する
#defineの行を書くかわりに、#undefの行を書くことができます。
`unistd.h'があるシステムでは、configureは
2行目を`#define HAVE_UNISTD_H 1'と書き換えます。
そうでないシステムでは、2行目をコメントアウトして出力します
(コメントアウトするのは、このシンボルがシステムで既に使われている
かもしれないからです)。
/* Define if you have unistd.h. */ #undef HAVE_UNISTD_H |
autoheader to Create `config.h.in'
autoheaderプログラムは、configureが使う
Cの`#define'ディレクティブ入りのファイルを生成してくれます。
`configure.in'がAC_CONFIG_HEADER(file)を
呼び出している場合、autoheaderは`file.in'を
生成します。複数のファイルが指定されていたら、最初のファイル名を使います。
さもなくば、autoheaderは`config.h.in'を生成します。
autoheaderにコマンドライン引数を渡した場合、
入力として`configure.in'のかわりに指定されたファイルが使われ、
結果は(`config.h.in'でなく)標準出力に出力されます。
autoheaderに`-'をコマンドライン引数として渡すと、
(`configure.in'のかわりに)標準入力が読み込まれ、
結果は標準出力に出力されます。
autoheaderは`configure.in'を調べ、どんなCプリプロセッサシンボルが
定義される可能性があるか推測します。そして、
`acconfig.h'というファイルからコメントと#defineまたは
#undefの行をコピーします。
上記の`acconfig.h'はAutoconfと一緒に配布され、所定の場所にインストール
されているものです。
カレントディレクトリにも`acconfig.h'がある場合、こちらも使われます。
AC_DEFINEマクロで標準以外のシンボルを定義している場合、
それらのシンボルのぶんのエントリをカレントディレクトリの`acconfig.h'に
造っておく必要があります。
AC_CHECK_HEADERS、AC_CHECK_FUNCS、AC_CHECK_SIZEOF、
またはAC_CHECK_LIBで定義されるシンボルについては、
(`acconfig.h'から定義をコピーするのではなく)
autoheaderがコメントと#undefの行を自動生成します。
なぜなら、これらのマクロで使われる可能性のあるシンボルは事実上無限に
あるからです。
autoheaderの生成したファイルは、主に#defineまたは
#undefと、付随するコメントからなります。
`./acconfig.h'に`@TOP@'という文字列があった場合、
autoheaderは`@TOP@'を含む行以前の行を
出力の先頭にコピーします。
同様に、`./acconfig.h'に`@BOTTOM@'という文字列があった場合、
autoheaderは`@BOTTOM@'を含む行以降の行を
出力の末尾にコピーします。
どちらの文字列もなくても構いません。
`file.top'(通常`config.h.top'になります)や
`file.bot'という名前のファイルをカレントディレクトリに
作っておくと、同様の効果が得られます。
もしファイルがあった場合、autoheaderはファイルの内容を
出力の先頭(または末尾)にコピーします。
これらのファイルを使うのはおすすめしません。
なぜなら、これらのファイル名はMS-DOSファイルシステムに格納できないからです;
また、2つのファイルを置くことでディレクトリがごちゃごちゃします。
でも利点もあります。
他のディレクトリにある`acconfig.h'を読み込むために
autoheaderの`--localdir=dir'オプションを使う場合には、
これら2つのファイルを使うと全ての出力ファイルに別々のメッセージ
(訳註: boilerplate)をつけることができます。
autoheaderは以下のオプションを受け付けます:
--help
-h
--localdir=dir
-l dir
--macrodir=dir
-m dir
AC_MACRODIRを設定しても同じ効果が
得られます。コマンドラインオプションは環境変数の
設定より優先されます。
--version
ほとんどの場合、サブディレクトリに`Makefile'を作るには
AC_OUTPUTを使えば十分です。
しかし、複数の独立したパッケージを制御するconfigure
スクリプトを作る場合には、AC_CONFIG_SUBDIRSを使うことで
サブディレクトリにあるconfigureスクリプトを呼び出すことができます。
AC_OUTPUTマクロに、
dirに指定されたディレクトリ
にあるconfigureを実行させます。
ディレクトリが複数の場合はdirに
ディレクトリをスペースで区切って並べます。
ディレクトリdirがみつからない場合、
エラーにはなりません。これは、
configure大きなソースコード
ツリーのうちの実在する一部分だけを
設定できるようにするためです。
dirに`configure.in'があって
`configure'がない場合、Cygnus
ディレクトリAC_CONFIG_AUXDIRにある
Cygnus configureスクリプトが
使われます。
サブディレクトリにあるconfigure
スクリプトには、現在実行中の
configureスクリプトと、
基本的には同じコマンドライン引数が
渡されます。
コマンドライン引数は必要な場合には
わずかに変更されます(例えば、
キャッシュファイルやソースファイルの
あるディレクトリへの相対パスの調整など)。
このマクロは出力変数subdirsに、
サブディレクトリのリスト(dir ...)
を設定します。`Makefile'ルールでは
この変数を使って、どのサブディレクトリを
再帰的にmakeすればいいのか決める
ことができます。このマクロは複数回
呼び出しても構いません。
デフォルトでは、configureはインストールのためのファイル名の
ディレクトリプレフィクスを`/usr/local'に設定します。configureの
ユーザは、`--prefix'と`--exec-prefix'オプションを使って、
他のディレクトリプレフィクスを選択することができます。
デフォルトの設定を変更するにはふたつの方法があります:
configure生成時と、configureの実行時です。
一部のソフトウェアパッケージでは、デフォルトで`/usr/local'以外のところに
インストールしたい場合があるでしょう。このためには、
AC_PREFIX_DEFAULTマクロを使ってください。
configureスクリプトが、既にインストールされている
関係あるプログラムのインストール位置から、
インストールディレクトリプレフィクスを推測してくれると
便利なこともあるでしょう。このためには、AC_PREFIX_PROGRAMを
呼び出しましょう。
PATHをたぐって
探されます。もしprogramが
PATHに書かれたディレクトリの
どこかに存在した場合、ディレクトリ
プレフィクスをprogramのある
ディレクトリの親ディレクトリに
設定します; もしなかったら、
`Makefile.in'に指定された
プレフィクスをそのままにします。
例えば、programがgccで、
PATHを探した結果
`/usr/local/gnu/bin/gcc'が
見つかった場合、プレフィクスは
`/usr/local/gnu'になります。
configure
以下のマクロはconfigureスクリプトのバージョン番号を管理します。
このマクロは使っても使わなくても構いません。
configureを生成するのに
使われているAutoconfがversion
以前のものだった場合、エラーメッセージを
標準エラー出力に出力し、configureを
生成しません。例えば:
AC_PREREQ(1.8) |
このマクロは、`configure.in'が、
Autoconfのバージョンアップで変化した
自明でないふるまいに依存している場合に
役立ちます。もし最近定義されたマクロが
必要なだけの場合、AC_PREREQマクロは
あまり使いでがありません。なぜなら、
autoconfはAutoconfの
ユーザに、マクロがないというエラーを
出力しているはずだからです。
同様のことは、`cofigure.in'を
AC_PREREQが追加される以前の
Autoconfに通したときに起こります。
configureスクリプトに埋め込みます。
このマクロを使って`configure.in'の
リビジョンスタンプconfigureスクリプトに
取り込むと、RCS/CVSによって
configure内のリビジョンスタンプを
書き換えられずに済みます。
このようにすれば、configure
スクリプトがどのリビジョンの
`configure.in'から生成されたかを
簡単に知ることができます。
このマクロをAC_INIT以前に
使うようにすると、リビジョン番号が
`configure.in'とconfigureの
どちらでも先頭部分に入るので、
具合がよいです。
このように使われることを想定して、
AC_REVISIONの出力は
`#! /bin/sh'という行ではじまります。
これは通常のconfigureの
始まり方と同じです。
例えば、`configure.in'中の以下のような行は:
AC_REVISION($Revision: 1.30 $)dnl |
configureに以下のような出力を生成します:
#! /bin/sh # From configure.in Revision: 1.30 |
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |