Go to the first, previous, next, last section, table of contents.


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

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

プログラムのビルド

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

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

プログラムソースの定義

(ライブラリやスクリプトと比較して)プログラムにビルドされるソースを含んで いるディレクトリには,`PROGRAMS'プライマリが使用されます.プログラ ムを,bindirsbindirlibexecdirpkglibdir にインストールしたり,または全くインストールしない(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'になります.すなわちデフォルトとは,ベースとなる名前がプ ログラム自身の名前になっている,単一のCファイルをコンパイルするというこ とです.(これは危険なデフォルトですが,我々は歴史的な理由で行き詰まって います.)

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

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

プログラムのリンク

configureで見つからないライブラリに対してリンクする必要がある場合, そうするためにLDADDを使用することが可能です.この変数は,リンクす る追加のオブジェクトやライブラリを指定するために使用されます.それは,特 定のリンカフラグを指定するには不適切で,この目的ではAM_LDFLAGSを 使用すべきです.

複数のプログラムが一つのディレクトリで構築されていても,リンク時に同じ条 件を共有しないときもあります.この場合は,グローバルなLDADDに優先 させるため,`prog_LDADD'変数(ここでのprogはプログラムの 名前で,それは`_PROGRAMS'変数にあって,通常は小文字で書かれています) を使用することが可能です.この変数が所定のプログラムのために存在する場合, そのプログラムはLDADDを使用してリンクされません.

例えば,GNU cpioでは,paxcpio,そしてmtは, `libcpio.a'ライブラリにリンクされます.しかし,rmtは同じディ レクトリでビルドされますが,そのようなリンクは必要ありません.また, mtrmtは特定のアーキテクチャでのみビルドされます.以下は, 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の置換式(例えば,`@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.in'@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_DEPENDENCIEShello_LDADDに追加されます.

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.in'AM_CONDITIONALを使用して LINUX条件式を設定する必要があります(see section 条件文).

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

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

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

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

ビルドされるプログラムをconfigure時に決定することが役に立つときもありま す.例えば,GNU cpioは特別な状況のときだけmtrmtを ビルドします.

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

もちろん,ビルドするプログラムを定義するために,Automakeの条件式を使用す ることも可能です.

ライブラリのビルド

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

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

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

noinst_LIBRARIES = libcpio.a

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

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

libcpio_a_LIBADD = @LIBOBJS@ @ALLOCA@

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

共有ライブラリのビルド

