13.6.2 Files to put under version control

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

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

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

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

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

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

AM_GNU_GETTEXT_VERSION(0.19.8)

さらにパッケージのpre-buildスクリプトに‘autopoint’呼び出しを追加します。ソースをチェックアウトする人は誰でも、この‘autopoint’呼び出しによりリポジトリーから除外された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以降をインストールする必要があります。