2. 一般的な考え

以下のセクションで，Automakeが動作する方法を理解することに役立つ，基本 的な考えをいくつか述べます．

2.1 一般的な操作

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.ac'で 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

2.2 厳密さ

Automakeは，GNUパッケージの管理者が使用することを目的としていますが， 使用したいけれども，すべてのGNU規約を使用したいわけではない人たちをも 受け入れる努力をしています．

このため，Automakeは三つの厳密さのレベルをサポートします -- 厳 密さとは，Automakeに調査させる標準への適合度を示すものです．

有効な厳密さのレベルは以下のとおりです．

`foreign'

Automakeは，適切な処理のため絶対に必要なものだけを調査します．例えば， GNUの標準は`NEWS'ファイルが存在することを必要としますが，このモー ドで必要ではありません．この名前(foreign)は，本来はGNUプログラムのため にAutomakeを使用して欲しいのでこのように名付けられています．これらの緩 い規則は標準的な操作様式ではありません．

`gnu'

Automakeは，パッケージがGNUの標準に準拠しているかどうか ---可能な限り --- 調査します．これはデフォルトです．

`gnits'

Automakeは，まだ書かれていないGnits standardsに準拠しているかど うかを調査します．これらはGNUの標準に基づいていますが，より詳しく記述 されています．Gnits standardsの貢献者でない場合，Gnits standardsが実際 に発表されるときまで(発表されることはないかもしれませんが)，このオプショ ンの使用を避けるよう推奨します．

厳密さのレベルの正確な意味についての詳細は，21. --gnuと--gnitsの効果を参照してくだ さい．

Automakeには，厳密さに似ていますが異なる扱いを受ける，特殊な"cygnus" モードもあります．このモードは，"Cygnus"形式のツリー(例えば，GCCツリー) に配置するパッケージで役に立ちます．このモードの詳細は，22. --cygnusの効果を 参照してください．

2.3 一様な命名法

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)が定義されている場合に 有効です．

例えば，HTMLファイルのインストールはAutomakeの一部ですが，以下のように して生のHTMLドキュメントをインストール可能です．

htmldir = $(prefix)/html
html_DATA = automake.html

特別な接頭辞`noinst'は，該当するオブジェクトをビルドしインストー ルは決して行なわないことを示します．これは，パッケージ残りのビルドで必 要なオブジェクト，例えば，スタティックライブラリ(see section 8.2 ライブラリのビルド)や， 補助的なスクリプトに対して有効です．

特別な接頭辞`check'は，該当するオブジェクトがmake checkコ マンドが実行されるまでビルドされないことを示します．これらのオブジェク トはインストールもされません．

現在のプライマリ名は，`PROGRAMS'，`LIBRARIES'，`LISP'， `PYTHON'，`JAVA'，`SCRIPTS'，`DATA'， `HEADERS'，`MANS'，そして`TEXINFOS'です．

automakeの動作の他の側面を制御する，追加の接頭辞が可能なプライ マリもあります．現在定義されている接頭辞は，`dist_'， `nodist_'，そして`nobase_'です．これらの接頭辞は後で説明しま す(see section 8.4 プログラムとライブラリの変数)．

2.4 派生される変数と命名法

Makefileの変数名は，管理者が提供するいくつかのテキストから派生すること もあります．例えば，`_PROGRAMS'にリストアップされているプログラム 名は，`_SOURCES'変数の名前にも再び書き込まれます．このような状況 では，プログラム名とそれに類似したものがMakefileの変数命名規則に従う必 要が無いように，Automakeはテキストを標準に従うものにします．名前の中の 文字，数字，アットマーク(@)，そしてアンダースコア以外のすべての文字は， 変数で参照されるときにアンダースコアに変換されます．

例えば，プログラムをsniff-glueと命名する場合，派生する変数名は， sniff-glue_SOURCESではなくsniff_glue_SOURCESになります． 同様に，libmumble++.aと命名されるライブラリのソースは， libmumble___a_SOURCES変数にリストアップすべきです．

