| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Automakeの機能の大半は，プログラムとライブラリのビルドを容易にすること に費やされています．
| 8.1 プログラムのビルド | Building a program | |
| 8.2 ライブラリのビルド | Building a library | |
| 8.3 共有ライブラリのビルド | Building a Libtool library | |
| 8.4 プログラムとライブラリの変数 | Variables controlling program and library builds | |
8.5 デフォルトの_SOURCES | Default source files | |
| 8.6 LIBOBJSとALLOCAに対する特別扱い | Special handling for LIBOBJS and ALLOCA | |
| 8.7 プログラムビルド時に使用される変数 | Variables used when building a program | |
| 8.8 YaccとLexのサポート | Yacc and Lex support | |
| 8.9 C++のサポート | ||
| 8.10 アセンブラのサポート | ||
| 8.11 Fortran 77のサポート | ||
| 8.12 Javaのサポート | ||
| 8.13 他の言語のサポート | ||
| 8.14 自動的なde-ANSI-fication | Automatic de-ANSI-fication | |
| 8.15 自動的な依存性追跡 | Automatic dependency tracking | |
| 8.16 実行形式の拡張子のサポート | Support for executable extensions |
プログラムをビルドするために，その一部となるソースとリンクされるライブ ラリをAutomakeに伝える必要があります．
このセクションは，ソースやプログラムの条件付きコンパイルもカバーしてい ます．これらのコメントのほとんどは，ライブラリ(see section 8.2 ライブラリのビルド)と libtoolライブラリ(see section 8.3 共有ライブラリのビルド)に適用されます．
| 8.1.1 プログラムソースの定義 | Defining program sources | |
| 8.1.2 プログラムのリンク | Linking with libraries or extra objects | |
| 8.1.3 ソースの条件コンパイル | Handling conditional sources | |
| 8.1.4 プログラムの条件付コンパイル | Building program conditionally |
(ライブラリやスクリプトと比べて)プログラムにビルドされるソースを含んで
いるディレクトリには，`PROGRAMS'プライマリが使用されます．プログ
ラムを，bindir，sbindir，libexecdir，
pkglibdirにインストールしたり，または全くインストールしない
(noinst)ことが可能です．make checkに対してのみビルドさせ
ることも可能で，そのときは接頭辞は`check'になります．
例えば以下のようにします．
bin_PROGRAMS = hello |
この単純な状況では，結果として生成される`Makefile.in'に，
helloという名前のプログラムを生成するコードが含まれるでしょう．
それぞれのプログラムに関連して，プログラムの後に命名される補助変数もあ ります．これらの変数はすべてオプションで，妥当なデフォルト値を持ちます． それぞれの変数，その使用，そしてデフォルトについては以下で記述します． 我々は，"hello"の例を終始使用します．
変数hello_SOURCESは，実行形式にビルドされるソースファイルを指定
するために使用されます．
hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h |
これにより，上記のそれぞれの`.c'ファイルを，対応する`.o'にコ ンパイルします．そして，すべては`hello'を生成するためにリンクされ ます．
`hello_SOURCES'が指定されていない場合，そのデフォルトは一つのファ
イル`hello.c'になります(see section 8.5 デフォルトの_SOURCES)．
複数のプログラムを一つのディレクトリでビルドすることが可能です．複数の プログラムで単一のソースファイルを共有することが可能で，それぞれの `_SOURCES'定義でリストアップする必要があります．
`_SOURCES'定義にリストアップされているヘッダファイルは配布物に含 まれますが，それ以外のものは無視されます．明らかではないときは， `configure'で生成されるヘッダファイルを`_SOURCES'変数に含め るべきではありません．このファイルは配布すべきではありません． Lex(`.l')とYacc(`.y')のファイルもリストアップすることが可能 です．8.8 YaccとLexのサポートを参照して下さい．
configureで見つからないライブラリに対してリンクする必要がある場
合，そうするためにLDADDを使用することが可能です．この変数は，リ
ンクする追加のオブジェクトやライブラリを指定するために使用されます．そ
れは，特定のリンカフラグを指定するには不適切で，この目的では
AM_LDFLAGSを使用すべきです．
複数のプログラムが一つのディレクトリでビルドされていても，リンク時に同
じ条件を共有しないときもあります．この場合は，グローバルなLDADD
に優先させるため，`prog_LDADD'変数(ここでのprogはプロ
グラムの名前で，それは`_PROGRAMS'変数にあって，通常は小文字で書か
れています)を使用することが可能です．この変数が所定のプログラムに対し
て存在する場合，そのプログラムはLDADDを使用してリンクされません．
例えば，GNU cpioでは，pax，cpio，そしてmtは，
`libcpio.a'ライブラリにリンクされます．しかし，rmtは同じディ
レクトリでビルドされますが，そのようなリンクは必要ありません．また，
mtとrmtは特定のアーキテクチャでのみビルドされます．以下
は，cpioの`src/Makefile.am'に似たものです(省略されています)．
bin_PROGRAMS = cpio pax $(MT) libexec_PROGRAMS = $(RMT) EXTRA_PROGRAMS = mt rmt LDADD = ../lib/libcpio.a $(INTLLIBS) rmt_LDADD = cpio_SOURCES = ... pax_SOURCES = ... mt_SOURCES = ... rmt_SOURCES = ... |
`prog_LDADD'でプログラム独自のリンカフラグ(`-l'， `-L'，`-dlopen'そして`-dlpreopen'を除く)を渡すことは不 適当です．そのため，この目的に対しては`prog_LDFLAGS'変数を 使用してください．
実際にはプログラムの一部でない他のターゲットに依存するプログラムを持つ ことが役に立つこともあります．これは`prog_DEPENDENCIES'変数 を使用することで可能になります．それぞれのプログラムはこの変数の内容に 依存しますが，それ以上の解釈はされません．
`prog_DEPENDENCIES'が提供されていない場合，Automakeが考えま す．自動的に割り当てられる値は`prog_LDADD'の内容で，ほとん どのconfigureの置換式，`-l'，`-L'，`-dlopen'，そして `-dlpreopen'オプションは削除されます．残っているconfigureの置換式 は，`$(LIBOBJS)'と`$(ALLOCA)'だけです．これらは，生成される `prog_DEPENDENCIES'に無効な値を与えないことが知られているの で残されています．
configureの置換式(例えば，AC_SUBSTで定義されるFOO
を用いた`@FOO@'や`$(FOO)')を`_SOURCES' 変数に書き込む
ことはできません．この理由を説明するのは少し難しいのですが，単純に言っ
て動作しないということで十分でしょう．これを試みた場合，Automakeはエラー
を発します．
幸い，同じ結果を達成するために二つの別の方法があります．一つは，
configureの置換式を_LDADD変数で使用する方法で，もう一つ
は，Automakeの条件式を使用する方法です．
_LDADDの置換式を使用した条件コンパイル
Automakeは，すべてのファイルが全ての状況でビルドされるわけではない場合
でも，プログラムに組み込まれる可能性があるソースファイルをすべて知って
いる必要があります．条件によってのみビルドされるファイルは，適切な
`EXTRA_'変数でリストアップすべきです．例えば，条件によって
`hello-linux.c'や`hello-generic.c'をhelloに組み込む場
合，`Makefile.am'に以下のものを含めます．
bin_PROGRAMS = hello hello_SOURCES = hello-common.c EXTRA_hello_SOURCES = hello-linux.c hello-generic.c hello_LDADD = $(HELLO_SYSTEM) hello_DEPENDENCIES = $(HELLO_SYSTEM) |
`configure.ac'で$(HELLO_SYSTEM)の置換式を設定することが可
能です．
... case $host in *linux*) HELLO_SYSTEM='hello-linux.$(OBJEXT)' ;; *) HELLO_SYSTEM='hello-generic.$(OBJEXT)' ;; esac AC_SUBST([HELLO_SYSTEM]) ... |
この場合，HELLO_SYSTEMは`hello-linux.o'や
`hello-bsd.o'で置換され，ビルドしリンクするために
hello_DEPENDENCIESとhello_LDADDに追加されます．
条件によってソースファイルをコンパイルするためのより簡単な方法としては， Automakeの条件式を使用することが多くなっています．例えば，同じ `hello'の例をビルドするため，以下のような内容の`Makefile.am' を使用することが可能でしょう．
bin_PROGRAMS = hello if LINUX hello_SOURCES = hello-linux.c hello-common.c else hello_SOURCES = hello-generic.c hello-common.c endif |
この場合，`configure.ac'でAM_CONDITIONALを使用して
LINUX条件式を設定する必要があります(see section 20. 条件文)．
Automakeは，ソースファイルの完全なリストを構成するためにそれぞれの変数 の内容を調査するので，このような条件を使用するときは，`EXTRA_'変 数を使用する必要はありません．
プログラムで多くのファイルを使用している場合，おそらく条件付の
+=のほうが望ましいでしょう．
bin_PROGRAMS = hello hello_SOURCES = hello-common.c if LINUX hello_SOURCES += hello-linux.c else hello_SOURCES += hello-generic.c endif |
ビルドされるプログラムをconfigure時に決定することが役に立つときもあり
ます．例えば，GNU cpioは特別な状況のときだけmtと
rmtをビルドします．プログラムの条件付きコンパイルを達成するとい
う意味は，ソースファイルのコンパイルを条件的に行なうことと一緒です．置
換式を用いたり条件式を用いたりします．
configureの置換式を使用した条件的プログラム
この場合は，ビルドされる可能性のあるすべてのプログラムをAutomakeに知ら
せる必要がありますが，同時に，configureで指定されるプログラムを
使用するように`Makefile.in'を生成させる必要もあります．このことは，
それぞれの`_PROGRAMS'定義にconfigureでの置換式の値を持たせ
ることで行なわれますが，一方では，EXTRA_PROGRAMSでオプションと
してビルドされるプログラムがすべてリストアップされています．
bin_PROGRAMS = cpio pax $(MT) libexec_PROGRAMS = $(RMT) EXTRA_PROGRAMS = mt rmt |
8.16 実行形式の拡張子のサポートの説明として，Automakeは$(EXEEXT)をそれぞれのバイナ
リに付加して，bin_PROGRAMS，libexec_PROGRAMS，そして
EXTRA_PROGRAMSを書き換えます．configureの置換式で，実行
時に値を明示的に書き換えることは明らかに不可能なので，
AC_SUBST([MT], ['mt${EXEEXT}'])の様に$(EXEEXT)を付加す
ることには気を付けて下さい．
ビルドするプログラムを選択するため，Automakeの条件式を
(see section 20. 条件文)使用することも可能です．この状況では，
$(EXEEXT)やEXTRA_PROGRAMSに気を付ける必要はありません．
bin_PROGRAMS = cpio pax if WANT_MT bin_PROGRAMS += mt endif if WANT_RMT libexec_PROGRAMS = rmt endif |
ライブラリをビルドすることは，プログラムをビルドすることによく似ていま
す．この場合は，プライマリの名前は`LIBRARIES'です．ライブラリは
libdirやpkglibdirにインストールされます．
libtoolと`LTLIBRARIES'プライマリを使用して共有ライブラリをビルド する方法についての詳細は，See section 8.3 共有ライブラリのビルド.
それぞれの`_LIBRARIES'変数は，ビルドされるライブラリのリストです． 例えば，`libcpio.a'という名前のライブラリを作成し，それをインストー ルしないため，以下のように書きます．
noinst_LIBRARIES = libcpio.a |
ライブラリに組み込まれるソースは，プログラムのときのように， `_SOURCES'変数によって正しく決定されます．ライブラリ名は標準的に されるので(see section 2.4 派生される変数と命名法)，`liblob.a'に対応する `_SOURCES'変数は`liblob.a_SOURCES'ではなく `liblob_a_SOURCES'になることに注意してください．
追加のオブジェクトは，`library_LIBADD'変数を使用してライブ
ラリに追加することが可能です．これはconfigureで決定されるオブジェ
クトに対して使用されるべきです．再びcpioからの引用です．
libcpio_a_LIBADD = $(LIBOBJS) $(ALLOCA) |
さらに，configure時まで存在しない追加のオブジェクトに対するソースは，
BUILT_SOURCES変数に追加する必要があります(see section 9.4 ビルドされているソース)．
スタティックライブラリをビルドすることは，すべてのオブジェクトファイル
をコンパイルし，その後で$(AR) $(ARFLAGS)にライブラリ名とオブジェ
クトのリストを続けたものを呼び出し，そして最後にライブラリで
$(RANLIB)を呼び出すことで達成されます．RANLIBを定義する
ため，AC_PROG_RANLIBを`configure.ac'から呼び出すべきです
(そうしなければ，Automakeは文句を言います)．ARとARFLAGS
のデフォルトはそれぞれarとcruです．これらの二つの変数を
`Makefile.am'で設定する，`configure.ac'でAC_SUBSTする，
または，ライブラリごとにmaude_AR変数で定義することで優先させる
ことが可能です(see section 8.4 プログラムとライブラリの変数)．
移植性の高い共有ライブラリをビルドすることは比較的複雑な問題です．この ために，GNU Libtoolは(see section `Introduction' in The Libtool Manual)プラットホームに依存しない方法で共有ライブラリをビルドする補助 を行なうために作成されました．
| 8.3.1 Libtoolの概念 | Introducing Libtool | |
| 8.3.2 Libtoolライブラリのビルド | Declaring Libtool Libraries | |
| 8.3.3 Libtoolライブラリのビルドの条件分岐 | Building Libtool Libraries Conditionally | |
| 8.3.4 条件的ソースを用いたLibtoolライブラリ | Choosing Library Sources Conditionally | |
| 8.3.5 Libtoolのコンビニエンスライブラリ | Building Convenience Libtool Libraries | |
| 8.3.6 Libtoolのモジュール | Building Libtool Modules | |
| 8.3.7 _LIBADDと_LDFLAGS | Using _LIBADD and _LDFLAGS | |
8.3.8 LTLIBOBJS | Using $(LTLIBOBJ) | |
| 8.3.9 Libtoolの使用に関連する一般的な問題 | Common Issues Related to Libtool's Use |
Libtoolは，共有ライブラリとスタティックライブラリを統一した概念で，
libtoolライブラリ(libtool libraries)と呼ばれるものに抽出します．
Libtoolライブラリは`.la'接尾子を使用しているファイルで，スタティッ
クライブラリ，共有ライブラリ，または両方を表します．正確な性質は
`./configure'が実行されるまで決定することは不可能です．すべてのプ
ラットフォームですべての種類のライブラリをサポートしているわけではあり
ませんし，ユーザは明示的にビルドするライブラリを選択するすることも可能
です．(しかし，パッケージの管理者はデフォルトを調整することが可能です．
See section `The AC_PROG_LIBTOOL macro' in The Libtool Manual.)
共有ライブラリとスタティックライブラリのオブジェクトファイルは，別々に コンパイルする必要があるので，libtoolはコンパイル時にも使用されます． libtoolでビルドされたライブラリは，libtoolオブジェクト(libtool objects)と呼ばれます．これらは，`.lo'接尾子を利用しているファイ ルです．libtoolライブラリはこれらのlibtoolオブジェクトからビルドされま す．
`.la'や`.lo'ファイルの構造や，libtoolがそれらを構築する方法 を仮定すべきではありません．これはlibtoolが考えることで，最後のものは libtoolの中身を勉強したい人が欲しいものです．しかし，これらのファイル は，libtoolライブラリをビルドするとき，`Makefile'ルール内のターゲッ トと依存性として使用されるので，その存在が重要になります．例えば，条件 的にソースファイルをビルドする依存性を表現するとき，これらを参照する必 要がある状況があります(see section 8.3.4 条件的ソースを用いたLibtoolライブラリ)．
動的にロードされるモジュールとなっているプラグインシステムを書こうと考 えている人々は，`libltdl'の中を見るべきです．libtoolによるライブ ラリのdlopenです(see section `Using libltdl' in The Libtool Manual)．これは，libtoolライブラリを動的にロードするための移 植性の高いdlopenを提供し，やむをえないところではスタティックにリンクす ることも可能です．
我々がAutomakeを用いてlibtoolを使用する方法の詳細を議論する前に， libtoolマニュアルにあるlibtoolとともにAutomakeを使用する方法に付いて書 かれているセクションにも注意しておくべきです(see section `Using Automake with Libtool' in The Libtool Manual)．
Automakeは，`LTLIBRARIES'プライマリで宣言されたライブラリをビルド するためにLibtoolを使用します．それぞれの`_LTLIBRARIES'変数はビル ドするlibtoolライブラリのリストです．例えば，`libgettext.la'とい う名前のlibtoolライブラリを作成し，`libdir'にインストールするため に，以下のように書いてください．
lib_LTLIBRARIES = libgettext.la libgettext_la_SOURCES = gettext.c gettext.h ... |
Automakeは変数`pkglibdir'を前もって定義しているので，ライブラリを
$(libdir)/@PACKAGE@/にインストールするために，
pkglib_LTLIBRARIESを使用することが可能です．
プログラムの条件式のように(see section 8.1.4 プログラムの条件付コンパイル)，ライブラリの
条件付きビルドにも主に二つの方法があります．Automakeの条件式を使用する
方法と，AutoconfのAC_SUBSTを使用する方法です．
気を付けるべき重要な実装の詳細は，ライブラリがインストールされる場所が
libtoolにとって重要だということです．それは，-rpathオプションを
使用してリンク時に示されるものが必要になります．
Automakeの実行時にインストール先のディレクトリが分かっているライブラリ
に対し，Automakeは自動的に適切な`-rpath'オプションをlibtoolに供給
します．これは，lib_LTLIBRARIESのように，インストール可能な
_LTLIBRARIESに明示的にリストアップされているライブラリの場合で
す．
しかし，configure時に決定される(EXTRA_LTLIBRARIESに記述されてい
る)ライブラリに対して，Automakeは最終的なインストールディレクトリが分
かりません．そのようなライブラリに対して，適切な`_LDFLAGS'変数に
`-rpath'オプションを手動で追加する必要があります．
以下の例で，これら二つの手法の違いを説明します．
この例は，$(WANTEDLIBS)がAC_SUBSTされている変数で，
`./configure'時に`libfoo.la'，`libbar.la'，その両方，ま
たは空で設定されます．$(WANTEDLIBS)はlib_LTLIBRARIESに書
かれていますが，Automakeは，それが`libfoo.la'または
`libbar.la'に関連付けされることを，これら二つのライブラリに対する
リンクルールが作成されるときまで推測することが不可能です．このため，特
に-rpath引数を提供する必要があります．
EXTRA_LTLIBRARIES = libfoo.la libbar.la lib_LTLIBRARIES = $(WANTEDLIBS) libfoo_la_SOURCES = foo.c ... libfoo_la_LDFLAGS = -rpath '$(libdir)' libbar_la_SOURCES = bar.c ... libbar_la_LDFLAGS = -rpath '$(libdir)' |
これは，同じ`Makefile.am'で，WANT_LIBFOOと
WANT_LIBBARという名前のAutomakeの条件式を使用しているものがあり
ます．Automakeは，両方のライブラリをインストールする場合，結局
$(libdir)になることが明らかなので，-rpathの設定を自分で
計算することが可能です．
lib_LTLIBRARIES = if WANT_LIBFOO lib_LTLIBRARIES += libfoo.la endif if WANT_LIBBAR lib_LTLIBRARIES += libbar.la endif libfoo_la_SOURCES = foo.c ... libbar_la_SOURCES = bar.c ... |
ライブラリでのソースの条件的コンパイルは，プログラムでのソースの条件的
コンパイルと同じ方法で達成することが可能です(see section 8.1.3 ソースの条件コンパイル)．違いは，_LDADDの代わりに_LIBADDを使用し，
libtoolオブジェクト(`.lo'ファイル)について記述することだけです．
そのため，8.1.3 ソースの条件コンパイルの`hello'の例を真似てみると， 以下のような`Makefile.am'を用いて`hello-linux.c'または `hello-generic.c'のいずれかを使用して`libhello.la'ライブラリ をビルドすることが可能でしょう．
lib_LTLIBRARIES = libhello.la libhello_la_SOURCES = hello-common.c EXTRA_libhello_la_SOURCES = hello-linux.c hello-generic.c libhello_la_LIBADD = $(HELLO_SYSTEM) libhello_la_DEPENDENCIES = $(HELLO_SYSTEM) |
そして，$(HELLO_SYSTEM)が`./configure'で
`hello-linux.lo'または`hello-generic.lo'のいずれかに設定され
ていることを確かめて下さい．
また，Automake条件式を使用して以下のように簡単にすることも可能でしょう．
lib_LTLIBRARIES = libhello.la libhello_la_SOURCES = hello-common.c if LINUX libhello_la_SOURCES += hello-linux.c else libhello_la_SOURCES += hello-generic.c endif |
インストールされないlibtoolライブラリをビルドしたいときもあります．こ れらは，libtoolコンビニエンスライブラリ(libtool convenience libraries)と呼ばれ，通常多くのサブライブラリをカプセル化し，後でイン ストールされる大きな一つのライブラリにまとめるときに使用されます．
libtoolコンビニエンスライブラリは，noinst_LTLIBRARIES，
check_LTLIBRARIES，またはEXTRA_LTLIBRARIESでも宣言されま
す．インストールされるlibtoolライブラリと異なり，それらはリンク時に
-rpathフラグが不要です(実際，これが違うだけです)．
noinst_LTLIBRARIESでリストアップされているコンビニエンスライブ
ラリは，常にビルドされます．check_LTLIBRARIESにリストアップされ
ているものは，make checkのときだけビルドされます．最後に，
EXTRA_LTLIBRARIESでリストアップされているライブラリは，明示的に
はビルドされません．Automakeはそれらのビルドルールを出力しますが，ライ
ブラリがMakefileの依存性に表れない場合はビルドされません(これは，
EXTRA_LTLIBRARIESが条件付きコンパイルで使用されるためです)．
サブディレクトリのlibtoolコンビニエンスライブラリを，一つの中心となる `libtop.la'ライブラリにまとめる設定例は以下のようになります．
# -- Top-level Makefile.am -- SUBDIRS = sub1 sub2 ... lib_LTLIBRARIES = libtop.la libtop_la_SOURCES = libtop_la_LIBADD = \ sub1/libsub1.la \ sub2/libsub2.la \ ... # -- sub1/Makefile.am -- noinst_LTLIBRARIES = libsub1.la libsub1_la_SOURCES = ... # -- sub2/Makefile.am -- # showing nested convenience libraries SUBDIRS = sub2.1 sub2.2 ... noinst_LTLIBRARIES = libsub2.la libsub2_la_SOURCES = libsub2_la_LIBADD = \ sub21/libsub21.la \ sub22/libsub22.la \ ... |
これらは，dlopenされることを意味するlibtoolライブラリです．それらは，
リンク時に-moduleをlibtoolに渡すことで示されます．
pkglib_LTLIBRARIES = mymodule.la mymodule_la_SOURCES = doit.c mymodule_LDFLAGS = -module |
通常，Automakeは共有ライブラリの名前が`lib'で始まることを要求しま す．しかし，動的にロードされるモジュールをビルドしている場合，"標準的 でない" 名前を使用したいかもしれません．
`mymodule_la_SOURCES'が指定されていない場合，そのデフォルトは単一
ファイルの`mymodule.c' (see section 8.5 デフォルトの_SOURCES)です．
前のセクションで見てきたように，`library_LIBADD'変数は， libraryに追加する補助的なlibtoolオブジェクト(`.lo'ファイル) やlibtoolライブラリ(`.la')をリストアップするために使用すべきです．
`library_LDFLAGS'変数には，`-version-info'， `-static'，などの追加のlibtoolフラグをリストアップします． See section `Using libltdl' in The Libtool Manual.
LTLIBOBJS
通常のライブラリは$(LIBOBJS)に含まれますが，libtoolライブラリは
$(LTLIBOBJS)を使用する必要があります．libtoolが処理するオブジェ
クトファイルは，最終的に`.o'にする必要がないため，このように要求
されます．
現在，LIBOBJSからLTLIBOBJSを求めることはAutoconfが自動的
に実行します(see section `AC_LIBOBJ vs. LIBOBJS' in The Autoconf Manual)．
libtoolは，パッケージにlibtoolのサポートを行なうファイルをインストール
するlibtoolizeと呼ばれるツールから生じます．このコマンドを実
行すると，`ltmain.sh'がインストールされます．aclocalと
automakeの前にそれを実行すべきです．
古いパッケージから新しいautotoolにアップグレードすると，古いバージョン
のAutomakeはlibtoolizeと呼ばれるものを使用していたのでこの問
題に直面します．このため，古いビルドスクリプトではlibtoolize
を呼び出しません．
Automake1.6から，libtoolizeの実行がAutomakeの仕事ではないと
決定しました．その代わり，その機能はautoreconfコマンドに渡さ
れました(see section `Using autoreconf' in The Autoconf Manual)．いつ何を実行するのか覚えたくない場合，
autoreconfコマンドだけを勉強して下さい．希望的には，既存の
`bootstrap.sh'や`autogen.sh'スクリプトをautoreconf
の呼び出しに置換することで，将来においても同様の互換性の無い変更から自
由になれるでしょう．
同じソースファイルが，libtoolライブラリのビルドと，libtoolではない他の ターゲット(プログラムだったり，他のライブラリだったりします)をビルドす るために使用されることもあります．
以下の`Makefile.am'を考えてみましょう．
bin_PROGRAMS = prog prog_SOURCES = prog.c foo.c ... lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = foo.c ... |
(この平凡な状況では，prog_SOURCESにリストアップされている
`foo.c'の代わりに，`prog'を用いて`libfoo.la'をリンクす
ることを避けることで，問題を回避することが可能です．しかし，実際には
`prog'と`libfoo.la'は別々に保持したいと仮定します．)
技術的には，我々は`prog'に対して`foo.$(OBJEXT)'をビルドし， `libfoo.la'に対して`foo.lo'をビルドべきだということを意味し ます．問題は，`foo.lo'を作成する仮定で，libtoolが `foo.$(OBJEXT)'を削除(または置換)する可能性があるということです -- これは避けられません．
このため，Automakeがこの状況を検出すると，以下のようなメッセージで文句 を言います．
object `foo.$(OBJEXT)' created both with libtool and without |
この問題を回避する方法は，これら二つのオブジェクトを確実に異なるベース 名にすることです．26.5 なぜオブジェクトファイルの名前を変更することがあるのですか？で説明されているように，ターゲッ トごとのフラグが使用されているとき，これは自動的に行なわれます．
bin_PROGRAMS = prog prog_SOURCES = prog.c foo.c ... prog_CFLAGS = $(AM_CFLAGS) lib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = foo.c ... |
prog_CFLAGS = $(AM_CFLAGS)の追加は，prog_CFLAGSが定義さ
れているとき，AM_CFLAGSの代わりにそれを使用するので，ほとんど何
もしません．しかし，副作用として，`prog.c'と`foo.c'を
`prog-prog.$(OBJEXT)'と`prog-foo.$(OBJEXT)'にコンパイルし，
問題を解決することになります．
それぞれのプログラムに関連して，プログラムのビルドの方法を修正するため に使用可能な変数の集合があります．それぞれのライブラリに対しても，それ に似たような変数のリストがあります．プログラム(やライブラリ)の標準的な 名前が，これらの変数の命名に対してベースとして使用されます．
以下のリストでは，名前"maude"をプログラムやライブラリを示すものとし て使用しています．`Makefile.am'で，これをプログラムの標準的な名前 に置換してください．このリストは，"maude"をプログラムを示すものとし ていますが，一般的に同じルールを，スタティックライブラリやダイナミック ライブラリに適用します．以下の文章では，プログラムとライブラリで異なる 状況をコメントしています．
接頭辞の`dist_'と`nodist_'で，`_SOURCES'にリストアップ されているファイルを配布するかどうか制御するために使用することが可能で す．ソースはデフォルトで配布されるので，`dist_'は冗長ですが，必要 があれば明確にするために指定可能です．
`_SOURCES'変数に与えるものとして`dist_'と`nodist_'の両 方を一度に用いることが可能です．これによって，配布するファイルとしない ものに簡単に分類することができ，例えば以下のようにします．
nodist_maude_SOURCES = nodist.c dist_maude_SOURCES = dist-me.c |
デフォルトで，出力ファイル(Unixシステム上では`.o'ファイル)は，現
在のビルドディレクトリに書き込まれます．しかし，現在のディレクトリに対
してオプションのsubdir-objectsの影響がある場合，`.o'ファイ
ルはソースファイルの後で指名されるサブディレクトリに書き込まれます．例
えば，subdir-objectsが利用可能な場合，`sub/dir/file.c'は
`sub/dir/file.o'にコンパイルされます．この処理モードを好む人もい
ます．subdir-objectsをAUTOMAKE_OPTIONSで指定することが可
能です(see section 17. Automakeの動作の変更)．
この変数は，例えば`nodist_EXTRA_maude_SOURCES'のように， `dist_'と`nodist_'もサポートします．
$(AR) $(ARFLAGS)にライ
ブラリ名とライブラリに書き込むオブジェクトを続けて呼び出すことで作成さ
れます．`_AR'変数でこれに優先することが可能です．これは，通常C++
で使用されます．C++コンパイラには，ライブラリに組み込むすべてのテンプ
レートを生成するために，特殊な呼び出しが必要なものもあります．例えば，
SGI C++コンパイラは，この変数を以下のように設定します．
libmaude_a_AR = $(CXX) -ar -o |
configureで決定される
オブジェクトに対して使用すべきです(see section 8.2 ライブラリのビルド)．
configureで決定されるオブジェクトに対して使用すべきです
(see section 8.1.2 プログラムのリンク)．
(`-l'，`-L'，`-dlopen'，そして`-dlpreopen'以外の) プログラム特有のリンカフラグを渡すために`_LDADD'と`_LIBADD' を使用することは不適切です．この目的に対しては，`_LDFLAGS'変数を 使用してください．
例えば，`configure.ac'でAC_PATH_XTRAを使用している場合，X
のライブラリに対してプログラムをリンクするため，以下のようにすることが
可能でしょう．
maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS) |
`_DEPENDENCIES'が提供されていない場合，それはAutomakeが考慮します． 自動的に割り当てられる値は`_LDADD'や`_LIBADD'の内容で，ほと んどのconfigure置換式，`-l'，`-L'，`-dlopen'， `-dlpreopen'，そして`-dlpreopen'オプションは削除されています． 残っているconfigureの置換式は，`$(LIBOBJS)'と`$(ALLOCA)'です． これらは，生成される`_DEPENDENCIES'に対して無効な値を生成しないこ とが分かっているので残されます．
maude_LINK = $(CCLD) -magic -o $@ |
ターゲットごとのコンパイルフラグを使用するとき，Automakeは，中間的なオ ブジェクトファイルに対して異なる名前を選択します．通常， `sample.c'のようなファイルは，コンパイルされて`sample.o'が生 成されます．しかし，プログラムの`_CFLAGS'変数を設定した場合，オブ ジェクトファイルは，例えば`maude-sample.o'のように命名されます． (26.5 なぜオブジェクトファイルの名前を変更することがあるのですか？も参照して下さい．)
ターゲットごとにフラグを用いてコンパイルする際は，通常の`AM_'形式 のフラグ変数は自動的にコンパイルに組み込まれません(しかし，ユー ザ形式の変数は組み込まれます)．そのため，例えば， `AM_CFLAGS'の変数も使用して`maude'のコンパイルを行なうと仮定 すると，以下のように書く必要があります．
maude_CFLAGS = ... your flags ... $(AM_CFLAGS) |
bin_PROGRAMS = maude maude_CPPFLAGS = -DSOMEFLAG maude_SHORTNAME = m maude_SOURCES = sample.c ... |
オブジェクトファイルは`maude-sample.o'ではなく`m-sample.o'と 命名されます．
この機能は，実行上滅多に必要になりませんし，要求されていることが分かる まで使用を避けることを推奨します．
_SOURCES
_SOURCES変数は，プログラム(see section 8.1 プログラムのビルド)，ライブラリ
(see section 8.2 ライブラリのビルド)，そしてLibtoolライブラリ(see section 8.3 共有ライブラリのビルド)
のソースファイルを指定するために使用します．
そのような変数がターゲットに対して指定されていない場合，Automakeは独自 に定義します．デフォルトは，コンパイルする単一のCファイルで，その名前 はターゲット自身の名前を元にしていて，拡張子を`.c'に置換したもの です．(Cのデフォルトは危険ですが，我々は歴史的な理由で身動きがとれなく なっています．)
例えば，以下のような`Makefile.am'があって，対応する `libfoo_a_SOURCES'が無い場合を考えます．
lib_LIBRARIES = libfoo.a sub/libc++.a |
`libfoo.a'はデフォルトのソースファイル名`libfoo.c'を使用して ビルドされ，`sub/libc++.a'は`sub/libc++.c'からビルドされます． (より古いバージョンでは，`sub/libc++.a'は`sub_libc___a.c'か ら，すなわちデフォルトのソースはターゲットの標準的な名前に`.c'を 追加したものでした．新しい動作はより賢明だと信じていますが，下位互換性 として，その名前のファイルやルールが存在する場合，automakeは古い名前を 使用します．)
デフォルトのソースは，たくさんのテストプログラムをそれぞれ単一のソース からビルドする，テストスイートで主に役に立ちます．例えば以下のようにし ます．
check_PROGRAMS = test1 test2 test3 |
`test1'，`test2'，そして`test3'は，それぞれ `test1.c'，`test2.c'，そして`test3.c'からビルドされます．
これが便利になるもう一つの状況は，独自のファイル(`moduleN.c')で定 義されている多くのLibtoolモジュール(`moduleN.la')をビルドするとき です．
AM_LDFLAGS = -module lib_LTLIBRARIES = module1.la module2.la module3.la |
おしまいに，このデフォルトのソースを求めることを避ける必要がある状況が
一つあります．ターゲットがソースからビルドされないときです．我々は
3.3 trueとfalseのビルドでそのような例を見てきました．これは，ターゲットのすべての構
成要素が既にコンパイルされていて，単に_LDADD変数を使用して結合
する必要があるときに生じます．そして，automakeがデフォルトを求めないよ
うに空の_SOURCES変数を定義する必要があります．
bin_PROGRAMS = target target_SOURCES = target_LDADD = libmain.a libmisc.a |
Automakeは，$(LIBOBJS)と$(ALLOCA)を使用していることを明
示的に認識し，そしてこの情報を使用し，配布物に適切なソースファイルを自
動的に含めるため(see section 14. 配布物に含まれるもの)，`configure.ac'から派生される
LIBOBJSファイルのリストに追加します．これらのソースファイルは，
依存性追跡でも自動的に処理されます．See section 8.15 自動的な依存性追跡.
$(LIBOBJS)と$(ALLOCA)は，あらゆる`_LDADD'や
`_LIBADD'で特別に認識されます．
Automakeがコンパイルに使用する`Makefile'変数を知ることが役に立ち つこともあります．例えば，特別な状況では，自分でコンパイルをする必要が あるかもしれません．
Autoconfから継承される変数もあります．これらはCC，CFLAGS，
CPPFLAGS，DEFS，LDFLAGS，そしてLIBSです．
Automake自身が定義する追加の変数もあります．
AM_CPPFLAGS
Automakeは，すでに`-I'オプションを自動的に提供しています．特に，
`-I$(srcdir)'，`-I.'，そして(AC_CONFIG_HEADERSや
AM_CONFIG_HEADERを使用している場合は)`config.h'があるディ
レクトリを示す`-I'を生成します．`nostdinc'オプションを使用す
ることで，デフォルトの`-I'オプションを利用不可能にすることが可能
です．
実行形式ごと(またはライブラリごと)に_CPPFLAGS変数が定義されてい
る場合，それを優先するので，AM_CPPFLAGSは無視されます．
INCLUDES
AM_CFLAGS
_CFLAGSが優
先され，これは使用されません．
COMPILE
AM_LDFLAGS
_LDFLAGSが優先され，これは使用されません．
LINK
CFLAGS)が
含まれています．それは，リンクされるオブジェクトファイルとライブラリの
名前を"引数"として受けとります．
AutomakeはYaccとLexに対して幾分特異なサポートを行ないます．
Automakeは，yacc(あるいはlex)によって生成された`.c'
ファイルが，入力ファイルのベース名を使用して命名されていると仮定します．
すなわち，yaccソースファイル`foo.y'に対して，Automakeは中間ファイ
ルを(より伝統的な`y.tab.c'ではなく)`foo.c'と命名します．
yaccソースファイルの拡張子は，結果として生じる`C'あるいは `C++' ファイルの拡張子を決定するために使用されます．ファイルの拡 張子が`.y'の場合は`.c'になります．同様に`.yy'は `.cc'に，`.y++'は`c++'に，そして`.yxx'は `.cxx'になります．
同様に，lexソースファイルは，`C'や`C++'を生成するために使用 することが可能です．拡張子の`.l'，`.ll'，`.l++'，そして `.lxx'が認識されます．
あらゆる`SOURCES'変数に，(`C'や`C++'の)中間的なファイル を明示的に書いてはいけません．ソースファイルだけをリストアップします．
yacc(あるいはlex)によって生成さる中間的なファイルは，作
成されるすべての配布物に含められます．そのためユーザがyaccや
lexを持っている必要がありません．
yaccソースファイルが見つかった場合，`configure.ac'で変数
`YACC'を定義する必要があります．これは，マクロ`AC_PROG_YACC'
を呼び出すことで最も容易に行なえます(see section `Particular Program Checks' in The Autoconf Manual)．
yaccが呼び出された時，`YFLAGS'と`AM_YFLAGS'フラグが渡
されます．前者はユーザ変数で，後者は`Makefile.am'の著者のためのも
のです．
`AM_YFLAGS'は通常，-dオプションをyaccに渡すとき使用
されます．Automakeはこれが意味するところを知っていて，yacc -dで
ビルドされるヘッダファイルの更新と配布のルールを，自動的に調整します．
しかし，Automakeが分からないものは，このヘッダが使用される場所です．ヘッ
ダが最初に使用される前にヘッダをビルドしておくことはあなたの責任です．
通常これは，ヘッダが他のファイルからインクルードされているとき，依存性
の追跡が動作するために必要となります．一般的な解決策は，ヘッダファイル
を以下のようにBUILT_SOURCES (see section 9.4 ビルドされているソース)にリストアップする
ことです．
BUILT_SOURCES = parser.h AM_YFLAGS = -d bin_PROGRAMS = foo foo_SOURCES = ... parser.y ... |
同様に，lexソースファイルがある場合，`configure.ac'で変数
`LEX'を定義する必要があります．こうするために`AC_PROG_LEX'を
使用することが可能ですが(see section `Particular Program Checks' in The Autoconf Manual)，AM_PROG_LEXマ
クロ(see section 5.6 Automakeが提供するAutoconfマクロ)の使用を推奨します．
lexが呼び出されたとき，`LFLAGS'と`AM_LFLAGS'フラグが
渡されます．前者はユーザ変数で，後者は`Makefile.am'の著者のための
ものです．
Automakeで，一つのプログラムに複数のyacc(またはlex)ソー
スファイルを含めることが可能になります．ディレクトリに一つ以上の異なる
yacc(またはlex)のソースファイルがあるとき，Automakeは，
サブディレクトリでyacc(またはlex)を実行するために，
ylwrapと呼ばれる小さいプログラムを使用します．これが必要になる
のは，yaccの出力ファイル名が固定されていて，並列的なmakeでyacc
の一つ以上のインスタンスを同時に呼び出す可能性があるためです．
ylwrapプログラムは，Automakeと一緒に配布されます．それは
`AC_CONFIG_AUX_DIR'が指定するディレクトリ (see section `Finding `configure' Input' in The Autoconf Manual)，または，そ
のマクロが`configure.ac'で使用されていない場合はカレントディレク
トリにあります．
yaccに対しては，簡単なロックでの管理は不十分です．yaccの
出力は，内部で常に同じシンボル名を使うので，同じ実行形式の中に二つの
yaccパーサーをリンクするは不可能です．
gdbでは，使用する名前を以下のように変更してください．
#define yymaxdepth c_maxdepth #define yyparse c_parse #define yylex c_lex #define yyerror c_error #define yylval c_lval #define yychar c_char #define yydebug c_debug #define yypact c_pact #define yyr1 c_r1 #define yyr2 c_r2 #define yydef c_def #define yychk c_chk #define yypgo c_pgo #define yyact c_act #define yyexca c_exca #define yyerrflag c_errflag #define yynerrs c_nerrs #define yyps c_ps #define yypv c_pv #define yys c_s #define yy_yys c_yys #define yystate c_state #define yytmp c_tmp #define yyv c_v #define yy_yyv c_yyv #define yyval c_val #define yylloc c_lloc #define yyreds c_reds #define yytoks c_toks #define yylhs c_yylhs #define yylen c_yylen #define yydefred c_yydefred #define yydgoto c_yydgoto #define yysindex c_yysindex #define yyrindex c_yyrindex #define yygindex c_yygindex #define yytable c_yytable #define yycheck c_yycheck #define yyname c_yyname #define yyrule c_yyrule |
それぞれの定義に対して，`c_'接頭辞は好みのものに置き換えて下さい．
これらは，bison，byacc，そして伝統的なyaccに対す
る動作を定義します．パーサジェネレータが，ここでカバーされていないシン
ボルを使用していることが分かった場合，リストに加えることができるように，
新しい名前を報告してください．
Automakeには，C++に対する完全なサポートが含まれています．
C++コードを含んでいるすべてのパッケージでは，`configure.ac'で出力
変数`CXX'を定義する必要があります．これを行う最も単純な方法は，
AC_PROG_CXXマクロを使用することです(see section `Particular Program Checks' in The Autoconf Manual)．
C++ソースファイルがあるとき，少しだけ追加変数が定義されます．
CXX
CXXFLAGS
AM_CXXFLAGS
CXXFLAGSです．
CXXCOMPILE
CXXLINK
Automakeは，アセンブラコードに対するサポートも含んでいます．
変数CCASには，アセンブラコードをビルドするために使用するコンパ
イラ名が保持されています．このコンパイラは，Cコンパイラにちょっと似て
いる動作をする必要があります．特に，それは`-c'と`-o'を受け入
れる必要があります．CCASFLAGSの値はコンパイラに渡されます．
`configure.ac'でCCASとCCASFLAGSを設定する必要があり
ます．autoconfマクロのAM_PROG_ASでこれを行ないます．前もって設
定されていない場合は，CCASをCコンパイラに， CCASFLAGSをC
コンパイラフラグに，単純に設定します．
接尾子の`.s'と`.S'だけがアセンブリコードを含んでいるファイル
だとautomakeで認識されます．
Automakeには，Fortran 77に対する完全なサポートが含まれています．
Fortran 77コードを含むパッケージでは，`configure.ac'で出力変数
`F77'を定義する必要があります．こうするための最も簡単な方法は
AC_PROG_F77マクロを使用することです(see section `Particular Program Checks' in The Autoconf Manual)．
See section 8.11.4 Fortran 77とAutoconf.
Fortran 77ソースファイルが見つかるとき，追加変数がいくつか定義されます．
F77
FFLAGS
AM_FFLAGS
FFLAGSです．
RFLAGS
AM_RFLAGS
RFLAGSです．
F77COMPILE
FLINK
さらにAutomakeは，コンパイルするためにFortran 77とRatforソースファイル のプリプロセス処理を行なうことが可能です(6)． Automake には，Fortran 77と他の言葉が混合しているプログラムと共有ライ ブラリを作成するためのサポートも含まれています(see section 8.11.3 CとC++と，Fortran 77の混在)．
これらの問題は次のセクションで述べます．
| 8.11.1 Fortran 77のプリプロセス | ||
| 8.11.2 Fortran 77ファイルのコンパイル | ||
| 8.11.3 CとC++と，Fortran 77の混在 | ||
| 8.11.4 Fortran 77とAutoconf |
`N.f'は自動的に`N.F'あるいは`N.r'から作成されます．この ルールは，プリプロセス可能なFortran 77やRatforソースファイルを，厳密な Fortran 77ソースファイルに変換するためだけにプリプロセッサを走らせます． 使用される正確なコマンドは以下のようになります．
$(F77) -F $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)
$(F77) -F $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)
`N.o'は，Fortran 77を実行することによって`N.f'，`N.F'や `N.r'から自動的に作成されます．使用される正確なコマンドは以下のよ うになります．
$(F77) -c $(AM_FFLAGS) $(FFLAGS)
$(F77) -c $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)
$(F77) -c $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)
Automakeは現在，Fortran 77とCそして/またはC++が混在しているプログラム と共有ライブラリを作成するため，限定されたサポートを提供してい ます．しかし，(現在は)Automakeによって処理されませんが，他のパッ ケージ(7)で処理される，Fortran 77と他の言 葉との混在に関連して，多くの問題が発生しています．
Automakeは二つの方法でそれを助けることが可能です．
これらの追加されたFortran 77リンカフラグは，Autoconf(Autoconfバージョ
ン2.13やそれ以降)の新しいバージョンで供給された，
AC_F77_LIBRARY_LDFLAGSというAutoconfマクロでの出力変数
FLIBSで提供されます．See section `Fortran 77 Compiler Characteristics' in The Autoconf.
(_PROGRAMSや_LTLIBRARIESプライマリで記述されているような)
プログラムや共有ライブラリが，Fortran 77と，Cそして/またはC++が混合す
るソースコードを含んでいることをAutomakeが検出した場合，
AC_F77_LIBRARY_LDFLAGSマクロを`configure.ac'で呼び出し，
$(FLIBS)が，適切な(プログラムに対する)_LDADDや，(共有ラ
イブラリに対する)_LIBADD変数のいずれかで書かれていることを要求
します．$(FLIBS)が適切な_LDADDや_LIBADD変数に書か
れていることを確かめるのは，`Makefile.am'を書いている人の責任です．
例えば，以下の`Makefile.am'を考えます．
bin_PROGRAMS = foo foo_SOURCES = main.cc foo.f foo_LDADD = libfoo.la $(FLIBS) pkglib_LTLIBRARIES = libfoo.la libfoo_la_SOURCES = bar.f baz.c zardoz.cc libfoo_la_LIBADD = $(FLIBS) |
この状況では，Automakeは，AC_F77_LIBRARY_LDFLAGSが
`configure.ac'で記述されることを強く要求します．また，
$(FLIBS)がfoo_LDADDとlibfoo_la_LIBADDで記述されて
いない場合も，Automakeは警告を出します．
| 8.11.3.1 リンカの選択方法 |
Automakeによって特定のリンカが選択される条件を以下の図で明示します．
例えば，Fortran 77，C，そしてC++ソースコードがプログラムにコンパイルさ
れる場合，C++リンカが使用されます．この場合，CあるいはFortran 77リンカ
が，C++リンカに含まれていない特別なライブラリを必要とした場合，
`Makefile.am'を書いているユーザが，_LDADDや_LIBADD
変数を手作業で付け加える必要があります．
\ Linker
source \
code \ C C++ Fortran
----------------- +---------+---------+---------+
| | | |
C | x | | |
| | | |
+---------+---------+---------+
| | | |
C++ | | x | |
| | | |
+---------+---------+---------+
| | | |
Fortran | | | x |
| | | |
+---------+---------+---------+
| | | |
C + C++ | | x | |
| | | |
+---------+---------+---------+
| | | |
C + Fortran | | | x |
| | | |
+---------+---------+---------+
| | | |
C++ + Fortran | | x | |
| | | |
+---------+---------+---------+
| | | |
C + C++ + Fortran | | x | |
| | | |
+---------+---------+---------+
|
Fortran 77に対する現在のAutomakeサポートは，Fortran 77に対するサポート が含まれている最近のバージョンのAutoconfも必要になります．Fortran 77の 完全なサポートがAutoconf2.13で加えられたので，それかそれ以降のバージョ ンのAutoconfを使用したいと思うことでしょう．
Automakeには，GNU Compiler CollectionのJavaフロントエンドである
gcjを使用してコンパイルされるJavaに対するサポートも含まれていま
す．
Javaコードを含んでいるパッケージのコンパイルには，`configure.ac'
で出力変数`GCJ'を定義する必要があります．変数`GCJFLAGS'も，
(`configure.ac'や`Makefile.am'で)なんとかして定義する必要が
あります．こうするための最も簡単な方法は，AM_PROG_GCJマクロを使
用することです．
デフォルトで，Javaソースファイルを含んでいるプログラムは，gcjで
リンクされます．
通常どおり，`AM_GCJFLAGS'の内容は，gcjが呼び出されるコンパ
イルごとに渡されます(コンパイル前でのその役割を果たすもの ---
`.class'ファイルを作成するためにそれを呼び出すとき，
`AM_JAVACFLAGS'が代わりに使用されます)．`Makefile.am'から
gcjにオプションを渡す必要がある場合，この変数とユーザ変数でない
`GCJFLAGS'を使用すべきでしょう．
gcjは，`.java'，`.class'，`.zip'，または
`.jar'ファイルをコンパイルするために使用することが可能です．
リンク時に，gcjはメインクラスが`--main='オプションを使用し
て指定されていることを要求します．こうするための最も簡単な方法は，プロ
グラムで_LDFLAGS変数を使用することです．
Automakeには現在，C，C++(see section 8.9 C++のサポート)，Fortran 77(see section 8.11 Fortran 77のサポート)，そしてJava(see section 8.12 Javaのサポート)のみの 完全なサポートが含まれています．他の言葉に対しては，基本的なサポートと ユーザの需要に基づいて改善されるサポートしかありません．
独自の言語を加えるため幾分制限されているサポートは，サフィックスルール の処理によって利用可能になっています．18.2 新しいファイル拡張子の取り扱いを参照してください．
GNU standardsはANSI Cの使用を許可していますが，これはもっと古いコンパ イラ(特にSunOS C コンパイラ)へのパッケージの移植性を制限することになる はずです．
実際にコンパイルされる前にde-ANSI-fyngしたそれぞれのファイルによっ て，Automakeではそのようなマシン上でのこの問題を解決することが可能にな ります．
`Makefile.am'の変数AUTOMAKE_OPTIONS(see section 17. Automakeの動作の変更)がオプ
ションansi2knrを含んでいる場合，de-ANSI-ficationを処理するため
のコードが生成された`Makefile.in'に挿入されます．
これによって，ディレクトリ内のそれぞれのCソースファイルをANSI Cとして
扱います．ANSI Cコンパイラが利用可能な場合，それが使用されます．ANSI C
コンパイラが利用可能でない場合，ansi2knrプログラムがソースファ
イルをK&R Cに変換するために使用され，そしてコンパイルされます．
ansi2knrプログラムは単純です．それはソースコードが特定の方法で
書式化されると仮定します．詳細はansi2knrのmanページを参照してく
ださい．
de-ANSI-ficationに対するサポートでは，ソースファイル`ansi2knr.c'
と`ansi2knr.1'がANSI Cソースと同じパッケージにある必要があります．
これらのファイルはAutomakeと一緒に配布されます．また，パッケージ
`configure.ac'では，AM_C_PROTOTYPESマクロを呼び出す必要も
あります(see section 5.6 Automakeが提供するAutoconfマクロ)．
Automakeは，現在のパッケージの他のディレクトリでansi2knrサポー
トファイルを見つけることもできます．これは，ansi2knrオプション
へ適切なディレクトリへの相対的なパスを前置することで行なわれます．例え
ば，パッケージの`src'と`lib'サブディレクトリにANSI Cコードが
あると仮定します．ファイル`ansi2knr.c'と`ansi2knr.1'は
`lib'にあります．この場合，`src/Makefile.am'は以下のように書
くことが可能でしょう．
AUTOMAKE_OPTIONS = ../lib/ansi2knr |
ディレクトリの接頭辞が与えられてない場合，ファイルはカレントディレクト リにあると仮定されます．
自動的なde-ANSI-ficationは，パッケージが異なるホストアーキテクチャに対
するビルドでは動作しないことに注意してください．それは，ビルドマシンに
対してansi2knrをビルドする方法が，現在のautomakeには無いためで
す．
ソースのde-ANSI-ficationでLIBOBJSを使用すると，`configure'
のLIBOBJSのbasenameに$Uを手動で追加する必要がありました．
現在ではそうではありません．バージョン2.54から，Autoconfは
LIBOBJSとLTLIBOBJSを注意深く書き換えています．
(see section `AC_LIBOBJ vs. LIBOBJS' in The Autoconf Manual)
プロジェクトで，インクルードファイルの依存性が変化するときはいつでも， 絶えず`Makefile.in'を更新することは開発者として辛いことも多いもの です．Automakeは自動的に依存性の変更を追跡する方法を提供しています．
Automakeは常に，システムヘッダを含むコンパイルに対する完全な依存性を使
用します．Automakeのモデルは，依存性の評価がビルドの副作用になるという
ものです．つまり依存性は，depcompと呼ばれる特別なラッパプログラ
ムを通じてすべてのコンパイルを実行することで求められます．
depcompは，多くの異なるCとC++コンパイラで，それが要求する書式で
依存情報の生成させるように上手に扱う方法を理解してます．automake
-aで，depcompをソースツリーにインストールします．
depcompがコンパイラの正しい呼び出し方が分からない場合，依存性の
追跡はビルドで利用不可能になるだけです．
これまでのバージョンのAutomakeの経験上(8)，configureが非常に多くなるにつれ，管理者のシステムでのみ生 成される依存性が信頼できないことを我々に教えてくれました．そのため， Automake はビルド時に依存性を追跡することをその代わりに実装しました．
自動的な依存性の追跡で，変数AUTOMAKE_OPTIONSに
no-dependenciesを書くことや，AM_INIT_AUTOMAKEへの引数と
してno-dependenciesを渡すこと(これは推奨されるべき方法です)が無
くなるはずです．そうしない場合は，automakeを-iオプション
を用いて呼び出してください．依存性の追跡はデフォルトで利用可能です．
パッケージを構築している人々も，--disable-dependency-trackingを
用いてconfigureすることで，依存性の追跡を利用不可能にすることを選択す
ることが可能です．
プラットフォームによっては，Windowsのように実行形式が`.exe'のよう な拡張子を持つことを期待するものもあります．これらのプラットフォームで は，(GCCを含む)コンパイラは，`foo'を生成するように依頼されるとき， 自動的に`foo.exe'を生成します．
Automakeは，これに対するほとんどの変換でサポートを提供します．残念なが らほとんどとは完全ではないということです．英語の辞書では反対に なりますが，パッケージをこれらのプラットフォームでサポートされるように したい場合，Automakeを補助する必要があります．
気付いていると思われることの一つは，Automakeが以下のような内容に内部で 書き直すことです．
bin_PROGRAMS = liver |
これを以下のようにします．
bin_PROGRAMS = liver$(EXEEXT) |
Automakeが生成するターゲットは，`$(EXEEXT)'拡張子が与えられたもの
になります．EXEEXT
しかし，Automakeがこの書き換えをconfigureの置換式に適用すること
は不可能です．そのような置換式を使用しているプログラムを条件付きでビル
ドしている場合，出力変数を作成しているときに`configure.ac'に
`$(EXEEXT)'を注意して加えるようにする必要があるということを，これ
は意味します．
Autoconf 2.13とそれ以前のものを用いると，このサポートを得るために，明
示的にAC_EXEEXTを使用する必要があります．Autoconf 2.50を用いる
と，コンパイラをconfigureする際に(すなわちAC_PROG_CCを通じて)，
AC_EXEEXTが自動的に実行されます．
それらのプログラムに対し，管理者が明示的にリンクルールを書きたいときも あります．実行形式の拡張子サポートを用いなければ，これは簡単です -- ターゲットをプログラム名にしたルールを書くだけです．しかし，実行形式の 拡張子のサポートが利用可能な時は，代わりに`$(EXEEXT)'接尾辞を加え る必要があります．
残念ながら，Autoconf 2.50の変更のため，常にこの拡張子を加える必要があ
ることを，これは意味しています．しかし，パッケージが実行形式の拡張子を
持つプラットフォームで実行されるはずがないことを知っている管理者にとっ
て，このことは問題になります．これらの管理者に対しては，
no-exeextオプション(see section 17. Automakeの動作の変更)でこの機能が利用不可能にな
ります．これは，かなり醜い方法で動作します．no-exeextが見つかっ
た場合，`Makefile.am'のfooという名前のターゲットに対するルー
ルが存在すると，automekeが生成するfoo$(EXEEXT)に対するルールで
上書きされます．no-exeextオプションが用いなければ，これでエラー
が生じます．
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |