7. プログラムとライブラリのビルド

Automakeの機能の大半は，プログラムとライブラリのビルドを容易にすること に費やされています．

7.1 プログラムのビルド

プログラムをビルドするために，その一部となるソースとリンクされるライブ ラリをAutomakeに伝える必要があります．

このセクションは，ソースやプログラムの条件付きコンパイルもカバーしてい ます．これらのコメントのほとんどは，ライブラリ(see 節 7.2 ライブラリのビルド)と libtoolライブラリ(see 節 7.3 共有ライブラリのビルド)に適用されます．

7.1.1 プログラムソースの定義		Defining program sources
7.1.2 プログラムのリンク		Linking with libraries or extra objects
7.1.3 ソースの条件コンパイル		Handling conditional sources
7.1.4 プログラムの条件付コンパイル		Building program conditionally

7.1.1 プログラムソースの定義

(ライブラリやスクリプトと比べて)プログラムにビルドされるソースを含んで いるディレクトリには，`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 節 7.5 デフォルトの_SOURCES)．

複数のプログラムを一つのディレクトリでビルドすることが可能です．複数の プログラムで単一のソースファイルを共有することが可能で，それぞれの `_SOURCES'定義でリストアップする必要があります．

`_SOURCES'定義にリストアップされているヘッダファイルは配布物に含 まれますが，それ以外のものは無視されます．明らかではないときは， `configure'で生成されるヘッダファイルを`_SOURCES'変数に含め るべきではありません．このファイルは配布すべきではありません． Lex(`.l')とYacc(`.y')のファイルもリストアップすることが可能 です．7.8 YaccとLexのサポートを参照して下さい．

7.1.2 プログラムのリンク

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'に無効な値を与えないことが知られているの で残されています．

7.1.3 ソースの条件コンパイル

configureの置換式(例えば，AC_SUBSTで定義されるFOO を用いた`@FOO@'や`$(FOO)')を`_SOURCES' 変数に書き込む ことはできません．この理由を説明するのは少し難しいのですが，単純に言っ て動作しないということで十分でしょう．これを試みた場合，Automakeはエラー を発します．

幸い，同じ結果を達成するために二つの別の方法があります．一つは， configureの置換式を_LDADD変数で使用する方法で，もう一つ は，Automakeの条件式を使用する方法です．

7.1.3.1 _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-generic.o'で置換され，ビルドしリンクするために hello_DEPENDENCIESとhello_LDADDに追加されます．

7.1.3.2 Automakeの条件式を使用した条件コンパイル

条件によってソースファイルをコンパイルするためのより簡単な方法としては， 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 節 19. 条件文)．

Automakeは，ソースファイルの完全なリストを構成するためにそれぞれの変数 の内容を調査するので，このような条件を使用するときは，`EXTRA_'変 数を使用する必要はありません．

プログラムで多くのファイルを使用している場合，おそらく条件付の +=のほうが望ましいでしょう．

bin_PROGRAMS = hello
hello_SOURCES = hello-common.c
if LINUX
hello_SOURCES += hello-linux.c
else
hello_SOURCES += hello-generic.c
endif

7.1.4 プログラムの条件付コンパイル

ビルドされるプログラムをconfigure時に決定することが役に立つときもあり ます．例えば，GNU cpioは特別な状況のときだけmtと rmtをビルドします．プログラムの条件付きコンパイルを達成するとい う意味は，ソースファイルのコンパイルを条件的に行なうことと一緒です．置 換式を用いたり条件式を用いたりします．

7.1.4.1 configureの置換式を使用した条件的プログラム

この場合は，ビルドされる可能性のあるすべてのプログラムをAutomakeに知ら せる必要がありますが，同時に，configureで指定されるプログラムを 使用するように`Makefile.in'を生成させる必要もあります．このことは， それぞれの`_PROGRAMS'定義にconfigureでの置換式の値を持たせ ることで行なわれますが，一方では，EXTRA_PROGRAMSでオプションと してビルドされるプログラムがすべてリストアップされています．

bin_PROGRAMS = cpio pax $(MT)
libexec_PROGRAMS = $(RMT)
EXTRA_PROGRAMS = mt rmt

7.17 実行形式の拡張子のサポートの説明として，Automakeは$(EXEEXT)をそれぞれのバイナ リに付加して，bin_PROGRAMS，libexec_PROGRAMS，そして EXTRA_PROGRAMSを書き換えます．configureの置換式で，実行 時に値を明示的に書き換えることは明らかに不可能なので， AC_SUBST([MT], ['mt${EXEEXT}'])の様に$(EXEEXT)を付加す ることには気を付けて下さい．

7.1.4.2 Automakeの条件式を使用した条件的プログラム

ビルドするプログラムを選択するため，Automakeの条件式を (see 節 19. 条件文)使用することも可能です．この状況では， $(EXEEXT)やEXTRA_PROGRAMSに気を付ける必要はありません．

bin_PROGRAMS = cpio pax
if WANT_MT
  bin_PROGRAMS += mt
endif
if WANT_RMT
  libexec_PROGRAMS = rmt
endif

7.2 ライブラリのビルド

ライブラリをビルドすることは，プログラムをビルドすることによく似ていま す．この場合は，プライマリの名前は`LIBRARIES'です．ライブラリは libdirやpkglibdirにインストールされます．

libtoolと`LTLIBRARIES'プライマリを使用して共有ライブラリをビルド する方法についての詳細は，See 節 7.3 共有ライブラリのビルド.

それぞれの`_LIBRARIES'変数は，ビルドされるライブラリのリストです． 例えば，`libcpio.a'という名前のライブラリを作成し，それをインストー ルしないため，以下のように書きます．

noinst_LIBRARIES = libcpio.a

ライブラリに組み込まれるソースは，プログラムのときのように， `_SOURCES'変数によって正しく決定されます．ライブラリ名は標準的に されるので(see 節 2.4 派生される変数と命名法)，`liblob.a'に対応する `_SOURCES'変数は`liblob.a_SOURCES'ではなく `liblob_a_SOURCES'になることに注意してください．

追加のオブジェクトは，`library_LIBADD'変数を使用してライブ ラリに追加することが可能です．これはconfigureで決定されるオブジェ クトに対して使用されるべきです．再びcpioからの引用です．

libcpio_a_LIBADD = $(LIBOBJS) $(ALLOCA)

さらに，configure時まで存在しない追加のオブジェクトに対するソースは， BUILT_SOURCES変数に追加する必要があります(see 節 8.4 ビルドされているソース)．

スタティックライブラリをビルドすることは，すべてのオブジェクトファイル をコンパイルし，その後で$(AR) $(ARFLAGS)にライブラリ名とオブジェ クトのリストを続けたものを呼び出し，そして最後にライブラリで $(RANLIB)を呼び出すことで達成されます．RANLIBを定義する ため，AC_PROG_RANLIBを`configure.ac'から呼び出すべきです (そうしなければ，Automakeは文句を言います)．ARとARFLAGS のデフォルトはそれぞれarとcruです．これらの二つの変数を `Makefile.am'で設定する，`configure.ac'でAC_SUBSTする， または，ライブラリごとにmaude_AR変数で定義することで優先させる ことが可能です(see 節 7.4 プログラムとライブラリの変数)．

7.3 共有ライブラリのビルド

移植性の高い共有ライブラリをビルドすることは比較的複雑な問題です．この ために，GNU Libtoolは(see 節 `Introduction' in

7.3.1 Libtoolの概念		Introducing Libtool
7.3.2 Libtoolライブラリのビルド		Declaring Libtool Libraries
7.3.3 Libtoolライブラリのビルドの条件分岐		Building Libtool Libraries Conditionally
7.3.4 条件的ソースを用いたLibtoolライブラリ		Choosing Library Sources Conditionally
7.3.5 Libtoolのコンビニエンスライブラリ		Building Convenience Libtool Libraries
7.3.6 Libtoolのモジュール		Building Libtool Modules
7.3.7 _LIBADDと_LDFLAGS		Using _LIBADD and _LDFLAGS
7.3.8 LTLIBOBJS		Using $(LTLIBOBJ)
7.3.9 Libtoolの使用に関連する一般的な問題		Common Issues Related to Libtool's Use

7.3.1 Libtoolの概念

Libtoolは，共有ライブラリとスタティックライブラリを統一した概念で， libtoolライブラリ(libtool libraries)と呼ばれるものに抽出します． Libtoolライブラリは`.la'接尾子を使用しているファイルで，スタティッ クライブラリ，共有ライブラリ，または両方を表します．正確な性質は `./configure'が実行されるまで決定することは不可能です．すべてのプ ラットフォームですべての種類のライブラリをサポートしているわけではあり ませんし，ユーザは明示的にビルドするライブラリを選択するすることも可能 です．(しかし，パッケージの管理者はデフォルトを調整することが可能です． See 節 `The AC_PROG_LIBTOOL macro' in

共有ライブラリとスタティックライブラリのオブジェクトファイルは，別々に コンパイルする必要があるので，libtoolはコンパイル時にも使用されます． libtoolでビルドされたライブラリは，libtoolオブジェクト(libtool objects)と呼ばれます．これらは，`.lo'接尾子を利用しているファイ ルです．libtoolライブラリはこれらのlibtoolオブジェクトからビルドされま す．

`.la'や`.lo'ファイルの構造や，libtoolがそれらを構築する方法 を仮定すべきではありません．これはlibtoolが考えることで，最後のものは libtoolの中身を勉強したい人が欲しいものです．しかし，これらのファイル は，libtoolライブラリをビルドするとき，`Makefile'ルール内のターゲッ トと依存性として使用されるので，その存在が重要になります．例えば，条件 的にソースファイルをビルドする依存性を表現するとき，これらを参照する必 要がある状況があります(see 節 7.3.4 条件的ソースを用いたLibtoolライブラリ)．

動的にロードされるモジュールとなっているプラグインシステムを書こうと考 えている人々は，`libltdl'の中を見るべきです．libtoolによるライブ ラリのdlopenです(see 節 `Using libltdl' in

我々がAutomakeを用いてlibtoolを使用する方法の詳細を議論する前に， libtoolマニュアルにあるlibtoolとともにAutomakeを使用する方法に付いて書 かれているセクションにも注意しておくべきです(see 節 `Using Automake with Libtool' in

7.3.2 Libtoolライブラリのビルド

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を使用することが可能です．

7.3.3 Libtoolライブラリのビルドの条件分岐

プログラムの条件式のように(see 節 7.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 ...

7.3.4 条件的ソースを用いたLibtoolライブラリ

ライブラリでのソースの条件的コンパイルは，プログラムでのソースの条件的 コンパイルと同じ方法で達成することが可能です(see 節 7.1.3 ソースの条件コンパイル)．違いは，_LDADDの代わりに_LIBADDを使用し， libtoolオブジェクト(`.lo'ファイル)について記述することだけです．

そのため，7.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

7.3.5 Libtoolのコンビニエンスライブラリ

インストールされない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 \
  ...

7.3.6 Libtoolのモジュール

これらは，dlopenされることを意味するlibtoolライブラリです．それらは， リンク時に-moduleをlibtoolに渡すことで示されます．

pkglib_LTLIBRARIES = mymodule.la
mymodule_la_SOURCES = doit.c
mymodule_la_LDFLAGS = -module

通常，Automakeは共有ライブラリの名前が`lib'で始まることを要求しま す．しかし，動的にロードされるモジュールをビルドしている場合，"標準的 でない" 名前を使用したいかもしれません．

`mymodule_la_SOURCES'が指定されていない場合，そのデフォルトは単一 ファイルの`mymodule.c' (see 節 7.5 デフォルトの_SOURCES)です．

7.3.7 _LIBADDと_LDFLAGS

前のセクションで見てきたように，`library_LIBADD'変数は， libraryに追加する補助的なlibtoolオブジェクト(`.lo'ファイル) やlibtoolライブラリ(`.la')をリストアップするために使用すべきです．

`library_LDFLAGS'変数には，`-version-info'， `-static'，などの追加のlibtoolフラグをリストアップします． See 節 `Using libltdl' in

7.3.8 LTLIBOBJS

通常のライブラリは$(LIBOBJS)に含まれますが，libtoolライブラリは $(LTLIBOBJS)を使用する必要があります．libtoolが処理するオブジェ クトファイルは，最終的に`.o'にする必要がないため，このように要求 されます．

現在，LIBOBJSからLTLIBOBJSを求めることはAutoconfが自動的 に実行します(see 節 `AC_LIBOBJ vs. LIBOBJS' in

7.3.9 Libtoolの使用に関連する一般的な問題

7.3.9.1 required file `./ltmain.sh' not found

libtoolは，パッケージにlibtoolのサポートを行なうファイルをインストール するlibtoolizeと呼ばれるツールから生じます．このコマンドを実 行すると，`ltmain.sh'がインストールされます．aclocalと automakeの前にそれを実行すべきです．

古いパッケージから新しいautotoolにアップグレードすると，古いバージョン のAutomakeはlibtoolizeと呼ばれるものを使用していたのでこの問 題に直面します．このため，古いビルドスクリプトではlibtoolize を呼び出しません．

Automake1.6から，libtoolizeの実行がAutomakeの仕事ではないと 決定しました．その代わり，その機能はautoreconfコマンドに渡さ れました(see 節 `Using autoreconf' in

7.3.9.2 libtoolで作成されたりされなかったりするオブジェクト

同じソースファイルが，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)'にコンパイルし， 問題を解決することになります．

7.4 プログラムとライブラリの変数

それぞれのプログラムに関連して，プログラムのビルドの方法を修正するため に使用可能な変数の集合があります．それぞれのライブラリに対しても，それ に似たような変数のリストがあります．プログラム(やライブラリ)の標準的な 名前が，これらの変数の命名に対してベースとして使用されます．

以下のリストでは，名前"maude"をプログラムやライブラリを示すものとし て使用しています．`Makefile.am'で，これをプログラムの標準的な名前 に置換してください．このリストは，"maude"をプログラムを示すものとし ていますが，一般的に同じルールを，スタティックライブラリやダイナミック ライブラリに適用します．以下の文章では，プログラムとライブラリで異なる 状況をコメントしています．

`maude_SOURCES'

存在する場合，この変数は，プログラムをビルドするためにコンパイルされる， すべてのソースファイルをリストアップします．プログラムをビルドしている とき，Automakeはそれぞれのソースファイルを単一の`.o'ファイル(や libtoolを使用しているときは`.lo')にコンパイルさせます．通常これら のオブジェクトファイルはソースファイルの後に命名されますが，他の要因で 変更することが可能です．`_SOURCES'変数のファイルに認識できない拡 張子がある場合，Automakeは二つのうちの一つを実行します．認識できない拡 張子を持つファイルを`.o'に変換するためのサフィックスルールが存在 する場合，automakeはこのファイルを，その他の(言語の)ソースファイルとし て扱います(see 節 7.14 他の言語のサポート)．それ以外では，ファイ ルがヘッダファイルと考えて無視されます．

接頭辞の`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 節 16. Automakeの動作の変更)．

`EXTRA_maude_SOURCES'

Automakeは，コンパイルしたいファイルのリストを静的に知っている 必要があります．一つには，該当する`Makefile.in'が要求する言語のサ ポートの種類をAutomakeが知るための唯一の方法だということがあげられます． (4)例えばこれには，`@my_sources@'のようなconfigureの置換 式を`_SOURCES'に書き込むことができないという意味があります．ソー スファイルの条件コンパイルを行ない，例えば`_LDADD'(以下を参照して ください)のオブジェクト名を適切に置換するために`configure'を使用 したい場合，対応するソースファイルを`EXTRA_'にリストアップした方 が良いでしょう．

この変数は，例えば`nodist_EXTRA_maude_SOURCES'のように， `dist_'と`nodist_'もサポートします．

`maude_AR'

スタティックライブラリは，デフォルトで，$(AR) $(ARFLAGS)にライ ブラリ名とライブラリに書き込むオブジェクトを続けて呼び出すことで作成さ れます．`_AR'変数でこれに優先することが可能です．これは，通常C++ で使用されます．C++コンパイラには，ライブラリに組み込むすべてのテンプ レートを生成するために，特殊な呼び出しが必要なものもあります．例えば， SGI C++コンパイラは，この変数を以下のように設定します．

libmaude_a_AR = $(CXX) -ar -o

`maude_LIBADD'