共有ライブラリをビルドすることは比較的複雑な問題です.このために,GNU Libtoolは(see section `Introduction' in The Libtool Manual)プラッ トホームに依存しない方法で共有ライブラリをビルドする補助を行なうために作 成されました.

Automakeは,`LTLIBRARIES'プライマリで宣言されたライブラリをビルドす るためにLibtoolを使用します.それぞれの`_LTLIBRARIES'変数はビルドす る共有ライブラリのリストです.例えば,`libgettext.a'という名前のラ イブラリとそれに対応する共有ライブラリを作成し,`libdir'にインストー ルするために,以下のように書いてください.

lib_LTLIBRARIES = libgettext.la

共有ライブラリが正しく動作するようにインストールする必要があるの で,check_LTLIBRARIESが使用不可能だということに注意してください. しかし,noinst_LTLIBRARIESは使用可能です.この機能はlibtoolの "convinience library"で使用されます.

それぞれのライブラリに対して,`library_LIBADD'変数は,共有ラ イブラリに加える追加のlibtoolオブジェクト(`.lo'ファイル)の名前を含 んでいます.`library_LDFLAGS'変数は,`-version-info'`-static'といった,付加的なlibtoolフラグも含んでいます.

普通のライブラリが@LIBOBJS@を使用するところで,libtoolライブラ リは@LTLIBOBJS@を使用する必要があります.libtoolが処理するオブ ジェクトファイルは必ずしも`.o'で終わらないので,これが必要になりま す.libtoolマニュアルには,このトピックに関する詳細が書かれています.

いくつかのディレクトリにインストールされるライブラリに対して,Automakeは 自動的に適切な`-rpath'オプションを供給します.しかし,configure時 (とEXTRA_LTLIBRARIESに書いたとき)に決定されるライブラリに対して, Automakeは最終的なインストールディレクトリを知りません.このようなライブ ラリに対しては,適切な`_LDFLAGX'変数に`-rpath' オプションを手 書きで加える必要があります.

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

詳細はSee section `The Libtool Manual' in The Libtool Manual.

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

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

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

`maude_SOURCES'
存在する場合,この変数は,プログラムをビルドするためにコンパイルされる, すべてのソースファイルをリストアップします.プログラムをビルドしていると き,Automakeはそれぞれのソースファイルを単一の`.o'ファイル(や libtoolを使用しているときは`.lo')にコンパイルさせます.通常これらの オブジェクトファイルはソースファイルの後に命名されますが,他の要因で変更 することが可能です.`_SOURCES'変数のファイルに認識できない拡張子が ある場合,Automakeは二つのうちの一つを実行します.認識できない拡張子を持 つファイルを`.o'に変換するためのサフィックス規則が存在する場合, automakeはこのファイルを,その他の(言語の)ソースファイルとして扱います (see section 他の言語のサポート).それ以外では,ファイルがヘッダファ イルと考えて無視されます. 接頭辞の`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-objectsAUTOMAKE_OPTIONSで指定することが可能で す(see section Automakeの動作の変更).
`EXTRA_maude_SOURCES'
Automakeは,コンパイルしたいファイルのリストを静的に知っている必 要があります.一つには,該当する`Makefile.in'が要求する言語のサポー トの種類をAutomakeが知るための唯一の方法だということがあげられます. (7) 例えばこれには,`@my_sources@'のようなconfigure の置換式を`_SOURCES'に書き込むことができないという意味があります. ソースファイルの条件コンパイルを行ない,例えば`_LDADD'(以下を参照し てください)のオブジェクト名を適切に置換するために`configure'を使用 したい場合,対応するソースファイルを`EXTRA_'にリストアップした方が 良いでしょう. この変数は,例えば`nodist_EXTRA_maude_SOURCES'のように, `dist_'`nodist_'もサポートします.
`maude_AR'
スタティックライブラリは,デフォルトで,$(AR) cruにライブラリ名と ライブラリに書き込むオブジェクトを続けて呼び出すことで作成されます. `_AR'変数でこれに優先することが可能です.これは,通常C++で使用され ます.C++コンパイラには,ライブラリに組み込むすべてのテンプレートを instantiateするために,特殊な呼び出しが必要なものもあります.例えば,SGI C++コンパイラは,この変数を以下のように設定します.
libmaude_a_AR = $(CXX) -ar -o
`maude_LIBADD'
`_LIBADD'変数を使用することで,追加のオブジェクトをライブラリに加え ることが可能です.これは,configureで決定されるオブジェクトに対し て使用すべきです.
`maude_LDADD'
`_LDADD'変数に追加のオブジェクトをリストアップすることで,共有ライ ブラリやプログラムに加えることが可能です.これは,configureで決定 されるオブジェクトに対して使用すべきです. (`-l'`-L'`-dlopen',そして`-dlpreopen'以外の)プ ログラム特有のリンカフラグを渡すために`_LDADD'`_LIBADD'を使 用することは不適切です.この目的に対しては,`_LDFLAGS'変数を使用し てください. 例えば,`configure.in'AC_PATH_XTRAを使用している場合,Xの ライブラリに対してプログラムをリンクするため,以下のようにすることが可能 でしょう.
maude_LDADD = $(X_PRE_LIBS) $(X_LIBS) $(X_EXTRA_LIBS)
`maude_LDFLAGS'
これは,プログラムや共有ライブラリのリンク段階に特別なフラグを渡すために 使用する変数です.
`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がサポー トすることで動作します.フラグは, `_CCASFLAGS'`_CFLAGS'`_CPPFLAGS'`_CXXFLAGS'`_FFLAGS'`_GCJFLAGS'`_LFLAGS'`_OBJCFLAGS'`_RFLAGS',そして `_YFLAGS'です. プログラムごとにコンパイルフラグを使用するとき,Automakeは,中間的なオブ ジェクトファイルに対して異なる名前を選択します.通常,`sample.c'の ようなファイルは,コンパイルされて`sample.o'が生成されます.しかし, プログラムの`_CFLAGS'変数を設定した場合,オブジェクトファイルは,例 えば`maude-sample.o'のように命名されます. プログラムごとにフラグを用いてコンパイルする際は,通常の`AM_'形式の フラグ変数は自動的にコンパイルに組み込まれません(しかし,ユーザ形 式の変数は組み込まれます).そのため,例えば,`AM_CFLAGS'の変 数も使用して`maude'のコンパイルを行なうと仮定すると,以下のように書 く必要があります.
maude_CFLAGS = ... your flags ... $(AM_CFLAGS)
`maude_DEPENDENCIES'
実際には,プログラムの一部にはならない他のターゲットに依存するプログラム があることが,役に立つ場合もあります.これは,`_DEPENDENCIES'変数を 使用することで可能になります.それぞれのプログラムは,その変数の内容に依 存しますが,それ以上の解釈はなされません. `_DEPENDENCIES'が提供されていない場合,それはAutomakeが考慮します. 自動的に割り当てられる値は`_LDADD'`_LIBADD'の内容で,ほとん どのconfigure置換式,`-l'`-L'`-dlopen',そして `-dlpreopen'は削除されています.残っているconfigureの置換式は, `@LIBOBJS@'`@ALLOCA@'です.これらは,生成される `_DEPENDENCIES'に対して無効な値を生成しないことが分かっているので残 されます.
`maude_SHORTNAME'
利用可能なファイル名が非常に短いプラットフォームもあります.これらのシス テムと,プログラムごとのコンパイルフラグを同時にサポートするために, Automakeでは,中間的なオブジェクトファイルの命名方法に影響する"短い名前" を設定することが可能です.例えば,`maude_SHORTNAME'`m'に設定 する場合,上記のプログラムごとのコンパイルフラグの例では,オブジェクトファ イルは`maude-sample.o'ではなく`m-sample.o'と命名されます.この 機能は,実行上滅多に必要になりませんし,要求されていることが分かるまで使 用を避けることを推奨します.

