On Fri, 2004-10-15 at 20:12, Lothar Behrens wrote:
Doch warum nicht hart-codierte Dateinamen oder find oder ls nehmen, falls Dir hart-codierte Dateinamen als zu umständlich erscheinen?
find und ls erwischen möglicherweise zuviel (Testdateien, Tempfiles), bei hartcodierten Listen wird erfahrungsgemäß schnell mal was vergessen. CVS/Entries ist eben immer aktuell ;-)
Du vergisst eines: Zwischen CVS/Entries und "make dist" Dateilisten besteht kein strenger Zusammenhang (vgl. unten). Verwendest Du CVS/Entries wirst Du ebenso filtern müssen wie bei Verwendung von find/ls etc.
Fast immer aktuell. Man darf nicht vergessen, neue Dateien auch zu adden und committen. Aber eigentlich ist dann der Entwickler selbst schuld :-)
Ich finde, dass das makesystem selbst dafür sorgen sollte. Wie kann es das?
Es kann z.B. nicht wissen, was Quellcode, was Editor-Backup, was generierte Datei, was temporäre Datei und was Meta-Daten der Entwicklungsumgebung sind.
Schlieslich sorgt ein autoconf dafür, dass alles richtig kompiliert werden kann. So findet es alle relevanten Quelldateien und deren Header. Weder autoconf noch automake *finden* Quelldateien.
Automake nimmt nur die Quell-Dateien, die Du ihm im mitgeteilt hast zu nehmen (z.B. *_SOURCES im Makefile.am) und seine eigene Infrastruktur (aclocal.m4, configure, configure.ac etc.). Autoconf ist an der Zusammenstellung der Dateilisten für "make dist" gar nicht beteiligt.
Diese Liste der Dateien könnte man doch als Basis für ein 'dist' verwenden. Siehe oben.
Optional ist immer noch die CVS/Entries Methode eine gute Wahl. Nein. CVS/Entries sind Meta-Daten einer Entwicklungsumgebung.
In der Regel wird CVS/Entries dabei Dateien beinhalten, die nicht Bestandteil eines Paketes sind (z.B. .cvsignore), anderseits wird es aber auch Dateien *nicht* beinhalten, die Bestandteil eines Paketes sind (z.B. generierte Dateien). Ralf