`_LIBADD'変数を使用することで，追加のオブジェクトをライブラ リに加えることが可能です．例えばこれは，configureで決定される オブジェクトに対して使用すべきです(see 節 7.2 ライブラリのビルド)．

`maude_LDADD'

`_LDADD'変数に追加のオブジェクトをリストアップすることで， プログラムに加えることが可能です．例えばこれは， configureで決定されるオブジェクトに対して使用すべきです (see 節 7.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)

`maude_LDFLAGS'

これは，プログラムや共有ライブラリのリンク段階に特別なフラグを渡すため に使用する変数です．

`maude_DEPENDENCIES'

実際には，プログラムの一部にはならない他のターゲットに依存するプログラ ムがあることが，役に立つ場合もあります．これは，`_DEPENDENCIES'変 数を使用することで可能になります．それぞれのプログラムは，その変数の内 容に依存しますが，それ以上に解釈されません．

`_DEPENDENCIES'が提供されていない場合，それはAutomakeが考慮します． 自動的に割り当てられる値は`_LDADD'や`_LIBADD'の内容で，ほと んどのconfigure置換式，`-l'，`-L'，`-dlopen'， `-dlpreopen'，そして`-dlpreopen'オプションは削除されています． 残っているconfigureの置換式は，`$(LIBOBJS)'と`$(ALLOCA)'です． これらは，生成される`_DEPENDENCIES'に対して無効な値を生成しないこ とが分かっているので残されます．