LIBOBJSとALLOCAに対する特別扱い

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

@LIBOBJS@@ALLOCA@は,あらゆる`_LDADD'`_LIBADD'で特別に認識されます.

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

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

Autoconfから継承される変数もあります.これらはCCCFLAGSCPPFLAGSDEFSLDFLAGS,そしてLIBSです.

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

AM_CPPFLAGS
この変数の内容は,Cプリプロセッサを呼び出すコンパイルで毎回渡されます. それはプリプロセッサへの引数リストです.例えば,`-I'`-D'オプ ションは,ここにリストアップすべきです. Automakeは,すでに`-I'オプションを自動的に提供しています.特に, `-I$(srcdir)'`-I.',そして(AC_CONFIG_HEADERSAM_CONFIG_HEADERを使用している場合は)`config.h'があるディレ クトリを示す`-I'を生成します.`nostdinc'オプションを使用するこ とで,デフォルトの`-I'オプションを利用不可能にすることが可能です. 実行形式ごと(またはライブラリごと)に_CPPFLAGS変数が定義されている 場合,それを優先するので,AM_CPPFLAGSは無視されます,
INCLUDES
これは,`AM_CPPFLAGS'と同じ仕事をします.それは同じ機能に対する古い 名前です.この変数の使用には反対です.代わりに`AM_CPPFLAGS'の使用を 勧めます.
AM_CFLAGS
これは,`Makefile.am'の著者が,追加のCコンパイラフラグを渡すために 使用することが可能な変数です.その完全な説明はどこかにあるでしょう.状況 によっては,実行形式ごと(またはライブラリごと)の_CFLAGSが優先され, これは使用されません.
COMPILE
これはCソースファイルをコンパイルするために実際に使用されるコマンドです. 完全なコマンドラインを構成するために,ファイル名が追加されます.
AM_LDFLAGS
これは,`Makefile.am'の著者が,追加のリンカフラグを渡すために使用す ることが可能な変数です.状況によっては,実行形式ごと(またはライブラリご と)の_LDFLAGSが優先され,これは使用されません.
LINK
これはCプログラムをリンクするために実際に使用されるコマンドです.それに はすでに,`-o $@'と通常参照される変数(例えば,CFLAGS)が含ま れています.それは,リンクされるオブジェクトファイルとライブラリの名前を "引数"として受けとります.

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)によって生成さる中間的なファイルは,作成 されるすべての配布物に含められます.そのためユーザがyacclexを持っている必要がありません.

yaccソースファイルが見つかった場合,`configure.in'で変数 `YACC'を定義する必要があります.これは,マクロ`AC_PROG_YACC'を 呼び出すことで最も容易に行なえます(see section `Particular Program Checks' in The Autoconf Manual).

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

