前: Extending, 上: Not Enough
ほとんどのプロジェクトで,すべてのMakefileはAutomakeで生成され ます.しかし,状況によっては手書きのMakefileをサブディレクトリ に配置する必要があるプロジェクトもあります.例えば,あるディレクトリは 独自のビルドシステムを用いたサードパーティーのプロジェクトで,それ以外 はAutomakeを使用していることもあるでしょう.
以下の再帰的なターゲットをすべて認識するMakefileがあるディレク
トリであれば,任意のディレクトリをSUBDIRS
やDIST_SUBDIRS
にリストアップすることが可能です.
ユーザが以下のターゲットを実行したとき,ターゲットはすべてのサブディレ クトリで再帰的に実行されます.これは,サードパーティーの Makefileがそれらをサポートしていることが重要である理由です.
all
distdir
$(distdir)
に配布すべきファイルをコピーし
ます.もちろん,このターゲットもno-dist
オプション
(see Optionsが使用されている場合は不要です.
変数$(top_distdir)
と$(distdir)
(see Dist)は,
distdir
ターゲットが呼び出されるとき,サブパッケージとなる外部パッ
ケージから渡されます.これら二つの変数は,再帰的になっているディレクト
リで調整されているので,すでに使用されています.
install
install-data
install-exec
uninstall
install-info
installdirs
check
installcheck
mostlyclean
clean
distclean
maintainer-clean
dvi
pdf
ps
info
html
tags
ctags
TAGS
と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のビ ルドが必要でサブプロジェクトがそれをサポートしていない場合,非常に理に かなったものに感じるでしょう.