`maude_LINK'

プログラムごとを基本として，(デフォルトの)リンカに優先することが可能で す．デフォルトで，プログラムで使用されている言語によってリンカは選択さ れます．例えば，C++のソースコードを含むプログラムでは，C++コンパイラが リンクに使用されます．`_LINK'変数は，すべての`.o'ファイル名 を引数として渡すことが可能なコマンドの名前を含んでいる必要があります． 基礎となるプログラム名は，`_LINK'に渡されないことに注意し てください．通常は`$@'を使用します．

maude_LINK = $(CCLD) -magic -o $@

`maude_CCASFLAGS'

`maude_CFLAGS'

`maude_CPPFLAGS'

`maude_CXXFLAGS'

`maude_FFLAGS'

`maude_GCJFLAGS'

`maude_LFLAGS'

`maude_OBJCFLAGS'

`maude_RFLAGS'

`maude_YFLAGS'

Automakeでは，プログラムごと(またはライブラリごと)を基本として，コンパ イルフラグを設定することが可能です．単一のソースファイルを複数のプログ ラムに含めることが可能で，それぞれのプログラムに対して異なるフラグでコ ンパイルされる可能性もあります．これは，あらゆる言語に対し，直接 Automakeがサポートすることで動作します．これらのターゲットごとの コンパイルフラグ(per-target compilation flags)は，`_CCASFLAGS'， `_CFLAGS'，`_CPPFLAGS'，`_CXXFLAGS'，`_FFLAGS'， `_GCJFLAGS'，`_LFLAGS'，`_OBJCFLAGS'，`_RFLAGS'， そして`_YFLAGS'です．

ターゲットごとのコンパイルフラグを使用するとき，Automakeは，中間的なオ ブジェクトファイルに対して異なる名前を選択します．通常， `sample.c'のようなファイルは，コンパイルされて`sample.o'が生 成されます．しかし，プログラムの`_CFLAGS'変数を設定した場合，オブ ジェクトファイルは，例えば`maude-sample.o'のように命名されます． (26.5 なぜオブジェクトファイルの名前を変更することがあるのですか？も参照して下さい．)

ターゲットごとにフラグを用いてコンパイルする際は，通常の`AM_'形式 のフラグ変数は自動的にコンパイルに組み込まれません(しかし，ユー ザ形式の変数は組み込まれます)．そのため，例えば， `AM_CFLAGS'の変数も使用して`maude'のコンパイルを行なうと仮定 すると，以下のように書く必要があります．

maude_CFLAGS = ... your flags ... $(AM_CFLAGS)

`maude_SHORTNAME'

利用可能なファイル名が非常に短いプラットフォームもあります．これらのシ ステムと，ターゲットごとのコンパイルフラグを同時にサポートするために， Automakeでは，中間的なオブジェクトファイルの命名方法に影響する"短い名 前"を設定することが可能です．例えば，以下の例のようにします．

bin_PROGRAMS = maude maude_CPPFLAGS = -DSOMEFLAG maude_SHORTNAME = m maude_SOURCES = sample.c ...

オブジェクトファイルは`maude-sample.o'ではなく`m-sample.o'と 命名されます．

この機能は，実行上滅多に必要になりませんし，要求されていることが分かる まで使用を避けることを推奨します．

7.5 デフォルトの_SOURCES

_SOURCES変数は，プログラム(see 節 7.1 プログラムのビルド)，ライブラリ (see 節 7.2 ライブラリのビルド)，そしてLibtoolライブラリ(see 節 7.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

7.6 LIBOBJSとALLOCAに対する特別扱い

Automakeは，$(LIBOBJS)と$(ALLOCA)を使用していることを明 示的に認識し，そしてこの情報を使用し，配布物に適切なソースファイルを自 動的に含めるため(see 節 13. 配布物に含まれるもの)，`configure.ac'から派生される LIBOBJSファイルのリストに追加します．これらのソースファイルは， 依存性追跡でも自動的に処理されます．See 節 7.16 自動的な依存性追跡.

$(LIBOBJS)と$(ALLOCA)は，あらゆる`_LDADD'や `_LIBADD'で特別に認識されます．

7.7 プログラムビルド時に使用される変数

Automakeがコンパイルに使用する`Makefile'変数を知ることが役に立ち つこともあります．例えば，特別な状況では，自分でコンパイルをする必要が あるかもしれません．

Autoconfから継承される変数もあります．これらはCC，CFLAGS， CPPFLAGS，DEFS，LDFLAGS，そしてLIBSです．

Automake自身が定義する追加の変数もあります．

AM_CPPFLAGS

この変数の内容は，Cプリプロセッサを呼び出すコンパイルで毎回渡されます． それはプリプロセッサへの引数リストです．例えば，`-I'と`-D'オ プションは，ここにリストアップすべきです．

Automakeは，すでに`-I'オプションを自動的に提供しています．特に， `-I$(srcdir)'，`-I.'，そして(AC_CONFIG_HEADERSや AM_CONFIG_HEADERを使用している場合は)`config.h'があるディ レクトリを示す`-I'を生成します．`nostdinc'オプションを使用す ることで，デフォルトの`-I'オプションを利用不可能にすることが可能 です．

実行形式ごと(またはライブラリごと)に_CPPFLAGS変数が定義されてい る場合，それを優先するので，AM_CPPFLAGSは無視されます．

INCLUDES

これは，`AM_CPPFLAGS'と同じ仕事をします(または，ターゲットごとに `_CPPFLAGS'が使用されている場合と同じです)．それは同じ機能に対す る古い名前です．この変数の使用には反対します．我々は，代わりに `AM_CPPFLAGS'とターゲットごとの`_CPPFLAGS'の使用を勧めます．

AM_CFLAGS

これは，`Makefile.am'の著者が，追加のCコンパイラフラグを渡すため に使用することが可能な変数です．その完全な説明はどこかにあるでしょう． 状況によっては，実行形式ごと(またはライブラリごと)の_CFLAGSが優 先され，これは使用されません．

COMPILE

これはCソースファイルをコンパイルするために実際に使用されるコマンドで す．完全なコマンドラインを構成するために，ファイル名が追加されます．

AM_LDFLAGS

これは，`Makefile.am'の著者が，追加のリンカフラグを渡すために使用 することが可能な変数です．状況によっては，実行形式ごと(またはライブラ リごと)の_LDFLAGSが優先され，これは使用されません．

LINK

これはCプログラムをリンクするために実際に使用されるコマンドです．それ にはすでに，`-o $@'と通常参照される変数(例えば，CFLAGS)が 含まれています．それは，リンクされるオブジェクトファイルとライブラリの 名前を"引数"として受けとります．

7.8 YaccとLexのサポート

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 節 `Particular Program Checks' in

yaccが呼び出された時，`YFLAGS'と`AM_YFLAGS'フラグが渡 されます．前者はユーザ変数で，後者は`Makefile.am'の著者のためのも のです．

`AM_YFLAGS'は通常，-dオプションをyaccに渡すとき使用 されます．Automakeはこれが意味するところを知っていて，yacc -dで ビルドされるヘッダファイルの更新と配布のルールを，自動的に調整します． しかし，Automakeが分からないものは，このヘッダが使用される場所です．ヘッ ダが最初に使用される前にヘッダをビルドしておくことはあなたの責任です． 通常これは，ヘッダが他のファイルからインクルードされているとき，依存性 の追跡が動作するために必要となります．一般的な解決策は，ヘッダファイル を以下のようにBUILT_SOURCES (see 節 8.4 ビルドされているソース)にリストアップする ことです．

BUILT_SOURCES = parser.h
AM_YFLAGS = -d
bin_PROGRAMS = foo
foo_SOURCES = ... parser.y ...

同様に，lexソースファイルがある場合，`configure.ac'で変数 `LEX'を定義する必要があります．こうするために`AC_PROG_LEX'を 使用することが可能ですが(see 節 `Particular Program Checks' in

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 節 `Finding `configure' Input' in

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に対す る動作を定義します．パーサジェネレータが，ここでカバーされていないシン ボルを使用していることが分かった場合，リストに加えることができるように， 新しい名前を報告してください．

7.9 C++のサポート

Automakeには，C++に対する完全なサポートが含まれています．

C++コードを含んでいるすべてのパッケージでは，`configure.ac'で出力 変数`CXX'を定義する必要があります．これを行う最も単純な方法は， AC_PROG_CXXマクロを使用することです(see 節 `Particular Program Checks' in

C++ソースファイルがあるとき，少しだけ追加変数が定義されます．

CXX

C++コンパイラの名前です．

CXXFLAGS

C++コンパイラに渡すすべてのフラグです．

AM_CXXFLAGS

管理者のためのCXXFLAGSです．

CXXCOMPILE

C++ソースファイルを実際にコンパイルするために使用されるコマンドです． 完全なコマンドラインを構成するためにファイル名が追加されます．

CXXLINK

実際にC++プログラムをリンクするコマンドです．

7.10 アセンブラのサポート

Automakeは，アセンブラコードに対するサポートも含んでいます．

