[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
以下のセクションで,Automakeが動作する方法を理解することに役立つ,基本 的な考えをいくつか述べます.
2.1 一般的な操作 | General operation of Automake | |
2.2 厳密さ | Standards conformance checking | |
2.3 一様な命名法 | The Uniform Naming Scheme | |
2.4 派生される変数と命名法 | How derived variables are named | |
2.5 ユーザに対して予約されている変数 | Variables reserved for the user | |
2.6 automakeが必要とする可能性があるプログラム | Programs automake might require |
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 |
Automakeは,GNUパッケージの管理者が使用することを目的としていますが, 使用したいけれども,すべてのGNU規約を使用したいわけではない人たちをも 受け入れる努力をしています.
このため,Automakeは三つの厳密さのレベルをサポートします -- 厳 密さとは,Automakeに調査させる標準への適合度を示すものです.
有効な厳密さのレベルは以下のとおりです.
Automakeは,適切な処理のため絶対に必要なものだけを調査します.例えば, GNUの標準は`NEWS'ファイルが存在することを必要としますが,このモー ドで必要ではありません.この名前(foreign)は,本来はGNUプログラムのため にAutomakeを使用して欲しいのでこのように名付けられています.これらの緩 い規則は標準的な操作様式ではありません.
Automakeは,パッケージがGNUの標準に準拠しているかどうか -- 可能な限り -- 調査します.これはデフォルトです.
Automakeは,まだ書かれていないGnits standardsに準拠しているかど うかを調査します.これらはGNUの標準に基づいていますが,より詳しく記述 されています.Gnits standardsの貢献者でない場合,Gnits standardsが実際 に発表されるときまで(発表されることはないかもしれませんが),このオプショ ンの使用を避けるよう推奨します.
厳密さのレベルの正確な意味についての詳細は,--gnu
と--gnits
の効果を参照してくだ
さい.
Automakeには,厳密さに似ていますが異なる扱いを受ける,特殊な"cygnus"
モードもあります.このモードは,"Cygnus"形式のツリー(例えば,GCCツリー)
に配置するパッケージで役に立ちます.このモードの詳細は,--cygnus
の効果を
参照してください.
Automake変数は,一般に以下の一様な命名法(uniform naming scheme)
に従っていて,それは,プログラム(とその他の派生されるオブジェクト)のビ
ルド方法と,それらのインストール方法の決定を容易にします.この手法は,
configure
時にビルドするものを決定することもサポートしています.
make
時にビルドするオブジェクトを決定するため,特定の変数を使用
します.変数の名前は,いくつかの部品をお互いに連結したものからできてい
ます.
ビルドするものをautomakeに伝える部品は,一般にプライマリと呼ばれ
ています.例えば,プライマリのPROGRAMS
は,コンパイルされリンク
されるプログラムのリストを保持しています.
ビルドしたオブジェクトをインストールする場所を決定するため,異なる名前
の組が使用されます.これらの名前はプライマリに前置されていて,それはイ
ンストールするディレクトリとして使用される標準的なディレクトリを示して
います.標準的なディレクトリ名はGNUの標準で与えられています
(see (standards)Directory Variables 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 ライブラリのビルド)や, 補助的なスクリプトに対して有効です.
特別な接頭辞`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
これらの二つのファイルは,自動的なde-ANSI-ficationのサポートで使用され ます(see section 自動的な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
のインスタンスを単一のディレクトリで,並行して呼び出すこと
が可能であることを確かめます.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 8 2005 using texi2html 1.70.