Next: maintainer-mode, Up: FAQ
AutoconfとAutomakeを用いて作成したパッケージは,configureや Makefile.inといった生成されるファイルとともに配布されます.これ らのファイルは開発者のホストで生成され,それらをビルドするためにエンド ユーザが管理用のツールをインストールする必要が無いように配布されます. Lexスキャナー,Yaccパーサ,またInfoドキュメントのような,それ以外に生 成されるファイルは,同じ理由で通常配布されます.
例えば,configure.acが変更されたときはconfigureをリビル ドするためにautoconfを実行します.configureが対応する configure.acより古くないように,開発者が確実に行なえます.
パッケージで配布されている,生成されたファイルは最新で,tar でタイムスタンプを保存しているので,これらのリビルドのルールはユーザが パッケージを展開しビルドするときも開始されません.
CVSキーワードを使用していない限り(この状況ではコミット時にファイルを更
新する必要があります),cvs commit
とcvs import -d
の処理中
にCVSが保持しているタイムスタンプは保持されます.
cvs checkout
を使用してファイルをチェックアウトしたとき,そのタ
イムスタンプは,チェックアウトしたリビジョンで設定されたタイムスタンプ
になります.
しかし,cvs updateしたとき,ファイルの日付が更新されますが, オリジナルのタイムスタンプはこのリビジョンになります.これは, makeでソースファイルが更新されたことに確実に気付くことを意味 します.
このタイムスタンプの変更は,ソースと生成されたファイルの両方をCVSに保
持しているときは面倒です.CVSはアルファベット順にファイルを処理するの
で,cvs updateで両方のファイルを更新した後は,チェックイン時
にconfigure.acよりconfigureのほうが新しい場合でも,
configureよりconfigure.acが古いものとして表されます.
make
を呼び出すと,間違ってconfigureのリビルドが開始され
ます.
基本的に二種類の管理者がいます.生成されるファイルを含め,すべての配布 されるファイルをCVSの元に保持している人,そして,生成されたファイルを CVSの外部に保持している人です.
実際,そのようなツールの呼び出しは,後で議論するmissingスク リプトで呼び出しにすべてラップされています(see maintainer-mode). missingは,これらのツールがインストールされていないとき,ビ ルドが続けられるように,タイムスタンプを修正します.
AM_MAINTAINER_MODE
を使用します.これは,
maintainer-modeで更に議論していきます.
例えば,開発者が編集されたMakefile.amとリビルドされた Makefile.inを所有していて,両方のファイルを調査する直前に Makefile.amの変更を決定したと仮定します(変更に対応する Makefile.inをリビルドする前です).
この最後のMakefile.amの変更で,Makefile.inのコピーは古い
ものになっています.CVSはファイルをアルファベット順に処理するので,他
の開発者がツリー上でcvs update
するとき,Makefile.inが
Makefile.amより新しくなってしまいます.この開発者は,
Makefile.inが古いことが分からないでしょう.
CVSとmake
を平和に動作させる一つの方法は,生成されるファイルを
CVSに保存しないことで,すなわち,Makefile
のターゲット(派
生ファイルとも呼ばれます)をCVSの制御下におかないことです.
この方法では,開発者は生成されるファイルの変更で悩むことはありません. 全員が異なるバージョンを所有している場合は問題になります(もちろん互換 性があると仮定してもです).結局,タイムスタンプは失われ,ソースファイ ルへの変更は,これまでに議論してきた Makefile.am/Makefile.inの例のように失われてしまうはずで す.
欠点は,配布されるものの正確なコピーがCVSリポジトリに無いことと,チェッ クアウトしたものをビルド可能にする前に,様々な開発ツール(バージョンが 指定されるかもしれません)をユーザがインストールする必要があるというこ とです.しかし,結局は,CVSの仕事はバージョン管理であり,配布ではあり ません.
開発者が異なるバージョンのツールの使用を可能にすると,配布された開発物 のバグを隠すことにもなります.事実,開発者は,実際のリリースで生成され るファイルの代わりに,(テストであっても)自分が生成したファイルを使用し ます.tarballを準備している開発者は,使用しているツールのバージョンが 間違った出力を生成するものを使用している可能性があり(例えば,移植性の ないCファイル),他の開発者が,独自のバージョンのこのツールを使用してい ない場合,注意されることになるでしょう.
(タイムスタンプの問題が無いので)ここでは議論しませんが,それ以外に分類 されるファイルとして,パッケージとともに配布されるけれども,どこでも管 理されていないファイルがあります.例えば,gettextizeと autopoint(Gettext由来)や,libtoolize(Libtool由来) のようなツールは,パッケージにファイルをインストールしたり更新したりし ます.
これらのファイルは,CVSに保持しようが保持しまいが,開発者のツール間の バージョンの違いについて,似たようなことが生じます.Gettextのマニュア ルにはこれに関するセクションがあります.CVS Issuesを参照して下さい.