前: Extending, 上: Not Enough
ほとんどのプロジェクトで，すべてのMakefileはAutomakeで生成され ます．しかし，状況によっては手書きのMakefileをサブディレクトリ に配置する必要があるプロジェクトもあります．例えば，あるディレクトリは 独自のビルドシステムを用いたサードパーティーのプロジェクトで，それ以外 はAutomakeを使用していることもあるでしょう．
以下の再帰的なターゲットをすべて認識するMakefileがあるディレク
トリであれば，任意のディレクトリをSUBDIRSやDIST_SUBDIRS
にリストアップすることが可能です．
ユーザが以下のターゲットを実行したとき，ターゲットはすべてのサブディレ クトリで再帰的に実行されます．これは，サードパーティーの Makefileがそれらをサポートしていることが重要である理由です．
alldistdir$(distdir)に配布すべきファイルをコピーし
ます．もちろん，このターゲットもno-distオプション
(see Optionsが使用されている場合は不要です．
変数$(top_distdir)と$(distdir)(see Dist)は，
distdirターゲットが呼び出されるとき，サブパッケージとなる外部パッ
ケージから渡されます．これら二つの変数は，再帰的になっているディレクト
リで調整されているので，すでに使用されています．
installinstall-datainstall-execuninstallinstall-infoinstalldirscheckinstallcheckmostlycleancleandistcleanmaintainer-cleandvipdfpsinfohtmltagsctagsTAGSとCTAGSをビルドします(see Tags)．
プロジェクトでGettextを使用したことがある場合，これはサードパーティー
のMakefileがAutomakeが使用可能だという良い例になります．
po/とintl/にあるgettextizeされた
Makefileは，これらすべてのターゲットを実装している手書きの
Makefileです．すなわち，AutomakeパッケージのSUBDIRSに追
加することが可能です．
DIST_SUBDIRSだけでリストアップされていて，SUBDIRSでリス
トアップされていないディレクトリは，distclean，
maintainer-clean，そしてdistdirルールだけが必要です
(see Conditional Subdirectories)．
通常，これらのルールの多くは，サードパーティーのサブプロジェクトには無 関係ですが，パッケージ全体がうまく動作するために要求されます．何もしな いルールもOKなので，ドキュメントもタグのサポートもないサードパーティー のプロジェクトを統合する場合は，単純にMakefileにを追加すること も可能でしょう．
EMPTY_AUTOMAKE_TARGETS = dvi pdf ps info html tags ctags
.PHONY: $(EMPTY_AUTOMAKE_TARGETS)
$(EMPTY_AUTOMAKE_TARGETS):
サードパーティーのビルドシステムとの統合のもう一つの側面は，それらが
VPATHのビルドをサポートしているかどうかによります．明らかに，サブパッ
ケージがVPATHのビルドをサポートしていない場合，パッケージ全体ではVPATH
のビルドをサポートしないことになります．言い替えると，make
distcheckはVPATHのビルドに依存するため動作しないことを意味します．こ
れを利用しないことも可能です(実際，Automakeユーザにはmake
distcheckを聞いたこともない人がたくさんいます)．それ以外の人々は，既
存のMakefileをVPATHをサポートするように改造するかもしれません．
そうすることの必要性をAutomakeが要求するわけではありませんが．Autoconf
だけは必要とします(see Build Directories)．必要となる代入は，Makefileの処
理でconfigureで定義される@scrdir@，
@top_srcdir@，そして@top_buildir@で(see Preset Output Variables)，それらは前述の$(distdir)と$(top_distdir)変数の
ようにMakefileで計算されません．
サードパーティーのMakefileが上記で要求されるターゲットを導入す るように編集するのは，不便なことも時々あります．例えば，新しいバージョ ンに簡単に更新できるようサードパーティのソースをいじらないようにしたい 人もいるかもしれません．
他にも二つの考えがあります．GNU makeと仮定する場合，一つの方法として，
要求されるターゲットを追加しサードパーティのMakefileをインクルー
ドしたGNUmakefileをサブディレクトリに追加することが可能です．
VPATHのビルドでこれを動作するため，GNUmakefileはディレクトリの
ビルドでだます必要があります．こうするための最も簡単な方法は，代わりに
これをGNUmakefile.inに書き，外部パッケージから
AC_CONFIG_FILESで処理させることです．例えば，Makefileで
ドキュメントのターゲット以外のすべてのターゲットを定義していると仮定し，
checkターゲットは実際にはtestで呼び出される場合，
GNUmakefile(またはGNUmakefile.in)を以下のように書くでしょ
う．
# First, include the real Makefile
include Makefile
# Then, define the other targets needed by Automake Makefiles.
.PHONY: dvi pdf ps info html check
dvi pdf ps info html:
check: test
includeを使用しない同じような考えは，本物のMakefileにルー
ルを送る，代わりのMakefileを書くことで，$(MAKE) -f
Makefile.real $(AM_MAKEFLAGS) target (オリジナルのMakefileの名
前を変更できる場合)，または，cd subdir && $(MAKE)
$(AM_MAKEFLAGS) target (サブディレクトリのプロジェクトの階層をもう一
つ深くできる場合)のいずれかを用います．この代わりのMakefileを
Automakeで生成可能だというのは，良い知らせでしょう．ルールを送りつける
-local ターゲット(see Extending)だけが必要です．もちろん，それ以外
のAutomakeの機能も利用可能なので，Automakeに配布とインストールを実行さ
せることを決定することも可能でしょう．以下は，実行可能な
Makefile.amです．
all-local:
cd subdir && $(MAKE) $(AM_MAKEFLAGS) all
check-local:
cd subdir && $(MAKE) $(AM_MAKEFLAGS) test
clean-local:
cd subdir && $(MAKE) $(AM_MAKEFLAGS) clean
# Assuming the package knows how to install itself
install-data-local:
cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-data
install-exec-local:
cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-exec
uninstall-local:
cd subdir && $(MAKE) $(AM_MAKEFLAGS) uninstall
# Distribute files from here.
EXTRA_DIST = subdir/Makefile subdir/program.c ...
このアイディアは最後の手段で，サブプロジェクトのビルドシステムを無視し， すべてをこの代わりのMakefile.amで生成します．これは，VPATHのビ ルドが必要でサブプロジェクトがそれをサポートしていない場合，非常に理に かなったものに感じるでしょう．