| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
さて，渦から渦まで頭を浮かせる(?)プログラムの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 を実行して，必要な補助ファイルを入手して，おしまいです！
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
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)\" |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
以下にもう一つの，トリッキーな例があります．それは同じソースファイル (`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 節 7.15 自動的な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'になるでしょう．(オブジェクトファ イルの名前が問題となることは滅多にありません．)
| [ << ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |