[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

7. プログラムやライブラリの構築

Automakeの機能の大部分はプログラムやライブラリを構築するのを容易にす ることを目的にしている。


7.1 プログラムの構築

(ライブラリに対比して)プログラムに組み込まれるソースを含むディレクトリで は、`PROGRAMS'主要変数が使われる。プログラムはbindirsbindirlibexecdirpkglibdirにインストールされる か、全くインストールされない(`noinst')。

例えば、

 
bin_PROGRAMS = hello

この単純な場合には、結果として生じる`Makefile.in'はhelloと名 付けられたプログラムを生成するコードを含むだろう。変数 hello_SOURCESはどのソース・ファイルが実行形式に組み込まれるかを指 定するのに使われる。

 
hello_SOURCES = hello.c version.c getopt.c getopt1.c getopt.h system.h 

これにより記述された`.c'ファイルがそれぞれ対応する`.o'にコンパ イルされる。そして全て`hello'を生成するためにリンクされる。

もし`prog_SOURCES'が必要とされるが、指定されないなら、単一のファイ ル`prog.c'がデフォルトになる。

複数のプログラムが単一ディレクトリで構築され得る。複数のプログラムは単一 のソース・ファイルを共有できる。ソース・ファイルはそれぞれの `_SOURCES'定義で列挙されねばならない。

`_SOURCES'定義で列挙されるヘッダ・ファイルは配布物に含まれるが、さ もなければ無視されるだろう。それが明らかでない場合には、`_SOURCES' 変数に`configure'で生成されるヘッダ・ファイルを含むべきではない。こ のファイルは配布されるべきではない。Lex(`.l')やYacc(`.y')ファ イルもまた列挙されて良い。YaccとLexのサポートを見よ。

Automakeはプログラムにもしかすると入るかもしれないソース・ファイルを全て 知る必要がある、たとえあらゆる環境で全てのファイルが構築されるわけではな いとしても。条件付きでのみ構築されるファイルは適切な`EXTRA_'変数に 列挙されるべきだ。例えば、もし`hello-linux.c'がhelloに条件付 きで含まれるなら、`Makefile.am'はこれを含む。

 
EXTRA_hello_SOURCES = hello-linux.c

同様に、ときどき設定時に構築される予定のプログラムを決定することが役に立 つ。例えば、GNU cpioは特別な環境でのみmtrmtを構築 する。

この場合、Automakeに、構築されるかもしれないが、同時に、生成され た`Makefile.in'にconfigureによって指定されたプログラムを使う ようにさせるかもしれない全てのプログラムを知らせなければならない。これは configureに`_PROGRAMS'定義の値をそれぞれ置き換えさせることに よって行われるが、付加的に構築されるプログラムをEXTRA_PROGRAMSに 列挙する。

もしconfigureで見付けられないライブラリに対してリンクする必要があ るなら、そうするためにLDADDを使うことができる。この変数は実際には リンカのコマンドラインにいかなるオプションでも追加するのに使用できる。

ときどき、複数のプログラムは一つのディレクトリで構築されるがリンク時に必 要なものが同じではない。この場合、`prog_LDADD'変数(prog はある`_PROGRAMS'変数で現れるようなプログラムの名前であり、普通小文 字で書かれる)を広域的なLDADDを上書きするために使用できる。もしこ の変数が任意のプログラムに対して存在したら、このプログラムは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'を除き)プログラム特異的なリンカ・ フラグを渡すには不適切である。だから、この目的には`prog_LDFLAGS'を 使用する。

プログラムを実際にはこのプログラムの一部ではない他のターゲットに依存させ るのもときには有用である。これは`prog_DEPENDENCIES'変数を使って行わ れ得る。各プログラムはそのような変数の中身に依存するが、さらに解釈が行わ れることはない。

もし`prog_DEPENDENCIES'が与えられないなら、Automakeによって計算され る。自動的に指定される値は、`prog_LDADD'の中身からほとんどの設定に よる置換、`-l'や`-L'オプションが除かれたものである。残される設 定による置換は`@LIBOBJS@'と`@ALLOCA@'だけである。これらは `prog_DEPENDENCIES'に対し無効な値を生成させないことが分かっているの で残される。


7.2 ライブラリの構築

ライブラリの構築はプログラムの構築に非常に似ている。この場合には、主要変 数の名前は`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@

7.3 LIBOBJSとALLOCAの特殊処理

