6. ディレクトリ

配布されるすべてのファイルが同じディレクトリにある単純なプロジェクトに 対して，すべてをその場でビルドする単一の`Makefile.am'があれば十分 です．

大きなプロジェクトでは，ツリーの別々のディレクトリに体系化されたファイ ルがあるのが一般的です．例えば，プログラムごと，ライブラリごと，そして モジュールごと一つのディレクトリがあります．伝統的な手法は，これらのサ ブディレクトリを再帰的にビルドしていました．それぞれのディレクトリには (`Makefile.am'から生成された)`Makefile'が含まれており， makeをトップレベルのディレクトリで実行すると，それぞれのサブ ディレクトリに移動し，順番にその内容をビルドしていきます．

6.1 サブディレクトリの再帰

サブディレクトリがあるパッケージでは，最上位の`Makefile.am'でビル ドするサブディレクトリをAutomakeに伝える必要があります．これは SUBDIRS変数によってなされます．

SUBDIRS変数は，さまざまな種類のビルドが行われるサブディレクトリ のリストを保持しています．生成されている`Makefile'内の多くのター ゲットに対するルールは(例えばall)，ローカルと指定されたすべての サブディレクトリの両方で実行されます．SUBDIRSでリストアップされ ているディレクトリには，`Makefile.am'を含んでいる必要がないことに 注意してください．(configure後の)`Makefile'だけが必要です．こうす ることで，(gettextのようなもので，22.2 サードパーティーの`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'ルールは，ビルドルールの逆の順序で実行されます．

6.2 サブディレクトリの条件

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 節 19. 条件文)を使用したり，AutoconfのAC_SUBSTマクロ (see 節 `Setting Output Variables' in

6.2.1 SUBDIRS対DIST_SUBDIRS

Automakeは，SUBDIRSとDIST_SUBDIRSで定義される，二つのディ レクトリ・セットを考慮します．

SUBDIRSは，ビルドする必要があるカレント・ディレクトリのサブディ レクトリを含んでいます(see 節 6.1 サブディレクトリの再帰)．それは手動で定義する必 要があります．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 を手動で定義する必要があります．

6.2.2 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を自動的に定義します．

6.2.3 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に定義する必要があるということです．

6.2.4 コンフィグレーションされないサブディレクトリ

DIST_SUBDIRSの意味は，サブディレクトリを条件的にコンフィ グレーションしビルドしようとするユーザに誤解されていることが多くなっ ています．ここでのコンフィグレーションとは，`Makefile'の作成を意 味します(入れ子状のconfigureスクリプトの呼び出しの可能性もあ ります．これはコストのかかる処理で，条件的にしたい言い訳にしますが， `Makefile'に関することだけを議論します)．

上記の例ではすべて，ビルドされないディレクトリを含めて，全部の `Makefile'の作成を仮定しています．単純な理由として，make distでビルドされないディレクトリも配布したいことがあり(例えば，プラッ トフォーム依存のコード)，このため`make dist'でサブディレクトリを 再帰的にする必要があり，更にこのディレクトリをコンフィグレーションし DIST_SUBDIRSに存在させる必要があります．

すべてのサブディレクトリをコンフィグレーションするわけではないパッケー ジのビルドはトリッキーな作業になり，間違って不完全なtarballを生成しが ちなので，初心者にはお勧めしません．我々はこのトピックをここでは深く議 論しませんが，ちょっと危険なので,いくつかルールがあることを覚えておい て下さい．

• SUBDIRSは常にDIST_SUBDIRSのサブセット(下位集合)にすべきです．

  DIST_SUBDIRSには無いディレクトリをSUBDIRSに書くことには ちょっとだけ意味があります．前者はディレクトリのリストを伝える方法で， 後者はビルドすべきものです．

• DIST_SUBDIRSとSUBDIRSにリストアップされるディレクトリは，すべてコンフィグレーションすべきです．

  すなわち，`Makefile'が存在する必要があり，そうしなければ，再帰的 なmakeルールでディレクトリを処理することができません．

• コンフィグレーションされるディレクトリはすべてDIST_SUBDIRSにリストアップする必要があります．

  cleanルールで生成された`Makefile'を削除するようにするためです． DIST_SUBDIRSが変数として，コンフィグレーションされるすべてのディ レクトリをリストアップしていることを確認するのが王道です．

コンフィグレーションされないディレクトリを再帰するのを避けるため，その ディレクトリが確実にDIST_SUBDIRS(とSUBDIRS)に存在しない ことを確かめる必要があります．例えば，AC_SUBSTを使用して SUBDIRSを条件的に定義していて，DIST_SUBDIRSが明示的に定 義されていない場合，それはデフォルトで$(SUBDIRS)になります．も う一つの可能性として，DIST_SUBDIRS = $(SUBDIRS)を強制します．

6.3 サブディレクトリに代わるアプローチ

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 節 13. 配布物に含まれるもの)のいずれか と組合わせて使用するとき，最初に指定するべきです．例えば以下のようにし ます．

nobase_dist_pkgdata_DATA = images/vortex.pgm

6.4 入れ子状のパッケージ

GNUビルド・システムでは，パッケージを任意の深さに入れ子状にすることが 可能です．これは，独自の`configure'，`Makefile'などがある他 のパッケージを埋め込んだパッケージが可能になることを意味します．

これらのその他のパッケージは，親パッケージのサブディレクトリに存在する ようにすべきです．それらは，他の普通のディレクトリと同様に SUBDIRSにリストアップする必要があります．しかし，サブパッケージ の`Makefile'は，親の`configure'ではなく，独自の `configure'スクリプトで出力するようにすべきです．これはAutoconfマ クロのAC_CONFIG_SUBDIRSを使用して達成します (see 節 `Configuring Other Packages in Subdirectories' in

サブディレクトリの`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 節 22.2 サードパーティーの`Makefile'.