同様に,lexソースファイルがある場合,`configure.in'で変数 `LEX'を定義する必要があります.こうするために`AC_PROG_LEX'を使 用することが可能ですが(see section `Particular Program Checks' in The Autoconf Manual),AM_PROG_LEXマクロ (see section 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.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_'接頭辞は好みのものに置き換えて下さい. これらは,bisonbyacc,そして伝統的なyaccに対する 動作を定義します.パーサジェネレータが,ここでカバーされていないシンボル を使用していることが分かった場合,リストに加えることができるように,新し い名前を報告してください.

C++のサポート

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

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

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

CXX
C++コンパイラの名前です.
CXXFLAGS
C++コンパイラに渡すすべてのフラグです.
AM_CXXFLAGS
管理者のためのCXXFLAGSです.
CXXCOMPILE
C++ソースファイルを実際にコンパイルするために使用されるコマンドです.完 全なコマンドラインを構成するためにファイル名が追加されます.
CXXLINK
実際にC++プログラムをリンクするコマンドです.

アセンブラのサポート

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

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

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

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

Fortran 77のサポート

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

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

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ソースファイルの プリプロセス処理を行なうことが可能です(8).Automakeには, Fortran 77と他の言葉が混合しているプログラムと共有ライブラリを作成するた めのサポートも含まれています(see section CとC++と,Fortran 77の混在).

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

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)

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)

CとC++と,Fortran 77の混在

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

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

  1. ソースコードの組み合わせに依存したリンカの自動的な選択.
  2. 適切なFortran 77のイントリンシックとランタイムライブラリにリンクするため に,自動的に選択されたリンカに渡す適切なリンカフラグ(例えば`-L'`-l')の自動的な選択. これらの追加された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.in'で呼び出し, $(FLIBS)または@FLIBS@のどちらかで,適切な(プログラムに対 する)_LDADDや,(共有ライブラリに対する)_LIBADD変数が書かれ ていることを要求します.$(FLIBS)@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.in'で記述されることを強く要求します.また, @FLIBS@foo_LDADDlibfoo_la_LIBADDで記述されて いない場合も,Automakeは警告を出します.

リンカの選択方法

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とAutoconf

Fortran 77に対する現在のAutomakeサポートは,Fortran 77に対するサポートが 含まれている最近のバージョンのAutoconfも必要になります.Fortran 77の完全 なサポートがAutoconf2.13で加えられたので,それかそれ以降のバージョンの Autoconfを使用したいと思うことでしょう.

Javaのサポート

Automakeには,GNU Compiler CollectionのJavaフロントエンドである gcjを使用してコンパイルされるJavaに対するサポートも含まれています.

Javaコードを含んでいるパッケージのコンパイルには,`configure.in'で 出力変数`GCJ'の定義する必要があります.変数`GCJFLAGS'も, (`configure.in'`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 C++のサポート),Fortran 77(see section Fortran 77のサポート),そしてJava(see section Javaのサポート)のみの完全なサポートが含ま れています.他の言葉に対しては,基本的なサポートとユーザの需要に基づいて 改善されるサポートしかありません.

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

自動的なde-ANSI-fication

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

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

`Makefile.am'の変数AUTOMAKE_OPTIONS(see section 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.in'では,AM_C_PROTOTYPESマクロを呼び出す必要もあ ります(see section Automakeが提供するAutoconfマクロ).

Automakeは,現在のパッケージの他のディレクトリでansi2knrサポート ファイルを見つけることもできます.これは,ansi2knrオプションへ適 切なディレクトリへの相対的なパスを前置することで行なわれます.例えば,パッ ケージの`src'`lib'サブディレクトリにANSI Cコードがあると仮定 します.ファイル`ansi2knr.c'`ansi2knr.1'`lib'にありま す.この場合,`src/Makefile.am'は以下のように書くことが可能でしょう.

AUTOMAKE_OPTIONS = ../lib/ansi2knr

ディレクトリの接頭辞が与えられてない場合,ファイルはカレントディレクトリ にあると仮定されます.

de-ANSI-ficationを必要とするLIBOBJSに書かれているファイルは,自動 的に処理されません.その理由は,configure`regex.o'のような オブジェクト名を生成しますが,makeは(de-ANSI-fyingの時), `regex_.o'を探すためです.最終的に,この問題はautoconfによっ て修正されますが,しばらくはAC_OUTPUTを呼び出す直前に, `configure.in'に以下のコードを書き込む必要があります.

# This is necessary so that .o files in LIBOBJS are also built via
# the ANSI2KNR-filtering rules.
LIBOBJS=`echo $LIBOBJS|sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'`

自動的なde-ANSI-ficationは,パッケージが異なるホストアーキテクチャに対す るビルドでは動作しないことに注意してください.それは,ビルドマシンに対し てansi2knrをビルドする方法が,現在のautomakeには無いためです.

自動的な依存性追跡

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

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

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

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

パッケージを構築している人々も,--disable-dependency-trackingを用 いてコンフィグレーションすることで,依存性の追跡を利用不可能にすることを 選択することが可能です.

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

プラットフォームによっては,Windowsのように実行形式が`.exe'のような 拡張子を持つことを期待するものもあります.これらのプラットフォームでは, (GCCを含む)コンパイラは,`foo'を生成するように依頼されるとき,自動 的に`foo.exe'を生成します.

Automakeは,これに対するほとんどの変換でサポートを提供します.残念ながら ほとんどとは完全では無いということです.英語の辞書では反対になり ますが,パッケージをこれらのプラットフォームでサポートされるようにしたい 場合,Automakeを補助する必要があります.

気付いていると思われることの一つは,Automakeが以下のような内容に内部で書 き直すことです.

bin_PROGRAMS = liver

これを以下のようにします.

bin_PROGRAMS = liver$(EXEEXT)

Automakeが生成するターゲットは,`$(EXEEXT)'拡張子が与えられたものに なります.EXEEXT

しかし,Automakeがこの書き換えをconfigureの置換式に適用することは 不可能です.そのような置換式を使用しているプログラムを条件付きでビルドし ている場合,出力変数を作成しているときに`configure.in'`$(EXEEXT)'を注意して加えるようにする必要があるということを,これは 意味します.

Autoconf 2.13とそれ以前のものを用いると,このサポートを得るために,明示 的にAC_EXEEXTを使用する必要があります.Autoconf 2.50を用いると, コンパイラをコンフィグレーションする際に(すなわちAC_PROG_CCを通じ て),AC_EXEEXTが自動的に実行されます.

それらのプログラムに対し,管理者が明示的にリンク規則を書きたいときもあり ます.実行形式の拡張子サポートを用いなければ,これは簡単です -- ターゲッ トをプログラムと同じ名前にするだけです.しかし,実行形式の拡張子のサポー トが利用可能な時は,代わりに`$(EXEEXT)'接尾辞を加える必要があります.

残念ながら,Autoconf 2.50の変更のため,常にこの拡張子を加える必要がある ことを,これは意味しています.しかし,パッケージが実行形式の拡張子を持つ プラットフォームで実行されるはずがないことを知っている管理者にとって,こ のことは問題になります.これらの管理者に対しては,no-exeextオプショ ン(see section Automakeの動作の変更)でこの機能が利用不可能になります.これは,かなり醜い 方法で動作します.no-exeextが見つかった場合,`Makefile.am'fooという名前のターゲットが存在すると,automekeが生成する foo$(EXEEXT)形式のターゲットで上書きされます.no-exeextオ プションが用いなければ,これでエラーが生じます.


Go to the first, previous, next, last section, table of contents.