[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
配布されるすべてのファイルが同じディレクトリにある単純なプロジェクトに 対して,すべてをその場でビルドする単一の`Makefile.am'があれば十分 です.
大きなプロジェクトでは,ツリーの別々のディレクトリに体系化されたファイ
ルがあるのが一般的です.例えば,プログラムごと,ライブラリごと,そして
モジュールごと一つのディレクトリがあります.伝統的な手法は,これらのサ
ブディレクトリを再帰的にビルドしていました.それぞれのディレクトリには
(`Makefile.am'から生成された)`Makefile'が含まれており,
make
をトップレベルのディレクトリで実行すると,それぞれのサブ
ディレクトリに移動し,順番にその内容をビルドしていきます.
6.1 サブディレクトリの再帰 | Building subdirectories recursively | |
6.2 サブディレクトリの条件 | Conditionally not building directories | |
6.3 サブディレクトリに代わるアプローチ | Subdirectories without recursion | |
6.4 入れ子状のパッケージ | Nesting packages |
サブディレクトリがあるパッケージでは,最上位の`Makefile.am'でビル
ドするサブディレクトリをAutomakeに伝える必要があります.これは
SUBDIRS
変数によってなされます.
SUBDIRS
変数は,さまざまな種類のビルドが行われるサブディレクトリ
のリストを保持しています.生成されている`Makefile'内の多くのター
ゲットに対するルールは(例えばall
),ローカルと指定されたすべての
サブディレクトリの両方で実行されます.SUBDIRS
でリストアップされ
ているディレクトリには,`Makefile.am'を含んでいる必要がないことに
注意してください.(configure後の)`Makefile'だけが必要です.こうす
ることで,(gettext
のようなもので,サードパーティーの`Makefile'
も参照して下さい)Automakeを使用しないパッケージからライブラリを含める
ことが可能になります.
サブディレクトリを使用しているパッケージでは,最上位の `Makefile.am'は非常に短いことが多くなっています.例えば,GNU Hello 配布物の`Makefile.am'は以下のようになっています.
EXTRA_DIST = BUGS ChangeLog.O README-alpha SUBDIRS = doc intl po src tests |
Automakeがmake
をサブディレクトリで呼び出すとき,MAKE
変数
の値を使用します.それは,変数AM_MAKEFLAGS
の値をmake
の呼
び出しに渡します.これで,常にmake
に渡す必要があるフラグを
`Makefile.am'で設定することが可能になります.
SUBDIRS
で記述されているディレクトリは,通常,現在のディレクトリ
の直接の子ディレクトリになっていて,それぞれのサブディレクトリには,そ
れより不快サブディレクトリを示すSUBDIRS
を示している,独自の
`Makefile.am'が含まれています.この方法で任意の深さのパッケージ構
成で,Automakeを使用することがが可能になります.
デフォルトで,Automakeはpostfixの順序での最初の深さで動作する
`Makefile'を生成します.サブディレクトリはカレントディレクトリの
前にビルドされます.しかし,この順序を変更することは可能です.
SUBDIRS
に`.'を書くことでこうすることが可能です.例えば,
`.'を最初に書くことで,ディレクトリの`prefix'の順序になりま
す.
以下を使用します.
SUBDIRS = lib src . test |
これで`lib/'が`src/'の前にビルドされ,そしてカレントディレク トリがビルドされ,最後に`test/'ディレクトリがビルドされるでしょう. 構成されたものをテストするので,テストディレクトリを他のすべての後にビ ルドするように手配するのは一般的です.
すべての`clean'ルールは,ビルドルールの逆の順序で実行されます.
GNU Inetutils
のように,パッケージ全体のサブセットをビルドしたい
だけの場合,SUBDIRS
変数を条件的に定義することがが可能です.
これがどのように動作するかを説明するため,二つのディレクトリ
`src/' と`opt/'があると仮定しましょう.`src/'は常にビル
ドされますが,`opt/'は./configure
でビルドするかどうかを決
定したいと思います.(この例では,変数$want_opt
がyes
に設
定されているとき`opt/'をビルドすると仮定します.)
make
と実行することで,`src/'は常に再帰され,`opt/'も
そうなるかもしれません.
しかし,make dist
では常に`src/'と`opt/'の両方を再帰す
べきです.つまり,現在のconfigureでは不要な場合でも,`opt/'は配布
されるべきです.これは,`opt/Makefile'は条件に依存せず作成
されるべきだということを意味します.
このようにプロジェクトを設定する方法は二つあります.Automakeの条件式
(see section 条件文)を使用したり,AutoconfのAC_SUBST
マクロ
(see (autoconf)Setting Output Variables section `Setting Output Variables' in The Autoconf Manual)を使用したりすることが可能です.
Automakeの条件式の使用は,より好まれる解となります.これら二つの可能性
を示す前に,DIST_SUBDIRS
を紹介しましょう.
SUBDIRS
対DIST_SUBDIRS
Automakeは,SUBDIRS
とDIST_SUBDIRS
で定義される,二つのディ
レクトリ・セットを考慮します.
SUBDIRS
は,ビルドする必要があるカレント・ディレクトリのサブディ
レクトリを含んでいます(see section サブディレクトリの再帰).それは手動で定義する必
要があります.Automakeは,ビルドするディレクトリかどうかを判定すること
はありません.以下の二つのセクションで分かるように,ビルドするディレク
トリからいくつかのディレクトリを削除する条件を定義することが可能です.
DIST_SUBDIRS
はすべてのディレクトリを再帰する必要があるルールで
使用され,ビルドされる条件から外れていても使用されます.サブディレクト
リ`opt/'はビルドしないのに,それを配布したいという例を思い出しま
したか?これはDIST_SUBDIRS
で行ないます.opt
は
SUBDIRS
にはありませんが,DIST_SUBDIRS
には存在する必要が
あります.
厳密にいうと,DIST_SUBDIRS
はmake dist
,make
distclean
,そしてmake maintainer-clean
で使用されます.それ以外
の再帰的なルールではSUBDIRS
が使用されます.
SUBDIRS
がAutomakeの条件文を使用し条件的に定義される場合,
Automakeは,すべての条件でSUBDIRS
がとり得る値で,
DIST_SUBDIRS
を自動的に定義します.
SUBDIRS
がAC_SUBST
変数を含む場合,Automakeはこれらの変数
がとり得る値が分からないので,DIST_SUBDIRS
は正確に定義できませ
ん.この状況では,DIST_SUBDIRS
を手動で定義する必要があります.
AM_CONDITIONAL
を用いた条件付サブディレクトリ `configure'でそれぞれのディレクトリの`Makefile'を出力し, `opt/'をビルドするかどうかの条件を定義すべきです.
… AM_CONDITIONAL([COND_OPT], [test "$want_opt" = yes]) AC_CONFIG_FILES([Makefile src/Makefile opt/Makefile]) … |
SUBDIRS
は,最上位の`Makefile.am'で,以下のように定義するこ
とが可能です.
if COND_OPT MAYBE_OPT = opt endif SUBDIRS = src $(MAYBE_OPT) |
御覧のように,make
を実行することで,`src/'と,おそらく
`opt/'に再帰していくでしょう.
見ることはできませんが,make dist
はmake all
とは異なり,
SUBDIRS
変数を使用しないので,make dist
を実行することで,
`src/'と`opt/'の両方に再帰的に行ないます.それは
DIST_SUBDIRS
変数を使用します.
この場合,AutomakeはMAYBE_OPT
が条件によってはopt
を含むこ
とを知っているので,DIST_SUBDIRS = src opt
を自動的に定義します.
AC_SUBST
を用いたサブディレクトリの条件式 もう一つの可能な方法は,AC_SUBST
を使用して,`./configure'
でMAYBE_OPT
を定義することです.
… if test "$want_opt" = yes; then MAYBE_OPT=opt else MAYBE_OPT= fi AC_SUBST([MAYBE_OPT]) AC_CONFIG_FILES([Makefile src/Makefile opt/Makefile]) … |
この状況では,最上位の`Makefile.am'は以下のようになるでしょう.
SUBDIRS = src $(MAYBE_OPT) DIST_SUBDIRS = src opt |
欠点は,AutomakeがMAYBE_OPT
の変数が何かを推測することが不可能な
ので,DIST_SUBDIRS
に定義する必要があるということです.
DIST_SUBDIRS
の意味は,サブディレクトリを条件的にコンフィ
グレーションしビルドしようとするユーザに誤解されていることが多くなっ
ています.ここでのコンフィグレーションとは,`Makefile'の作成を意
味します(入れ子状のconfigure
スクリプトの呼び出しの可能性もあ
ります.これはコストのかかる処理で,条件的にしたい言い訳にしますが,
`Makefile'に関することだけを議論します).
上記の例ではすべて,ビルドされないディレクトリを含めて,全部の
`Makefile'の作成を仮定しています.単純な理由として,make
dist
でビルドされないディレクトリも配布したいことがあり(例えば,プラッ
トフォーム依存のコード),このため`make dist'でサブディレクトリを
再帰的にする必要があり,更にこのディレクトリをコンフィグレーションし
DIST_SUBDIRS
に存在させる必要があります.
すべてのサブディレクトリをコンフィグレーションするわけではないパッケー ジのビルドはトリッキーな作業になり,間違って不完全なtarballを生成しが ちなので,初心者にはお勧めしません.我々はこのトピックをここでは深く議 論しませんが,ちょっと危険なので,いくつかルールがあることを覚えておい て下さい.
|
コンフィグレーションされないディレクトリを再帰するのを避けるため,その
ディレクトリが確実にDIST_SUBDIRS
(とSUBDIRS
)に存在しない
ことを確かめる必要があります.例えば,AC_SUBST
を使用して
SUBDIRS
を条件的に定義していて,DIST_SUBDIRS
が明示的に定
義されていない場合,それはデフォルトで$(SUBDIRS)
になります.も
う一つの可能性として,DIST_SUBDIRS = $(SUBDIRS)
を強制します.
Peter Millerの優れた論文をすでに読んでいる場合
Recursive Make Considered Harmful,サブディレクトリを使用する前のセク
ションは,おそらくありがたくない助言になるでしょう.論文を読んでいない
人のために,Millerの主題は,再帰的なmake
の呼び出しは,遅くてエ
ラーを発生しやすいということです.
複雑な複数のディレクトリがあるパッケージに対して,単一の `Makefile.am'だけを書くことを可能にする,ディレクトリを跨るための 優れたサポート(3)を, Automake は提供しています.
デフォルトで,サブディレクトリで指定されているインストール可能なファイ ルは,インストールする前にそのディレクトリ名が切り取られています.例え ば以下の例では,ヘッダファイルが`$(includedir)/stdio.h'にインストー ルされるでしょう.
include_HEADERS = inc/stdio.h |
しかし,`nobase_'を前置することで,このパスを切り取りを回避するこ とが可能になります.以下の例では,ヘッダファイルは `$(includedir)/sys/types.h'にインストールされるでしょう.
nobase_include_HEADERS = sys/types.h |
`nobase_'は,`dist_'や`nodist_'(see section 配布物に含まれるもの)のいずれか と組合わせて使用するとき,最初に指定するべきです.例えば以下のようにし ます.
nobase_dist_pkgdata_DATA = images/vortex.pgm |
GNUビルド・システムでは,パッケージを任意の深さに入れ子状にすることが 可能です.これは,独自の`configure',`Makefile'などがある他 のパッケージを埋め込んだパッケージが可能になることを意味します.
これらのその他のパッケージは,親パッケージのサブディレクトリに存在する
ようにすべきです.それらは,他の普通のディレクトリと同様に
SUBDIRS
にリストアップする必要があります.しかし,サブパッケージ
の`Makefile'は,親の`configure'ではなく,独自の
`configure'スクリプトで出力するようにすべきです.これはAutoconfマ
クロのAC_CONFIG_SUBDIRS
を使用して達成します
(see AC_CONFIG_SUBDIRS: (autoconf)Subdirectories section `Configuring Other Packages in Subdirectories' in The Autoconf Manual).
サブディレクトリの`hand/'にある入れ子状のパッケージhand
ラ
イブラリとリンクする,arm
プログラムのパッケージ例は,以下のよう
になります.
arm
の`configure.ac'です.
AC_INIT([arm], [1.0]) AC_CONFIG_AUX_DIR([.]) AM_INIT_AUTOMAKE AC_PROG_CC AC_CONFIG_FILES([Makefile]) # Call hand's ./configure script recursively. AC_CONFIG_SUBDIRS([hand]) AC_OUTPUT |
arm
の`Makefile.am'です.
# Build the library in the hand subdirectory first. SUBDIRS = hand # Include hand's header when compiling this directory. AM_CPPFLAGS = -I$(srcdir)/hand bin_PROGRAMS = arm arm_SOURCES = arm.c # link with the hand library. arm_LDADD = hand/libhand.a |
さて,hand
の`hand/configure.ac'です.
AC_INIT([hand], [1.2]) AC_CONFIG_AUX_DIR([.]) AM_INIT_AUTOMAKE AC_PROG_CC AC_PROG_RANLIB AC_CONFIG_FILES([Makefile]) AC_OUTPUT |
そしてその`hand/Makefile.am'です.
lib_LIBRARIES = libhand.a libhand_a_SOURCES = hand.c |
make dist
がトップレベルのディレクトリで実行されるとき,
`hand'サブディレクトリだけでなく,arm
コードも含むアーカイ
ブ`arm-1.0.tar.gz'を作成します.このパッケージは,通常のパッケー
ジと同じように,いつもの./configure && make && make install
でビ
ルドしインストールすることが可能です(hand
サブパッケージは,処理
中にビルドとインストールがなされます.).
make dist
がhand
ディレクトリで実行されるとき,それ自身が
含まれている`hand-1.2.tar.gz'アーカイブを作成します.他のパッケー
ジに埋め込まれているのですが,別々に使用することも可能です.
AC_CONFIG_AUX_DIR([.])
機能の目的は,AutomakeとAutoconfに追加ス
クリプトをカレントディレクトリで探すように強制することです.例えば,二
つの`install-sh'のコピーがあって,一つはトップレベルのarm
パッケージ,もう一つはhand
パッケージの`hand/'サブディレク
トリにあるということを意味します.
歴史的なデフォルトは,これらの追加スクリプトを直接の親と更にその親のディ
レクトリで探します.そのため,AC_CONFIG_AUX_DIR([.])
行が
`hand/configure.ac'からなくなると,サブパッケージはarm
パッ
ケージの追加スクリプトを共有します.これは若干サイズが大きくなる(数Kバ
イト)ように見えますが,hand
サブパッケージのモジュール性が実際に
なくなり,自身には含まれないことになってしまいます(サブディレクトリで
make dist
しても動作しません).
Automakeを使用しないパッケージは,この方法で統合するために,さらなる作 業が必要ですSee section サードパーティーの`Makefile'.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 8 2005 using texi2html 1.70.