On Wed, 2004-10-20 at 22:37, Lothar Behrens wrote:
On Tue, 2004-10-19 at 20:22, Lothar Behrens wrote:
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.
Wenn ich denn aber die Dateien habe, die ich an Automake weitergebe. Kann ich diese Liste nicht für dist wieder verwenden ? Genau das macht automake.
(+ einer Liste der Metadateien) siehe EXTRA_DIST in automake.info
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).
Ahhsoo, Du meinst z.B. doxygen Dateien, oder ähnliches was für ein Programm benötigt wird - wie das Programm selbst. Ja, das wäre ein derartiger Fall.
Mein dist ist dann kein dist in dem Sinne von einem Paket mit fertigen Programm. Es ist schlieslich ein Framework zur Programmentwicklung.
Ich habe noch ne Frage: Ich baue gerade mein Makesystem so um, dass ich nicht mehr diese Shell oder Batch Scripte brauche.
Es klappte nach ein paar Fehlern und Versuchen dann auch. Nicht mehr immer die unnötigen Builds :-)
Nun klappt attrib -r *.bak nicht mehr. Hier habe ich folgenden Fehler: attrib? DOS ???
Aber warum kann make den Befehl nicht genauso ausführen wie von der Kommandozeile ? Vermutlich weil gmake deine DOS-Pfade entfernt und das M$-proprietäre Tool attrib nicht findet.
Ich WeiÃ, dies ist eine Linux Liste, aber ich arbeite halt mal mit GNU make unter Windows. Dann frag auf der Cygwin-Liste oder frag M$, die sollten es wissen :-)
Was attrib und automake anbetrifft: Automake setzt eine POSIX-kompatible Umgebung voraus. attrib ist proprietär und hat deshalb in Automake-Makefile.ams nichts verloren.
Also ist automake für mich gestorben. Folgende Gründe:
Ich werde es warscheinlich nicht als zentrales Tool verwenden können. (Windows mit cygwin/Linux direkt) Was Du hier sagst, ergibt keinen Sinn. Windows mit Cygwin oder Linux erfüllen die Anforderungen der Autotools.
Ich sollte in automake.ams keine proprietaeren Tools reinmischen. Daher werde ich es schlecht unter Windows verwenden können. Ausser mit den equivalenten cygwin tools. Zwingt aber den User viele Teile der cygwin Tools zu installieren. Ja. Das ist eine ummittelbare Folge der Nicht-POSIX-Kompatibilität der DOS-Welt.
Allerdings sollte dir bewusst sein, dass diese Infrastruktur kleiner ist, als es viele WIN/DOS-Pakete sind.
MKMK unterstützt mehrere Compiler unter Windows und z.Z. GCC unter Linux.
Es schreibt automatisch die makefiles für mein Projekt. (pro Projekt Modul. Über eine Erweiterung für das Hauptmakefile denke ich nach)
Ich biete dem Benutzer den gleichen make Prozess in beiden Welten. Wieder jemand, der glaubt cleverer zu sein, ...
... "Makefile-Generatoren" und "Projekt-Managertools" gibt es wie Sand am Meer; die Guten und Ausgereiften darunter sind _sehr_ selten; keines, das mir bisher begegnet ist, war auch nur annähernd in der Lage alle Anforderung zu erfüllen ... ... die meisten dieser Tools überleben nicht sehr lange. ... let the bazaar vote ... URL? Ralf