変数名の内部でAutoconfの置換を使用する際にできるだけ明瞭にするため，アッ トマーク(strudel)が追加されています．

2.5 ユーザに対して予約されている変数

Makefile変数には，"user"が使用するためにGNU Coding Standards で予約されているものもあります -- それはパッケージを構築する人のためで す．例えば，CFLAGSはそのような変数の一つです．

パッケージ開発者は，明らかに仕事を簡単にするために，CFLAGSのよ うなユーザ変数の設定を試みるときもあります．しかし，パッケージ自身でユー ザ変数を設定すべきではなく，特に，パッケージの適切なコンパイルに要求さ れるスイッチを含めるべきではありません．これらの変数はパッケージの構築 者に対して説明されるので，人々は，ビルド時にこれらの変数に優先させるこ とが可能だと期待しています．

この問題を解決するため，automakeはそれぞれのユーザフラグ変数に対し， automake特有の隠れた変数を導入しています．(隠れた変数は，CCのよ うな変数に対しては導入されておらず，それは意味が無いためです．)隠れた 変数は，ユーザ変数名に`AM_'を前置して命名されています．例えば， YFLAGSに対する隠れた変数は，AM_YFLAGSになります．

2.6 automakeが必要とする可能性があるプログラム

生成された`Makefile'が適切に動作するように，automakeが補助的なプ ログラムを必要とすることもあります．それらは数がかなり多いのですが，こ こにリストアップします．

ansi2knr.c

ansi2knr.1

これらの二つのファイルは，自動的なde-ANSI-ficationのサポートで使用され ます(see section 8.14 自動的なde-ANSI-fication)．

compile

これは，`-c'と`-o'の両方を同時に受け入れることができないコン パイラに対するラッパーです．それは実際に要求されたときだけ使用されます． そのようなコンパイラは滅多にありません．

config.guess

config.sub

これらのプログラムは，与えられているビルド，ホスト，またはターゲットの アーキテクチャといった，三つの標準的なものを調べます．これらのプログラ ムは，新しいアーキテクチャのサポートや新しいカーネルでの変更で検査の失 敗を修正するために定期的に更新されています．これらのファイルの最新バー ジョンをftp://ftp.gnu.org/gnu/config/から取得して，リリース物を 作成する前に確かめてください．

depcomp

要求された出力だけでなく，自動的な依存性の追跡機能で使用されている依存 情報も生成するために，このプログラムはコンパイラの実行方法を理解します．

elisp-comp

このプログラムは，Emacs Lispコードをバイトコンパイルするために使用され ます．

install-sh

これは，installプログラムの代わりのもので，installの利用 や使用が不可能なプラットフォームで動作します．

mdate-sh

このスクリプトは，`version.texi'ファイルを生成します．それはファ イルを調査し，それに関する日付の情報を出力します．

missing

これは，通常管理者だけが必要とするいくつかのプログラムのラッパーです． 該当のプログラムが存在しない場合，missingは情報を伝える警告を出 力し，ビルドを継続することが可能になるように修正を試みます．

mkinstalldirs

このスクリプトは移植性が無いmkdir -pのラッパーです．現在我々は， mkdir -pが動作しないことをconfigure時に見つけたとき， install-sh -dを使用するようにしていて，これで配布時のスクリプト が少なくなります．

automakeがパッケージでmkinstalldirsを見つけた時，下位互 換性のため，それはまだ使用され配布されます．しかし，それはもはや自動的 にインストールされず，削除した方が安全でしょう．

py-compile

これは，Pythonスクリプトをバイトコンパイルするために使用されます．

texinfo.tex

プログラムではなく，パッケージにTexinfoソースファイルがあるとき，この ファイルは，make dvi，make ps，そしてmake pdfを動 作させるために必要になります．

ylwrap

このプログラムは，lexとyaccのラッパーで，例えば，複数の yaccのインスタンスを単一のディレクトリで，並行して呼び出すこと が可能であることを確かめます．