以下のセクションで,Automakeが動作する方法を理解することに役立つ,基本的 な考えをいくつか述べます.
Automakeは`Makefile.am'を読み込み,`Makefile.in'を生成する仕事 をします.`Makefile.am'で定義されている変数とターゲットで,Automake は更に特殊なコードを生成します.例えば,`bin_PROGRAMS'変数定義で, 生成されるプログラムをコンパイルしてリンクするターゲットを生成します.
`Makefile.am'の変数定義とターゲットは,そのまま生成されたファイルに
コピーされます.これにより,生成される`Makefile.in'に任意のコードを
加えることが可能になります.例えばAutomakeの配布物には,Automake管理者が
ソースコントロールシステムから配布物を作成するときに使用する,非標準的な
cvs-dist
ターゲットが含まれています.
ほとんどのGNU makeの拡張は,Automakeが理解しないことに注意してください. `Makefile.am'でこのような拡張を使用すると,エラーが生じたり紛らわし い動作をしたりします.
特別な例外として,GNU makeの追加オペレータの`+='はサポートされてい ます.このオペレータは,その右辺の引数を左辺で指定された変数に追加します. Automakeはそのオペレータを通常の`='オペレータに変換します.このため `+='は,あらゆるmakeプログラムでうまく動作します.
Automakeは賢い方法で,ターゲットと変数定義に隣接しているグループ化された コメントの保持を試みます.
一般に,`Makefile.am'で定義されているターゲットは,automake
によって自動的に生成されるターゲットに似た名前を持つものに優先します.こ
れをサポートしてはいるのですが,一般的に,生成される規則は非常に特殊なこ
ともあるので,それを利用することは避けたほうがよいでしょう.
同様に,`Makefile.am'で定義されている変数や`configure.in'で
AC_SUBST
されているものも,automake
が通常作成するあらゆる変
数定義より優先されます.この機能は,ターゲット定義の優先より役に立つこと
が多いでしょう.automake
で生成されたマクロの多くは,内部で使用す
ることだけを考慮に入れていて,それらマクロ名が将来のリリースで変更される
可能性があることに注意しておいてください.
変数定義を調査しているとき,Automakeは定義で参照されている変数を再帰的に
調査します.例えば,以下の断片的なfoo_SOURCES
の内容をAutomake が
調査している状況を考えます.
xs = a.c b.c foo_SOURCES = c.c $(xs)
それは,ファイル`a.c',`b.c',そして`c.c'を
foo_SOURCES
の内容として使用します.
Automakeでは,出力ファイルにコピーされないコメントの形式も利用可 能です.Automakeは`##'で始まる(スペースの前置は可能です)すべての行 を完全に無視します.
読み込まれる`Makefile.am'の最初の行に,以下の行を書くのはいつものこ とです.
## Process this file with automake to produce Makefile.in
Automakeは,GNUパッケージの管理者が使用することを目的としていますが,使 用したいけれども,すべてのGNU規約を使用したいわけではない人たちをも受け 入れる努力をしています.
このため,Automakeは三つの厳密さのレベルをサポートします -- 厳密 さとは,Automakeに調査させる標準への適合度を示すものです.
有効な厳密さのレベルは以下のとおりです.
厳密さのレベルの正確な意味についての詳細は,section --gnu
と--gnits
の効果を参照してくださ
い.
Automakeには,厳密さ似にていますが異なる扱いを受ける,特殊な"cygnus"モー
ドもあります.このモードは,"Cygnus"形式のツリー(例えば,GCCツリー)に
配置するパッケージで役に立ちます.このモードの詳細は,section --cygnus
の効果を参照
してください.
Automake変数は,一般に以下の一様な命名法(uniform naming scheme)に
従っていて,それは,プログラム(とその他の派生されるオブジェクト)のビルド
方法と,それらのインストール方法の決定を容易にします.この手法は,
configure
時にビルドするものを決定することもサポートしています.
make
時にビルドするオブジェクトを決定するため,特定の変数を使用し
ます.変数の名前は,いくつかのピースをお互いに連結したものからできていま
す.
ビルドするものをautomakeに伝える部品は,一般にプライマリと呼ばれて
います.例えば,プライマリのPROGRAMS
は,コンパイルされリンクされ
るプログラムのリストを保持しています.
ビルドしたオブジェクトをインストールする場所を決定するため,異なる名前の
組が使用されます.これらの名前はプライマリに前置されていて,それはインス
トールするディレクトリとして使用される標準的なディレクトリを示しています.
標準的なディレクトリ名はGNUの標準で与えられています(see section `Directory Variables' in The GNU Coding Standards).Automakeは,
pkglibdir
,pkgincludedir
,そしてpkgdatadir
を用いて,
このリストを拡張します.これらは非`pkg'のバージョンと同じですが,
`@PACKAGE@'が付加されます.例えば,pkglibdir
は
$(libdir)/@PACKAGE@
として定義されます.
それぞれのプライマリに対して,`EXTRA_'をプライマリ名に前置して命名
された追加の変数があります.この変数は,ビルドされたりされなかったりする
可能性のあるオブジェクトのリストで使用され,それは,configure
が決
定したものに依存します.Automakeは,すべての状況で動作する
`Makefile.in'を生成するために,ビルドされる可能性のあるオブジェクト
全体のリストをあらかじめ知っておく必要があるので,この変数が必要になりま
す.
例えば,cpio
はconfigure時にビルドするプログラムを決定します.
bindir
にインストールされるプログラムもあれば,sbindir
にイ
ンストールされるものもあります.
EXTRA_PROGRAMS = mt rmt bin_PROGRAMS = cpio pax sbin_PROGRAMS = @MORE_PROGRAMS@
接頭辞がないプライマリを変数として定義すること,例えばPROGRAMS
は
エラーになります.
一般的な`dir'接尾辞は,変数名を作るときには捨てられることに注意して 下さい.このため,`bindir_PROGRAMS'ではなく,`bin_PROGRAMS'と 書きます.
すべての種類のオブジェクトが,すべてのディレクトリにインストールされるわ けではありません.Automakeはエラーを見つけたとき,フラグを付けようとしま す.Automakeはディレクトリ名での明らかなスペルミスも診断します.
標準ディレクトリは---Automakeによって強化されてはいますが---十分でない場
合もあります.特に,前もって定義されているディレクトリのサブディレクトリ
にオブジェクトをインストールすると役に立つこともあります.このため,
Automakeはインストール可能なディレクトリのリストを拡張することを可能にし
ます.与えられている接頭辞(例えば`zar')は,同じ名前の変数に
`dir'を付加した変数(例えばzardir
)が定義されている場合に有効
です.
例えば,Automakeの一部としてHTMLがサポートされるまで,以下のようにして生 のHTMLドキュメンテトをインストール可能でしょう.
htmldir = $(prefix)/html html_DATA = automake.html
特別な接頭辞`noinst'は,該当するオブジェクトはビルドすべきですが決 してインストールされるべきではないことを示します.これは,パッケージ残り のビルドで必要なオブジェクト,例えば,スタティックライブラリ(see section ライブラリのビルド)や,補助的なスクリプトに対して有効です.
特別な接頭辞`check'は,該当するオブジェクトがmake check
コマ
ンドが実行されるまでビルドされないことを示します.これらのオブジェクトは
インストールもされません.
現在のプライマリ名は,`PROGRAMS',`LIBRARIES',`LISP', `PYTHON',`JAVA',`SCRIPTS',`DATA',`HEADERS', `MANS',そして`TEXINFOS'です.
automake
の動作の他の側面を制御する,追加の接頭辞が可能なプライマ
リもあります.現在定義されている接頭辞は,`dist_',`nodist_',
そして`nobase_'です.これらの接頭辞は後で説明します(see section プログラムとライブラリの変数).
Makefileの変数名は,管理者が提供するいくつかのテキストから派生することも あります.例えば,`_PROGRAMS'にリストアップされているプログラム名は, `_SOURCES'変数の名前にも再び書き込まれます.このような状況では,プ ログラム名とそれに類似したものがMakefileの変数命名規則に従う必要が無いよ うに,Automakeはテキストを標準に従うものにします.名前の中の文字,数字, アットマーク(@),そしてアンダースコア以外のすべての文字は,変数で参照さ れるときにアンダースコアに変換されます.
例えば,プログラムをsniff-glue
と命名する場合,派生する変数名は,
sniff-glue_SOURCES
ではなくsniff_glue_SOURCES
になります.同
様に,libmumble++.a
と命名されるライブラリのソースは,
libmumble___a_SOURCES
変数にリストアップすべきです.
変数名の内部でAutoconfの置換を使用する際にできるだけ明瞭にするため,アッ トマーク(strudel)が追加されています.
Makefile
変数には,"user"が使用するためにGNU Coding Standardsで
予約されているものもあります -- それはパッケージを構築する人のためです.
例えば,CFLAGS
はそのような変数の一つです.
パッケージ開発者は,明らかに仕事を簡単にするために,CFLAGS
のよう
なユーザ変数の設定を試みるときもあります -- 彼らはすべてのターゲットに二
番目の変数を導入する必要はありません.
しかし,パッケージ自身でユーザ変数を設定すべきではなく,特に,パッケージ の適切なコンパイルに要求されるスイッチを含めるべきではありません.これら の変数はパッケージの構築者に対して説明されているので,人々は,ビルド時に これらの変数に優先させることが可能だと期待しています.
この問題を解決するため,automakeはそれぞれのユーザフラグ変数に対し,
automake特有の隠れた変数を導入しています.(隠れた変数は,CC
のよう
な変数に対しては導入されておらず,それは意味が無いためです.)隠れた変数
は,ユーザ変数名に`AM_'を前置して命名されています.例えば,
YFLAGS
に対する隠れた変数は,AM_YFLAGS
になります.
生成された`Makefile'が適切に動作するように,automakeが補助的なプロ グラムを必要とすることもあります.それらは数がかなり多いのですが,ここに リストアップします.
ansi2knr.c
ansi2knr.1
compile
config.guess
config.sub
depcomp
elisp-comp
install-sh
install
プログラムの代わりのもので,install
の利用や
使用が不可能なプラットフォームで動作します.
mdate-sh
missing
missing
は情報を伝える警告を出力し,
ビルドを継続することが可能になるように修正を試みます.
mkinstalldirs
mkdir -p
に移植性が無い問題を解決します.
py-compile
texinfo.tex
make dvi
,make ps
,そしてmake pdf
を動作させ
るために必要になります.
ylwrap
lex
とyacc
のラッパーで,例えば,複数の
yacc
のインスタンスを単一のディレクトリで,並行して呼び出すことが
可能であることを確かめます.
Go to the first, previous, next, last section, table of contents.