13.6.2 CVSバージョンコントロールの配下に置くファイル

CVSレポジトリーのコンテキストで作成されるファイル、たとえばconfigure.acにより生成されるconfigure、parser.yから生成されるparser.c、gettextizeやautopointにより自動インストールされるpo/Makefile.in.inのようなファイルを取り扱うには、基本的に3つの方法があります。

1. 生成されるすべてのファイルを、常にレポジトリーにコミットする。
2. 生成されるすべてのファイルを、時々(たとえば毎リリースごとに)レポジトリーにコミットする。
3. 生成されるファイルを、レポジトリーにコミットされない。

これら3つの方法には、それぞれ異なる利点と欠点があります。

1. 1番目の方法の利点は、誰でもCVSからその時点で動作するビルドをチェックアウトできる点です。欠点は以下のとおりです:
   1a メンテナーによる頻繁な"cvs commit"操作が必要です。
   1b レポジトリーサイズの増加が早くなります。
2. 2番目の方法の利点は、誰もがチェックアウトでき、通常は"./configure; make"は動作します。欠点は以下のとおりです:
   2a レポジトリーからチェックアウトした人のPATHにGNU automake、GNU autoconf、GNU m4のようなツールがインストールされている必要があり、ときには特定のバージョンが必要になる。
   2b リリース版が作成されて生成されるファイルもコミットされた後に他の開発者が"cvs update"を行うと、生成されるファイルで競合が発生する点。この競合は簡単に解決できますが、煩わしいものです。
3. 3番目の方法の利点はメンテナーの作業負荷が軽減されることです。欠点はレポジトリーからチェックアウトした人のPATHにGNU automake, GNU autoconf, GNU m4のようなツールがインストールされている必要があるだけではなく、"./configure; make"をできるようになる前に、パッケージ固有のpre-build(ビルド前)ステップが必要になることです。

1番目と2番目の方法では、変更されたファイルや、gettextize呼び出しにより生成・更新されたファイルは、CVSにコミットする必要があります。

3番目の方法では、gettextizeが"コピー"するすべてのファイルを、CVSレポジトリーから除外できます。そのかわりにconfigure.ac(またはconfigure.in)を、以下のような形式で記述します

AM_GNU_GETTEXT_VERSION(0.18.3)

さらにパッケージのpre-buildスクリプトに‘autopoint’呼び出しを追加します。CVSからチェックアウトする人は誰でも、この‘autopoint’呼び出しによりCVSから除外されたgettextの基礎的なファイルが適切な場所にコピーされます。

AM_GNU_GETTEXT_VERSIONの引数に使用されているバージョン番号は、パッケージが使いたいgettextインフラストラクチャーのバージョン番号です。これは‘autopoint’プログラムの最小のバージョン番号でもあります。もしAM_GNU_GETTEXT_VERSION(0.11.5)と記述した場合、開発者は0.11.5以上のバージョンを使用でき、すべての開発者のビルドがバージョン0.11.5のインフラストラクチャーで動作します。メンテナーがパッケージにたいしてバージョン0.12.1を指定してgettextizeを実行したとき、AM_GNU_GETTEXT_VERSION(0.11.5)はAM_GNU_GETTEXT_VERSION(0.12.1)に変更され、今後CVSを使う開発者はGNU gettext 0.12.1以降をインストールする必要があります。