変数CCASには，アセンブラコードをビルドするために使用するコンパ イラ名が保持されています．このコンパイラは，Cコンパイラにちょっと似て いる動作をする必要があります．特に，それは`-c'と`-o'を受け入 れる必要があります．CCASFLAGSの値はコンパイラに渡されます．

`configure.ac'でCCASとCCASFLAGSを設定する必要があり ます．autoconfマクロのAM_PROG_ASでこれを行ないます．前もって設 定されていない場合は，CCASをCコンパイラに， CCASFLAGSをC コンパイラフラグに，単純に設定します．

接尾子の`.s'と`.S'だけがアセンブリコードを含んでいるファイル だとautomakeで認識されます．

7.11 Fortran 77のサポート

Automakeには，Fortran 77に対する完全なサポートが含まれています．

Fortran 77コードを含むパッケージでは，`configure.ac'で出力変数 `F77'を定義する必要があります．こうするための最も簡単な方法は AC_PROG_F77マクロを使用することです(see 節 `Particular Program Checks' in

Fortran 77ソースファイルが見つかるとき，追加変数がいくつか定義されます．

F77

Fortran 77コンパイラの名前です．

FFLAGS

Fortran 77コンパイラに渡す，すべてのフラグです．

AM_FFLAGS

管理者のためのFFLAGSです．

RFLAGS

Ratforコンパイラに渡す，すべてのフラグです．

AM_RFLAGS

管理者のためのRFLAGSです．

F77COMPILE

実際にFortran 77ソースファイルをコンパイルするコマンドです．完全なコマ ンドラインを構成するために，ファイル名が追加されます．

FLINK

実際に純粋なFortran 77プログラムあるいは共有ライブラリをリンクするコマ ンドです．

さらにAutomakeは，コンパイルするためにFortran 77とRatforソースファイル のプリプロセス処理を行なうことが可能です(5)． Automake には，Fortran 77と他の言葉が混合しているプログラムと共有ライ ブラリを作成するためのサポートも含まれています(see 節 7.11.3 CとC++と，Fortran 77の混在)．

これらの問題は次のセクションで述べます．

7.11.1 Fortran 77のプリプロセス		Preprocessing Fortran 77 sources
7.11.2 Fortran 77ファイルのコンパイル		Compiling Fortran 77 sources
7.11.3 CとC++と，Fortran 77の混在		Mixing Fortran 77 With C and C++

7.11.1 Fortran 77のプリプロセス

`N.f'は自動的に`N.F'あるいは`N.r'から作成されます．この ルールは，プリプロセス可能なFortran 77やRatforソースファイルを，厳密な Fortran 77ソースファイルに変換するためだけにプリプロセッサを走らせます． 使用される正確なコマンドは以下のようになります．

`.F'

$(F77) -F $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)

`.r'

$(F77) -F $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)

7.11.2 Fortran 77ファイルのコンパイル

`N.o'は，Fortran 77を実行することによって`N.f'，`N.F'， または`N.r'から自動的に作成されます．使用される正確なコマンドは以 下のようになります．

`.f'

$(F77) -c $(AM_FFLAGS) $(FFLAGS)

`.F'

$(F77) -c $(DEFS) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)

`.r'

$(F77) -c $(AM_FFLAGS) $(FFLAGS) $(AM_RFLAGS) $(RFLAGS)

7.11.3 CとC++と，Fortran 77の混在

Automakeは現在，Fortran 77とCそして/またはC++が混在しているプログラム と共有ライブラリを作成するため，限定されたサポートを提供してい ます．しかし，(現在は)Automakeによって処理されませんが，他のパッ ケージ(6)で処理される，Fortran 77と他の言 葉との混在に関連して，多くの問題が発生しています．

Automakeは二つの方法でそれを助けることが可能です．

1. ソースコードの組み合わせに依存したリンカの自動的な選択．

