3. いくつかのパッケージの例

3.1 簡単なサンプル例の最初から最後まで

さて，渦から渦まで頭を浮かせる(?)プログラムのzardozを，たった今 書き終えたと仮定します．移植性のフレームワークを提供するためにAutoconf を使用していましたが，`Makefile.in'は特別に作成しました．それらを 堅牢にしたいのでAutomakeに切替えてみましょう．

第一歩はautomakeが必要とするコマンドを含めるため， `configure.ac'の更新を開始します．こうする方法は，AC_INIT の直後にAM_INIT_AUTOMAKEの呼び出しを加えることです．

AC_INIT(zardoz, 1.0)
AM_INIT_AUTOMAKE
...

プログラムには，(例えば，gettextを使用していないし，共有ライブ ラリもビルドしないし)複雑な要因が全くないので，この部分はおしまいです． なんて簡単なんでしょう！

さて`configure'を再生成する必要があります．しかしこうするためには， 使用している新しいマクロを見つける方法をautoconfに伝える必要が あります．こうするための最も簡単な方法は，`aclocal.m4'を生成する aclocalプログラムを使用することです．しかしちょっと待って下さい ...プログラムに対してちょっとマクロを書く必要があり，既に `aclocal.m4'があるかもしれません．aclocalプログラムでは， マクロを`acinclude.m4'に書いておく必要があるので，単純に名前を変 更して以下のように実行します．

mv aclocal.m4 acinclude.m4
aclocal
autoconf

さてzardozに対する`Makefile.am'を書く時間がやってきました． zardozはユーザプログラムなので，他のユーザプログラムがインストー ルされる場所にインストールしたいと思います．bindirです．さらに， zardozにはTexinfoドキュメントもあります．`configure.ac'ス クリプトではAC_REPLACE_FUNCSを使用するので，`$(LIBOBJS)' をリンクする必要があります．そのため以下のように書いたほうが良いでしょ う．

bin_PROGRAMS = zardoz
zardoz_SOURCES = main.c head.c float.c vortex9.c gun.c
zardoz_LDADD = $(LIBOBJS)

info_TEXINFOS = zardoz.texi

さて，`Makefile.in'を生成するためにautomake --add-missing を実行して，必要な補助ファイルを入手して，おしまいです！

3.2 古典的なプログラム

GNU helloは，古 典的単純さと融通性で有名です．このセクションでは，AutomakeをGNU Hello パッケージに使用する方法を示します．以下の例は，GNU Helloの最近のベー タバージョンからのものですが，著作権のコメント全体と同様に，管理者専用 のすべてのコードが取り除かれています．

もちろん，GNU Helloは伝統的な二行より幾分長くなっています．GNU Helloは 国際化されていて，オプション処理をして，そしてマニュアルとテストスイー トもあります．

GNU Helloの`configure.ac'は以下のようになっています．注意 して下さい: 例にあるAC_INITとAM_INIT_AUTOMAKEの呼出は， 推奨されない構文です．現在の手法は，5.6.1 パブリックマクロの AM_INIT_AUTOMAKEの記述を参照して下さい．

dnl Process this file with autoconf to produce a configure script.
AC_INIT(src/hello.c)
AM_INIT_AUTOMAKE(hello, 1.3.11)
AM_CONFIG_HEADER(config.h)

dnl Set of available languages.
ALL_LINGUAS="de fr es ko nl no pl pt sl sv"

dnl Checks for programs.
AC_PROG_CC
AC_ISC_POSIX

dnl Checks for libraries.

dnl Checks for header files.
AC_STDC_HEADERS
AC_HAVE_HEADERS(string.h fcntl.h sys/file.h sys/param.h)

dnl Checks for library functions.
AC_FUNC_ALLOCA

dnl Check for st_blksize in struct stat
AC_ST_BLKSIZE

dnl internationalization macros
AM_GNU_GETTEXT
AC_OUTPUT([Makefile doc/Makefile intl/Makefile po/Makefile.in \
           src/Makefile tests/Makefile tests/hello],
   [chmod +x tests/hello])

`AM_'マクロは，Automake(あるいはGettextライブラリ)によって提供さ れています．残りは標準的なAutoconfマクロです．

最上位の`Makefile.am'は以下のようになっています．

EXTRA_DIST = BUGS ChangeLog.O
SUBDIRS = doc intl po src tests

御覧のように，ここでの仕事はすべてサブディレクトリで実際に実行されます．

`po'と`intl'ディレクトリは，gettextizeを使用すること で自動的に生成されます．それらについてはここで述べません．

`doc/Makefile.am'は以下のようになっています．

info_TEXINFOS = hello.texi
hello_TEXINFOS = gpl.texi

これで，GNU Helloマニュアルをビルドして，インストールして，そして配布 するには十分です．

`tests/Makefile.am'は以下のようになっています．

TESTS = hello
EXTRA_DIST = hello.in testdata

`hello'スクリプトは，configureにより生成され，それはテスト ケースのみで生成されます．make checkでこのテストを実行します．

最後は`src／Makefile.am'で，実際にすべての仕事が行なわれる場所で す．

bin_PROGRAMS = hello
hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h
hello_LDADD = $(INTLLIBS) $(ALLOCA)
localedir = $(datadir)/locale
INCLUDES = -I../intl -DLOCALEDIR=\"$(localedir)\"

3.3 trueとfalseのビルド

以下にもう一つの，トリッキーな例があります．それは同じソースファイル (`true.c')から二つのプログラム(trueとfalse)を生成す る方法を示します．難しい部分は，それぞれの`true.c'のコンパイルで， 異なるcppフラグが必要になるということです．

bin_PROGRAMS = true false
false_SOURCES =
false_LDADD = false.o

true.o: true.c
        $(COMPILE) -DEXIT_CODE=0 -c true.c

false.o: true.c
        $(COMPILE) -DEXIT_CODE=1 -o false.o -c true.c

true_SOURCESの定義が無いことに注意してください．Automake は，ソー スファイル名`true.c'が存在すると暗黙に仮定し，`true.o'にコン パイルし，`true'にリンクするルールを定義します．上記の `Makefile.am'で提供されているtrue.o: true.cのルールは， Automakeが生成する`true.o'をビルドするためのルールに優先します．

false_SOURCESは空で定義されています -- その方法では，暗黙の値 で置換されません．`false'のソースでリストアップしていないので，プ ログラムをリンクする方法をAutomakeに伝える必要があります．これが false_LDADD行の目的です．false_DEPENDENCIES変数は `false'ターゲットの依存性を保持していて，false_LDADDの内容 からAutomakeが自動的に生成されます．

上記のルールは，コンパイラが`-c'と`-o'の両方を受け入れない場 合は動作しません．これを簡単に修正するため，(並行したmakeの問題 を避けるために)偽の依存性を導入します．

true.o: true.c false.o
        $(COMPILE) -DEXIT_CODE=0 -c true.c

false.o: true.c
        $(COMPILE) -DEXIT_CODE=1 -c true.c && mv true.o false.o

また，これらの明示的なルールは，de-ANSI-ficationが使用される場合は動作 しません(see section 8.14 自動的なde-ANSI-fication)．de-ANSI-ficationをサポートするためには，もう少 し多くの仕事が必要です．

true._o: true._c false.o
        $(COMPILE) -DEXIT_CODE=0 -c true.c

false._o: true._c
        $(COMPILE) -DEXIT_CODE=1 -c true.c && mv true._o false.o

お分かりのように，同じ作業を行なうため，よりいっそう簡単な方法もありま す．上記のテクニックには，マニュアルの例として残しておくには十分役に立 つものもあります．しかし，trueとfalseを現実的にビルドす る場合は，以下のように，おそらくプログラムごとにコンパイルのフラグを使 用することでしょう．

bin_PROGRAMS = false true

false_SOURCES = true.c
false_CPPFLAGS = -DEXIT_CODE=1

true_SOURCES = true.c
true_CPPFLAGS = -DEXIT_CODE=0

この状況では，Automakeによって，`true.c'は異なるフラグで二度コン パイルされることになります．de-ANSI-ficationは自動的に動作します．この 例では，オブジェクトファイルの名前はautomakeが選択します．それは `false-true.o'と`true-true.o'になるでしょう．(オブジェクトファ イルの名前が問題となることは滅多にありません．)