Automakeは@LIBOBJS@@ALLOCA@の使用を明示的に認識し、 この情報に配布物(see section 何が配布物に含まれるか)の適切なソース・ファイルを自動的に含めるた めに`configure.in'から得たLIBOBJSファイルのリストを加えて利 用する。これらのソース・ファイルはまた依存関係追跡の仕組みで自動的に処理 される。See section 自動的な依存関係の追跡を見よ。

@LIBOBJS@@ALLOCA@はどの`_LDADD'や`_LIBADD' 変数でも特別に認識される。


7.4 共有ライブラリの構築

共有ライブラリの構築は比較的複雑な問題である。この理由のために、GNU Libtool (see (libtool)Top section `Introduction' in The Libtool Manual) がプラットフォーム独立な方法で共有ライブラリを構築するのを助けるために作 成された。

Automakeは`LTLIBRARIES'主要変数で宣言されたライブラリを構築するため にLibtoolを利用する。各`_LTLIBRARIES'変数は構築する共有ライブラリの リストである。例えば、`libgettext.a'と名付けられたライブラリとそれ の対応する共有ライブラリを作成し、それらを`libdir'にインストールす るために、こう書く。

 
lib_LTLIBRARIES = libgettext.la

共有ライブラリはインストールされなければならないので、 `check_LTLIBRARIES'は許されない。しかし、`noinst_LTLIBRARIES' は許される。この特徴はlibtool "convenience libraries" のために使われる べきである。

それぞれのライブラリに対して、`library_LIBADD'変数は共有ライブラリ に追加するために追加のlibtoolオブジェクト(`.lo'ファイル)の名前を含 む。`library_LDFLAGS'変数は`-version-info'や`-static'のよ うな、追加のlibtoolフラグを含む。

通常のライブラリが@LIBOBJS@を含むようなところでは、libtoolライ ブラリは@LTLIBOBJS@を使用しなければならない。これはlibtoolが扱 うオブジェクト・ファイルは必ずしも`.o'で終わらないので必要である。 libtoolのマニュアルではこの話題についてもっと詳細な事を記している。

あるディレクトリにインストールされるライブラリに対して、Automake は自動的に適切な`-rpath'オプションを与えるだろう。しかしながら、設 定時に決定される(したがってEXTRA_LTLIBRARIESで記述される)ライブラ リに対しては、Automakeは結果になるインストール用のディレクトリが 分からない。そのようなライブラリには手で`-rpath'オプションを適切な `_LDFLAGS'変数に加えなければならない。

See Using Automake with Libtool: (libtool)Using Automake section `The Libtool Manual' in The Libtool Manualにもっと情報がある。


7.5 プログラムを構築するときに使用される変数

ときおりAutomakeがコンパイルに使用する`Makefile'変数がどれか知って おくと便利である。例えば、ある特別な場合にはあなた自身のコンパイル作業を 行う必要があるだろう。

いくつかの変数はAutoconfから引き継がれる。これらはCCCFLAGSCPPFLAGSDEFSLDFLAGS、そして LIBSである。

Automake自身が定義するいくつかの追加された変数がある。

INCLUDES

`-I'オプションのリスト。もしあなたが参照したい特別なディレクトリが あるなら、あなたの`Makefile.am'にこれを設定できる。Automake はいくつかの`-I'オプションをすでに自動的に与えている。特に `-I$(srcdir)'と`config.h'を持つディレクトリを指す`-I'を生 成する(AC_CONFIG_HEADERAM_CONFIG_HEADERを使っているなら)。

INCLUDESは実際には`-I'のほかに他のcppオプションのため に使用できる。例えば、ときどきコンパイラに任意の`-D'オプションを渡 すために使用される。

COMPILE

これは実際にCのソース・ファイルをコンパイルするために使われるコマンドで ある。ファイル名が完全なコマンドラインにするために付け加えられる。

LINK

これは実際にCプログラムをリンクするために使われるコマンドである。


7.6 YaccとLexのサポート

AutomakeはYaccとLexに対していくぶん特異なサポートを有している。

Automakeはyacc(あるいはlex)によって生成された`.c'ファイルは入力ファ イルの基部名(basename)を使って名前が付けられるべきだとみなしている。すな わち、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 (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual) を起動することにより最も簡単に行われる。

同じく、もしlexのソース・ファイルが現れるなら、あなたの `configure.in'は変数`LEX'を定義しなければならない。これを行う ために`AC_PROG_LEX'を使用できる(see (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual)。 Automakeのlexサポートはまた `AC_DECL_YYTEXT'マクロを使用することを必要とする--automakeは `LEX_OUTPUT_ROOT'の値を知る必要がある。 もしあなたがAM_PROG_LEXマクロ(see section Automakeと共に与えられるAutoconfのマクロ)を使用すれば、これは すべて処理される。

Automakeは単一のプログラムで複数のyacc(あるいはlex)のソース・ファイルを 含むことができるようにする。Automakeはサブディレクトリでyacc(ある いはlex)を走らせるためにylwrapと呼ばれる小さなプログラムを 使用する。これはyaccの出力ファイル名が固定であり、並列makeはyacc を一つ以上同時に起動することが考えられるので必要である。ylwrapプログラムは Automakeと共に配布されている。それは`AC_CONFIG_AUX_DIR'(see (autoconf)Input 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で動作する。もしここで含まれていないシンボルを使用するパーザ・ ジェネレータ(parser generator)を見付けたら、リストに加えられるように新し い名前を報告してください。


7.7 C++のサポート

AutomakeはC++に対する完全なサポート含んでいる。

C++コードを含むパッケージは出力変数`CXX'を`configure.in'で定義 しなければならない。これを行う一番簡単な方法はAC_PROG_CXXマクロ (see (autoconf)Particular Programs section `Particular Program Checks' in The Autoconf Manual)を使用することである。

C++のソース・ファイルが現れるとき、少数の変数が追加されて定義される。

CXX

C++コンパイラの名前。

CXXFLAGS

C++コンパイラに渡すフラグ。

CXXCOMPILE

C++のソース・ファイルを実際にコンパイルするために使われるコマンド。ファ イル名が完全なコマンドラインにするために付け加えられる。

CXXLINK

C++プログラムを実際にリンクするために使われるコマンド。


7.8 Fortran 77のサポート

AutomakeはFortran 77に対する完全にサポートを含む。

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

Fortran 77ソースファイルがある場合、少数の追加変数が定義される。

F77

Fortran 77コンパイラの名前。

FFLAGS

Fortran 77コンパイラに渡す、すべてのフラグ。

RFLAGS

Ratforコンパイラに渡すすべてのフラグ。

F77COMPILE

実際にFortran 77ソースファイルをコンパイルするコマンド。ファイル名は完全 なコマンドラインを構成するために付加される。

FLINK

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

Automakeは,追加コンパイルでFortran 77とRatforソースファイルの前処理をす ることができる(5)。Automakeは、Fortran 77と他の言葉の混合のプログラムと共有ライブラ リを作るため、いくつかサポートもする(see section CとC++と,Fortran 77の混在)。

これらの問題は次のセクションで述べる。


7.8.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.8.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.8.3 CとC++と,Fortran 77の混在

Automakeは、現在Fortran 77とCとC++の混合のプログラムと共有ライブラリを作 るための限定されたサポートを供給している。しかし、(現在) Automake によって処理されないが、他のパッケージ(6)によって処理されるFortran 77と他の言葉と混ぜることに 関連して多くの問題がある。

Automakeは2つの方法で補助が可能である。

  1. ソースコードのコンビネーションに依存したリンカの自動的な選択。

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

    これらの追加されたFortran 77リンカフラグは、Autoconf(Autoconfバージョン 2.13やそれ以降)の新しいバージョンで供給された、Autoconfマクロ AC_F77_LIBRARY_LDFLAGSが出力するFLIBS変数で供給される。 See (autoconf)Fortran 77 Compiler Characteristics 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は警告を出す。


7.8.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.8.4 Fortran 77とAutoconf

Fortran 77に対する現在のAutomakeサポートは、Fortran 77に対するサポートを 含む十分最近のバージョンのAutoconfも必要である。十分なFortran 77のサポー トがAutoconf2.13に加えられたので、それかそれ以降のバージョンのAutoconfを 使用しなさい。


7.9 他の言語のサポート

Automakeは現在C、C++(see section C++のサポート)とFortran 77(see section Fortran 77のサポート)のみ完全にサポートしてる。他の言葉に対しては、基本的なサポー トと、ユーザの需要に基づいて改善されるサポートしかない。


7.10 自動的な脱ANSI化

GNU標準はANSI Cの使用を許しているが、これはいくつかの古いコンパイラ(特に SunOS)へのパッケージの移植性を制限するという影響を持つ。

Automakeは実際のコンパイルが行われる前にそれぞれのソース・ファイルを脱 ANSI化することによって、そのようなマシンに関する問題を解決できる。

もし`Makefile.am'の変数AUTOMAKE_OPTIONS (see section Automakeの挙動の変更)がオプションansi2knr を含めば、脱ANSI化を処理するコードが生成される`Makefile.in'に挿入さ れる。

これでそのディレクトリのそれぞれのCのソース・ファイルがANSI Cとして扱わ れる。もしANSI Cコンパイラが利用可能なら、それが使われる。もしANSI Cコン パイラが利用できないなら、ソース・ファイルをK&Rに変換するために ansi2knrプログラムが使用され、それが次にコンパイルされる。

ansi2knrプログラムは単純である。ソース・コードが特定の方法で構成 されるとみなす。詳細はansi2knrのmanページを見よ。

脱ANSI化のサポートにはANSI Cのソースと同じパッケージにソース・ファイル `ansi2knr.c'と`ansi2knr.1'があることが必要である。これらのファ イルは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

もしディレクトリの接頭辞が与えられないなら、ファイルは現在のディレクトリ にあるとみなされる。

LIBOBJSの中に挙げられた脱ANSI化を必要とするファイルは自動的に処理 されないだろう。makeは(脱ANSI 化のとき)`regex_.o'を期待して いるのにconfigureは`regex.o'のようなオブジェクト名を生成する だろうから。最終的には、この問題はautoconfの魔法によって修正され るだろう。しかし今のところあなたはconfigure.inAC_OUTPUT の直前で以下のコードを書かなければならない。

 
# これはLIBOBJSの中の.oファイルもANSI2KNRフィルタ規則を通して構築される
# ために必要である。
LIBOBJS=`echo $LIBOBJS|sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'`

7.11 自動的な依存関係の追跡

開発者としては、インクルード・ファイルの依存関係があるプロジェクトで変更 する度に継続的に`Makefile.in'を更新するのはしばしば骨が折れる。 Automakeは自動的に依存関係の変更を追跡し、生成される `Makefile.in'で依存関係を配布する方法を提供する。

現在このサポートはGNU makegccの使用を必要とする。もし十 分な要求があれば、異なる依存関係生成プログラムを与えることが将来可能にな るかもしれない。一方、このモードはもしCプログラムやライブラリが現在のディ レクトリで定義されていればデフォルトで有効にされるので、GNU以外のmakeか らは`Must be a separator'エラーを受け取るかもしれない。

配布物を作ることに決めるとき、dist ターゲットはautomakeに`--include-deps'や他のオプションを付け て再び走らせる。See section `Makefile.in'の作成, と Automakeの挙動の変更。 これによりその前に生成された依存関係が生成される `Makefile.in'に挿入され、このようにして配布物に入れられる。この段階 はまた、あなたの配布物をダウンロードするがGNU makegccを 使わない人々がエラーを受け取らないように、依存関係生成コードの挿入を起こ さないようにする。

`Makefile.in'に加えるとき、その依存関係から全てのシステム特異的な依 存関係が取り除かれる。これは`OMIT_DEPENDENCIES'でファイルを列挙する ことで行われる。 例えば、システムのヘッダ・ファイルへの全ての参照がAutomakeによっ て取り除かれる。ときどき特定のヘッダ・ファイルが取り除かれるように指定す ることが役に立つ。例えば、もしあなたの`configure.in'が `AM_WITH_REGEX'を使用するなら、ユーザがパッケージを設定するまで正し いものが分からないので、`rx.h'や`regex.h'に関する依存関係は取 り除かれるべきである。

分かるだろうが、Automakeは正規表現のヘッダという特別な場合を扱う には実際十分利口である。またもし`AM_GNU_GETTEXT'が使われれば、自動 的に`libintl.h'を省く。

自動的な依存関係追跡はno-dependenciesを変数 AUTOMAKE_OPTIONSに入れることで抑えられる。

もしmake distによって作られた配布物を展開して、依存関係追跡コード を再び有効にしたいなら、単にautomakeを再び走らせなさい。

実際の依存関係ファイルは構築ディレクトリの下に、`.deps'と名付けられ たサブディレクトリの中に置かれる。これらの依存関係はマシンに特異的である。 そうしたいならそれらを削除するのが安全である。それらは次の構築の間に自動 的に再作成されるだろう。


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.