2. 適切なFortran 77のイントリンシックとランタイムライブラリにリンクするた めに，自動的に選択されたリンカに渡す適切なリンカフラグ(例えば`-L' と`-l')の自動的な選択．

   これらの追加されたFortran 77リンカフラグは，Autoconf(Autoconfバージョ ン2.13やそれ以降)の新しいバージョンで供給された， AC_F77_LIBRARY_LDFLAGSというAutoconfマクロでの出力変数 FLIBSで提供されます．See 節 `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は警告を出します．

7.11.3.1 リンカの選択方法

Automatic linker selection

7.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    |         |
                        |         |         |         |
                        +---------+---------+---------+

7.12 Fortran 9xのサポート

Automakeには，Fortran 9xに対する完全なサポートが含まれています．

Fortran 9xコードを含むパッケージでは，`configure.ac'で出力変数 `FC'を定義する必要があります．こうするための最も簡単な方法は AC_PROG_FCマクロを使用することです(see 節 `Particular Program Checks' in

Fortran 9xソースファイルが見つかるとき，追加変数がいくつか定義されます．

FC

Fortran 9xコンパイラの名前です．

FCFLAGS

Fortran 9xコンパイラに渡す，すべてのフラグです．

AM_FCFLAGS

管理者のためのFCLAGSです．

FCCOMPILE

実際にFortran 9xソースファイルをコンパイルするコマンドです．完全なコマ ンドラインを構成するために，ファイル名が追加されます．

FCLINK

実際に純粋なFortran 9xプログラムあるいは共有ライブラリをリンクするコマ ンドです．

7.12.1 Fortran 9xファイルのコンパイル

Compiling Fortran 9x sources

7.12.1 Fortran 9xファイルのコンパイル

`N.o'は，Fortran 9xを実行することによって`N.f90'または `N.F95'から自動的に作成されます．使用される正確なコマンドは以下の ようになります．

`.f9x'

$(FC) -c $(AM_FCFLAGS) $(FCFLAGS)

7.13 Javaのサポート

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変数を使用することです．

7.14 他の言語のサポート

Automakeには現在，C，C++(see 節 7.9 C++のサポート)，Fortran 77(see 節 7.11 Fortran 77のサポート)，Fortran 9x (see 節 7.12 Fortran 9xのサポート)，そしてJava(see 節 7.13 Javaのサポート)のみの完全なサポートが含ま れています．他の言葉に対しては，基本的なサポートとユーザの需要に基づい て改善されるサポートしかありません．

独自の言語を加えるため幾分制限されているサポートは，サフィックスルール の処理によって利用可能になっています．17.2 新しいファイル拡張子の取り扱いを参照してください．

7.15 自動的なde-ANSI-fication

GNU standardsはANSI Cの使用を許可していますが，これはもっと古いコンパ イラ(特にSunOS C コンパイラ)へのパッケージの移植性を制限することになる はずです．

実際にコンパイルされる前にde-ANSI-fyngしたそれぞれのファイルによっ て，Automakeではそのようなマシン上でのこの問題を解決することが可能にな ります．

`Makefile.am'の変数AUTOMAKE_OPTIONS(see 節 16. 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 節 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 節 `AC_LIBOBJ vs. LIBOBJS' in

7.16 自動的な依存性追跡

プロジェクトで，インクルードファイルの依存性が変化するときはいつでも， 絶えず`Makefile.in'を更新することは開発者として辛いことも多いもの です．Automakeは自動的に依存性の変更を追跡する方法を提供しています．

Automakeは常に，システムヘッダを含むコンパイルに対する完全な依存性を使 用します．Automakeのモデルは，依存性の評価がビルドの副作用になるという ものです．つまり依存性は，depcompと呼ばれる特別なラッパプログラ ムを通じてすべてのコンパイルを実行することで求められます． depcompは，多くの異なるCとC++コンパイラで，それが要求する書式で 依存情報の生成させるように上手に扱う方法を理解してます．automake -aで，depcompをソースツリーにインストールします． depcompがコンパイラの正しい呼び出し方が分からない場合，依存性の 追跡はビルドで利用不可能になるだけです．

これまでのバージョンのAutomakeの経験上(7)，configureが非常に多くなるにつれ，管理者のシステムでのみ生 成される依存性が信頼できないことを我々に教えてくれました．そのため， Automake はビルド時に依存性を追跡することをその代わりに実装しました．

自動的な依存性の追跡で，変数AUTOMAKE_OPTIONSに no-dependenciesを書くことや，AM_INIT_AUTOMAKEへの引数と してno-dependenciesを渡すこと(これは推奨されるべき方法です)が無 くなるはずです．そうしない場合は，automakeを-iオプション を用いて呼び出してください．依存性の追跡はデフォルトで利用可能です．

パッケージを構築している人々も，--disable-dependency-trackingを 用いてconfigureすることで，依存性の追跡を利用不可能にすることを選択す ることが可能です．

7.17 実行形式の拡張子のサポート

プラットフォームによっては，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 節 16. Automakeの動作の変更)でこの機能が利用不可能にな ります．これは，かなり醜い方法で動作します．no-exeextが見つかっ た場合，`Makefile.am'のfooという名前のターゲットに対するルー ルが存在すると，automekeが生成するfoo$(EXEEXT)に対するルールで 上書きされます．no-exeextオプションが用いなければ，これでエラー が生じます．