このプロジェクトでは Automake が使用されていますが、どれが本来の「ソースファイル」なのか判別が難しくなっています。Makefile.in や configure、config.h.in などのファイルはビルド時に自動生成されるにもかかわらず、バージョン管理に含まれてしまっているケースがあります。
この問題を整理するため、以前イシュー #32 で一部対処を試みましたが、ファイルの変更の経緯の把握が難しく、根本的な解決に至っていません。また、イシュー #33 では Berkeley DB ライブラリのバージョン更新を試みましたが、Autotools 構成ファイルの適切な更新方法が分からず、途中で断念した経緯があります。
そもそも Berkeley DB ライブラリの更新は、GNU Guix 公式リポジトリにおいて skktools パッケージがこの旧バージョンを理由に削除対象となっていることに起因しています。またGNU Guix は自由ソフトウェアであり、配布物には原則として「ソースファイルのみ」が含まれることが期待されています。したがって、Autotools によって生成される一時ファイルを除外し、本当のソースファイルのみをバージョン管理の対象にしたいと考えております。
問題点
- 自動生成ファイルがコミットされていると、環境差やマージ時に不整合が生じやすくなります
configure.ac のような構成ファイルを更新する際、何を変更すればよいのか不明瞭になります- 履歴にノイズが入り、真に意味のある変更だけを追跡するのが困難になります
提案
.c, .h, Makefile.am, configure.ac などの「本当のソースファイル」を明示的に定義・文書化する.gitignore を更新して以下のような自動生成ファイルを除外する：
/Makefile.in
/configure
/config.h.in
/aclocal.m4
/autom4te.cache/
/depcomp
/install-sh
/missing
README.md 等に、autoreconf -i などの再生成手順を記載
期待される効果
ソースツリーが簡潔になり、構成変更（特にライブラリ検出）やパッケージ対応の作業が容易になります。また、自由ソフトウェアのポリシーとも整合し、配布要件も満たしやすくなります。
このプロジェクトでは Automake が使用されていますが、どれが本来の「ソースファイル」なのか判別が難しくなっています。
Makefile.inやconfigure、config.h.inなどのファイルはビルド時に自動生成されるにもかかわらず、バージョン管理に含まれてしまっているケースがあります。この問題を整理するため、以前イシュー #32 で一部対処を試みましたが、ファイルの変更の経緯の把握が難しく、根本的な解決に至っていません。また、イシュー #33 では Berkeley DB ライブラリのバージョン更新を試みましたが、Autotools 構成ファイルの適切な更新方法が分からず、途中で断念した経緯があります。
そもそも Berkeley DB ライブラリの更新は、GNU Guix 公式リポジトリにおいて skktools パッケージがこの旧バージョンを理由に削除対象となっていることに起因しています。またGNU Guix は自由ソフトウェアであり、配布物には原則として「ソースファイルのみ」が含まれることが期待されています。したがって、Autotools によって生成される一時ファイルを除外し、本当のソースファイルのみをバージョン管理の対象にしたいと考えております。
問題点
configure.acのような構成ファイルを更新する際、何を変更すればよいのか不明瞭になります提案
.c,.h,Makefile.am,configure.acなどの「本当のソースファイル」を明示的に定義・文書化する.gitignoreを更新して以下のような自動生成ファイルを除外する：README.md等に、autoreconf -iなどの再生成手順を記載期待される効果
ソースツリーが簡潔になり、構成変更（特にライブラリ検出）やパッケージ対応の作業が容易になります。また、自由ソフトウェアのポリシーとも整合し、配布要件も満たしやすくなります。