Automakeの機能の大半は,プログラムとライブラリのビルドを容易にすることに 費やされています.
プログラムをビルドするために,その一部となるソースとリンクされるライブラ リをAutomakeに伝える必要があります.
このセクションは,ソースやプログラムの条件付コンパイルもカバーしています. これらのコメントのほとんどは,ライブラリ(see section ライブラリのビルド)とLibtoolライ ブラリ(see section 共有ライブラリのビルド)に適用されます.
(ライブラリやスクリプトと比較して)プログラムにビルドされるソースを含んで
いるディレクトリには,`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'になります.すなわちデフォルトとは,ベースとなる名前がプ ログラム自身の名前になっている,単一のCファイルをコンパイルするというこ とです.(これは危険なデフォルトですが,我々は歴史的な理由で行き詰まって います.)
複数のプログラムを一つのディレクトリでビルドすることが可能です.複数のプ ログラムで単一のソースファイルを共有することが可能で,それぞれの `_SOURCES'定義でリストアップする必要があります.
`_SOURCES'定義にリストアップされているヘッダファイルは配布物に含ま れますが,それ以外のものは無視されます.明らかではないときは, `configure'で生成されるヘッダファイルを`_SOURCES'変数に含める べきではありません.このファイルは配布すべきではありません. Lex(`.l')とYacc(`.y')のファイルもリストアップすることが可能で す.section 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
の置換式(例えば,`@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_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.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
は特別な状況のときだけmt
とrmt
を
ビルドします.
この場合は,ビルドされる可能性のあるすべてのプログラムをAutomakeに知らせ
る必要がありますが,同時に,configure
で指定されるプログラムを使用
するように`Makefile.in'を生成させる必要もあります.このことは,それ
ぞれの`_PROGRAMS'定義にconfigure
での置換式の値を持たせること
で行なわれますが,一方では,EXTRA_PROGRAMS
でオプションとしてビル
ドされるプログラムがすべてリストアップされています.
もちろん,ビルドするプログラムを定義するために,Automakeの条件式を使用す ることも可能です.
ライブラリをビルドすることは,プログラムをビルドすることによく似ています.
この場合は,プライマリの名前は`LIBRARIES'です.ライブラリは
libdir
やpkglibdir
にインストールされます.
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"をプログラムを示すものとしていま すが,一般的に同じ規則を,スタティックライブラリやダイナミックライブラリ に適用します.以下の文章では,プログラムとライブラリで異なる状況をコメン トしています.
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 Automakeの動作の変更).
$(AR) cru
にライブラリ名と
ライブラリに書き込むオブジェクトを続けて呼び出すことで作成されます.
`_AR'変数でこれに優先することが可能です.これは,通常C++で使用され
ます.C++コンパイラには,ライブラリに組み込むすべてのテンプレートを
instantiateするために,特殊な呼び出しが必要なものもあります.例えば,SGI
C++コンパイラは,この変数を以下のように設定します.
libmaude_a_AR = $(CXX) -ar -o
configure
で決定されるオブジェクトに対し
て使用すべきです.
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_LINK = $(CCLD) -magic -o $@
maude_CFLAGS = ... your flags ... $(AM_CFLAGS)
Automakeは,@LIBOBJS@
と@ALLOCA@
を使用していることを明
示的に認識し,そしてこの情報を使用し,配布物に適切なソースファイルを自動
的に含めるため(see section 配布物に含まれるもの),`configure.in'から派生される
LIBOBJS
ファイルのリストに追加します.これらのソースファイルは,依
存性追跡でも自動的に処理されます.See section 自動的な依存性追跡.
@LIBOBJS@
と@ALLOCA@
は,あらゆる`_LDADD'や
`_LIBADD'で特別に認識されます.
Automakeがコンパイルに使用する`Makefile'変数を知ることが役に立ちつ こともあります.例えば,特別な状況では,自分でコンパイルをする必要がある かもしれません.
Autoconfから継承される変数もあります.これらはCC
,CFLAGS
,
CPPFLAGS
,DEFS
,LDFLAGS
,そしてLIBS
です.
Automake自身が定義する追加の変数もあります.
AM_CPPFLAGS
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.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_'接頭辞は好みのものに置き換えて下さい.
これらは,bison
,byacc
,そして伝統的なyacc
に対する
動作を定義します.パーサジェネレータが,ここでカバーされていないシンボル
を使用していることが分かった場合,リストに加えることができるように,新し
い名前を報告してください.
Automakeには,C++に対する完全なサポートが含まれています.
C++コードを含んでいるすべてのパッケージでは,`configure.in'で出力変
数`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.in'でCCAS
とCCASFLAGS
を設定する必要がありま
す.autoconfマクロのAM_PROG_AS
でこれを行ないます.前もって設定さ
れていない場合は,CCAS
をCコンパイラに, CCASFLAGS
をCコンパ
イラフラグに,単純に設定します.
接尾子の`.s'と`.S'だけがアセンブリコードを含んでいるファイルだ
とautomake
で認識されます.
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
FFLAGS
AM_FFLAGS
FFLAGS
です.
RFLAGS
AM_RFLAGS
RFLAGS
です.
F77COMPILE
FLINK
さらにAutomakeは,コンパイルするためにFortran 77とRatforソースファイルの プリプロセス処理を行なうことが可能です(8).Automakeには, Fortran 77と他の言葉が混合しているプログラムと共有ライブラリを作成するた めのサポートも含まれています(see section CとC++と,Fortran 77の混在).
これらの問題は次のセクションで述べます.
`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によって処理されませんが,他のパッケージ (9)で処理される,Fortran 77と他の言葉との混在に関連して,多くの問題が発生しています.
Automakeは二つの方法でそれを助けることが可能です.
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_LDADD
とlibfoo_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に対する現在のAutomakeサポートは,Fortran 77に対するサポートが 含まれている最近のバージョンのAutoconfも必要になります.Fortran 77の完全 なサポートがAutoconf2.13で加えられたので,それかそれ以降のバージョンの Autoconfを使用したいと思うことでしょう.
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 新しいファイル拡張子の取り扱いを参照してください.
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_OPTIONS
に
no-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.