Hallo, ich habe ein übergeordnetes makefile, in dem ich alle Teilprojekte durch automatisch generierte Makefiles baue. Ich bekomme das mit dem clean Aufruf nicht hin. Dies ist das makefile: MAKESUBDIR= \ @( \ cd $@; \ ./makefile.sh; \ make; \ ) MAKEWXSAMPLE= \ @( \ cd $@; \ make -f makefile.wx-sample; \ ) all_targets: lbHook \ lbDB \ lbModule \ lbclasses \ lbMetaApplication \ ../AppDevelopmentDemo/App \ ../Test/Console/XML \ ../Test/GUI/wxWrapper ../AppDevelopmentDemo/App: dummy $(MAKESUBDIR) lbHook: dummy $(MAKESUBDIR) lbDB: dummy $(MAKESUBDIR) Und so weiter... Hat da jemand einen Tip ? Danke Lothar ---- My home: www.lollisoft.de ----------------------------- Lothar Behrens | Independent: lothar.behrens@gmx.de Rosmarinstr 3 | My public project: 40235 Düsseldorf | http://sourceforge.net/projects/lbdmf | -> Need comments, please visit :-)
On Sat, 2004-10-09 at 08:38, Lothar Behrens wrote:
Hallo,
ich habe ein übergeordnetes makefile, in dem ich alle Teilprojekte durch automatisch generierte Makefiles baue.
Ich bekomme das mit dem clean Aufruf nicht hin.
Ich sehe keinen clean-Aufruf in deinem "Makefile".
Dies ist das makefile:
MAKESUBDIR= \ @( \ cd $@; \ ./makefile.sh; \ make; \ )
Generelle Anmerkung: Die "Make-Syntax" ist eine regel-basierte Sprache und keine sequenziell arbeitende Scriptsprache. Wie ich es sehe, scheinst Du die Make-Syntax aber als "Scriptsprache" zu interpretieren. "clean:" wäre also kein "Aufruf" sondern ein PHONY-Target.
Hat da jemand einen Tip ?
Schau Dir gmake.info mal sehr genau an oder nimm gleich automake. Ralf
On Sat, 2004-10-09 at 08:38, Lothar Behrens wrote:
Hallo,
ich habe ein übergeordnetes makefile, in dem ich alle Teilprojekte durch automatisch generierte Makefiles baue.
Ich bekomme das mit dem clean Aufruf nicht hin.
Ich sehe keinen clean-Aufruf in deinem "Makefile".
Ist momentan auch wieder rausgenommen, da es in dieser Datei nichts bringt. Dieses Makefile war ursprünglich auch mal ein shell/batch Script. Die eigentlichen Makefiles sind in den jeweiligen unterverzeichnissen.
Dies ist das makefile:
MAKESUBDIR= \ @( \ cd $@; \ ./makefile.sh; \ make; \ )
Generelle Anmerkung: Die "Make-Syntax" ist eine regel-basierte Sprache und keine sequenziell arbeitende Scriptsprache. Wie ich es sehe, scheinst Du die Make-Syntax aber als "Scriptsprache" zu interpretieren.
Ist mir schon klar, dass dieses Makefile eine 'Verunklimpfung' von make ist.
"clean:" wäre also kein "Aufruf" sondern ein PHONY-Target.
Mein clean in jeweils einem Unterverzeichniss ist dieses und ist getestet. Mein PHONY ist: clean: rm *.o rm *.so.* Ich weiß nur nicht wie ich den clean Parameter an die 'submakes' weiter gebe. Lothar
Hat da jemand einen Tip ?
Schau Dir gmake.info mal sehr genau an oder nimm gleich automake.
Ralf
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
---- My home: www.lollisoft.de ----------------------------- Lothar Behrens | Independent: lothar.behrens@gmx.de Rosmarinstr 3 | My public project: 40235 Düsseldorf | http://sourceforge.net/projects/lbdmf | -> Need comments, please visit :-)
Moin moin, Am Samstag, 9. Oktober 2004 11:06 schrieb Lothar Behrens: [...]
clean: rm *.o rm *.so.*
Ich weiß nur nicht wie ich den clean Parameter an die 'submakes' weiter gebe.
Du musst AFAIK auch im Master-makefile ein Target angeben. clean: cd project_dir; make clean So halte ich das jedenfalls, in 'make' kann man auch AFAIR ein wenig skripten... Jedenfalls kannst Du im Makefile auch Programme, etc angeben, die rekursiv durch Deine Unterverzeichnisse laufen und z.B. Objekt-Dateien löschen. OBJS = mod_1 mod_2 target-clean: ${PERL} ./bin/cleanup_directory.pl ${OBJS} "Make" ist ein wunderbares Tool, damit kannst Du fast alles automatisieren :)) Wenn Du ein wenig in den man-pages guckst, findest Du vielleicht etwas wie VPATH oder den Modifikatoren "D" und "F". Damit kannst Du auch noch tricksen, wenn es um Unterverzeichnisse geht. Ciao Andre
Hallo Lothar, hallo Leute, Am Samstag, 9. Oktober 2004 11:06 schrieb Lothar Behrens:
On Sat, 2004-10-09 at 08:38, Lothar Behrens wrote:
ich habe ein übergeordnetes makefile, in dem ich alle ^^ BTW: Du hast ein utf8-Problem beim Zitieren.
Teilprojekte durch automatisch generierte Makefiles baue. [...] Generelle Anmerkung: Die "Make-Syntax" ist eine regel-basierte Sprache und keine sequenziell arbeitende Scriptsprache. Wie ich es sehe, scheinst Du die Make-Syntax aber als "Scriptsprache" zu interpretieren.
Ist mir schon klar, dass dieses Makefile eine 'Verunklimpfung' von make ist.
*g*
Mein clean in jeweils einem Unterverzeichniss ist dieses und ist getestet. [...] Ich weiß nur nicht wie ich den clean Parameter an die 'submakes' weiter gebe.
SUBDIRS = subdir1 subdir2 subdir3 clean: @for d in $(SUBDIRS); do \ $(MAKE) -C $$d clean || exit $? ; \ done (das "|| exit $?" ist wichtig, damit im Fehlerfall auch der make-Lauf abbricht) Für weitere Inspirationen kann ich Dir die Makefiles der Fontlinge empfehlen (bei Sourceforge im CVS zu betrachten). Obiges Schnipsel ist eine vereinfachte Form aus fontlinge_rc/modules/Makefile. Recht interessant ist übrigens auch die Implementation von "make dist" auf Basis von CVS/Entries ;-) (fontlinge_rc/Makefile) Gruß Christian Boltz -- Fontlinge developer Fontlinge - font management for Linux / Schriftenverwaltung for Linux Infos und Download: http://www.gesindel.de
On Sat, 2004-10-09 at 15:50, Christian Boltz wrote:
SUBDIRS = subdir1 subdir2 subdir3
clean: @for d in $(SUBDIRS); do \ $(MAKE) -C $$d clean || exit $? ; \ done
(das "|| exit $?" ist wichtig, damit im Fehlerfall auch der make-Lauf abbricht) Für weitere Inspirationen kann ich Dir die Makefiles der Fontlinge empfehlen (bei Sourceforge im CVS zu betrachten).
Es ist immer wieder interessant zu lesen, was manche Leute als allgemeingültig zu verkaufen versuchen ;-) 2 Portabilitätsfehler aus deinem Beispiel: 1. "for d in $(SUBDIRS)" ist nicht portabel. 2. "make -C" ist nicht portabel. [Es hat seine Gründe, warum die von automake verwendeten Konstrukte scheinbar umständlich sind. Wenn dein Paket nur unter Linux/GNU übersetzbar sein soll, sind diese Konstrukte in Ordnung, sonst aber nicht. ]
Obiges Schnipsel ist eine vereinfachte Form aus fontlinge_rc/modules/Makefile. Recht interessant ist übrigens auch die Implementation von "make dist" auf Basis von CVS/Entries ;-) (fontlinge_rc/Makefile)
Manche Leute kommen auf Ideen ... :-() Ralf
Hallo, Am Sat, 09 Oct 2004, Ralf Corsepius schrieb:
2 Portabilitätsfehler aus deinem Beispiel:
1. "for d in $(SUBDIRS)" ist nicht portabel.
Welche $SHELL kann 'for foo in a b c; do' nicht? Ausser vielleicht der csh? Ich hab hier mal mit der ash, pdksh und zsh getestet... -dnh -- Did I do something wrong today, or has the world always been like this and I've just been too wrapped up in myself to notice? -- Arthur Dent
On Sat, 2004-10-09 at 20:56, David Haller wrote:
Hallo,
Am Sat, 09 Oct 2004, Ralf Corsepius schrieb:
2 Portabilitätsfehler aus deinem Beispiel:
1. "for d in $(SUBDIRS)" ist nicht portabel.
Welche $SHELL kann 'for foo in a b c; do' nicht?
"for foo in a b c" sollten alle Shells beherrschen. Das Problem ist folgendes: SUBDIRS= for d in $(SUBDIRS); do Dieses expandiert zu for d in ; do eine Konstruktion, die von einigen Shells (z.B. die /bin/sh unter Solaris) nicht beherrscht wird. D.h. solange sichergestellt ist, dass $(SUBDIRS) nicht leer sein kann, ist alles in Ordnung, sobald aber $(SUBDIRS) auch leer sein kann, wird es problematisch. Ralf
Hallo, Am Sun, 10 Oct 2004, Ralf Corsepius schrieb:
On Sat, 2004-10-09 at 20:56, David Haller wrote:
Am Sat, 09 Oct 2004, Ralf Corsepius schrieb:
2 Portabilitätsfehler aus deinem Beispiel:
1. "for d in $(SUBDIRS)" ist nicht portabel.
Welche $SHELL kann 'for foo in a b c; do' nicht?
"for foo in a b c" sollten alle Shells beherrschen.
Das Problem ist folgendes: SUBDIRS= for d in $(SUBDIRS); do
Dieses expandiert zu for d in ; do
eine Konstruktion, die von einigen Shells (z.B. die /bin/sh unter Solaris) nicht beherrscht wird.
Achso. Klar. Meine bash steigt da auch mit nem syntax error aus. -dnh -- Als Waschmaschinenbesitzer sollte man jedenfalls darauf achten, dass man seiner Waschmaschine nur Socken schlechter Qualität gibt. Denn schlechte Ernährung führt zu was? Genau, Mangelerscheinungen. Frisch gebügelte Wäsche, direkt aus der Waschmaschine, das ist doch mal was. -- Oliver Schad
Hallo Ralf, hallo Leute, Am Samstag, 9. Oktober 2004 19:49 schrieb Ralf Corsepius:
On Sat, 2004-10-09 at 15:50, Christian Boltz wrote: [...] Es ist immer wieder interessant zu lesen, was manche Leute als allgemeingültig zu verkaufen versuchen ;-)
Tja, bisher hat sich keiner beklagt ;-)
2 Portabilitätsfehler aus deinem Beispiel:
1. "for d in $(SUBDIRS)" ist nicht portabel.
Hast Du ja schon mit David geklärt. Und da ich SUBDIRS=... händisch ins Makefile schreibe, ist das garantiert nie leer.
2. "make -C" ist nicht portabel.
Verrätst Du mir auch, wo das Problem liegt? (ein Link o. ä. genügt) Bisher kam nämlich auch hier keine Reklamation ;-) und in info make habe ich keine Hinweise auf Inkompatibilitäten gefunden. Dort steht nur ein Hinweis auf die Alternative "cd $subdir && make", allerdings ohne nähere Erklärung, warum man diese oder jene Variante nehmen sollte.
Recht interessant ist übrigens auch die Implementation von "make dist" auf Basis von CVS/Entries ;-) (fontlinge_rc/Makefile)
Manche Leute kommen auf Ideen ... :-()
Ja und? make dist ist ja etwas, was üblicherweise die Entwickler ausführen. Und da ist (bei den Fontlingen) sowohl das Betriebssystem Linux als auch das Vorhandensein von CVS/Entries gesichert. Warum sollten wir also das Paket "von Hand" schnüren (und dabei z. B. Tempfiles usw. versehentlich mit einpacken)? Sprich: make dist ist etwas, bei dem es mir egal ist, wenn es auf $OS != Linux nicht läuft ;-) Gruß Christian Boltz -- Ich weiss leider nicht was du damit meinst. Was ist ein IE? [Franz Preihs in suse-linux]
On Mon, 2004-10-11 at 01:11, Christian Boltz wrote:
Hallo Ralf, hallo Leute,
Am Samstag, 9. Oktober 2004 19:49 schrieb Ralf Corsepius:
On Sat, 2004-10-09 at 15:50, Christian Boltz wrote:
2 Portabilitätsfehler aus deinem Beispiel:
1. "for d in $(SUBDIRS)" ist nicht portabel.
Hast Du ja schon mit David geklärt. Und da ich SUBDIRS=... händisch ins Makefile schreibe, ist das garantiert nie leer. Irrtum, SUBDIRS ist eine Make-Variable. Diese können von der Kommandozeile aus überschrieben werden:
make SUBDIRS=
2. "make -C" ist nicht portabel.
Verrätst Du mir auch, wo das Problem liegt? (ein Link o. ä. genügt)
Es gibt makes, die -C nicht kennen (AFAIK, ist "make -C" GNU-make proprietär).
Bisher kam nämlich auch hier keine Reklamation ;-) und in info make habe ich keine Hinweise auf Inkompatibilitäten gefunden. Dort steht nur ein Hinweis auf die Alternative "cd $subdir && make", allerdings ohne nähere Erklärung, warum man diese oder jene Variante nehmen sollte. "make.info" beschreibt GNU-make.
"cd $subdir && make" wäre eine portable Alternative.
Recht interessant ist übrigens auch die Implementation von "make dist" auf Basis von CVS/Entries ;-) (fontlinge_rc/Makefile)
Manche Leute kommen auf Ideen ... :-()
Ja und? make dist ist ja etwas, was üblicherweise die Entwickler ausführen. Und da ist (bei den Fontlingen) sowohl das Betriebssystem Linux als auch das Vorhandensein von CVS/Entries gesichert.
"make dist" kann von jedermann, jederzeit an jeden Ort dieser Welt, auf jedem beliebigen OS, auf dem sich Dein Tarball auspacken lässt, ausgeführt werden. Dabei ist weder sichergestellt, dass CVS zur Verfügung steht, noch ist sichergestellt, noch dass "make dist" nur von Fontlinge-Entwicklern ausgeführt wird.
Warum sollten wir also das Paket "von Hand" schnüren (und dabei z. B. Tempfiles usw. versehentlich mit einpacken)? Siehe oben.
Das Problem an deinen Ansatz besteht darin, "Entwickler-umgebung" mit "Installierer-Umgebung", sowie "Releasemanagement" mit "make dist" zu vermischen/verwechseln.
Sprich: make dist ist etwas, bei dem es mir egal ist, wenn es auf $OS != Linux nicht läuft ;-) Wenn Du meinst, dass *das* ein guter Ansatz ist ... Ich bin es nicht.
Ralf
Hallo Ralf, hallo Leute, Am Montag, 11. Oktober 2004 06:09 schrieb Ralf Corsepius:
On Mon, 2004-10-11 at 01:11, Christian Boltz wrote:
Am Samstag, 9. Oktober 2004 19:49 schrieb Ralf Corsepius:
On Sat, 2004-10-09 at 15:50, Christian Boltz wrote:
2 Portabilitätsfehler aus deinem Beispiel:
1. "for d in $(SUBDIRS)" ist nicht portabel.
Hast Du ja schon mit David geklärt. Und da ich SUBDIRS=... händisch ins Makefile schreibe, ist das garantiert nie leer.
Irrtum, SUBDIRS ist eine Make-Variable. Diese können von der Kommandozeile aus überschrieben werden:
make SUBDIRS=
Wenn Du so willst... make RM="rm -rf /" clean Bin ich dann für die gelöschte Festplatte verantwortlich? ;-) (Sprich: ich verstehe Deinen Einwand, aber gegen die Dummheit der User bin ich nunmal ziemlich machtlos.)
2. "make -C" ist nicht portabel.
Verrätst Du mir auch, wo das Problem liegt? (ein Link o. ä. genügt)
Es gibt makes, die -C nicht kennen (AFAIK, ist "make -C" GNU-make proprietär).
Ah so. Gutes Argument.
Bisher kam nämlich auch hier keine Reklamation ;-) und in info make habe ich keine Hinweise auf Inkompatibilitäten gefunden. Dort steht nur ein Hinweis auf die Alternative "cd $subdir && make", allerdings ohne nähere Erklärung, warum man diese oder jene Variante nehmen sollte.
"make.info" beschreibt GNU-make.
"cd $subdir && make" wäre eine portable Alternative.
OK, ist ja nicht schwerer zu tippen. -C fliegt also bei Gelegenheit raus.
Recht interessant ist übrigens auch die Implementation von "make dist" auf Basis von CVS/Entries ;-) (fontlinge_rc/Makefile)
Manche Leute kommen auf Ideen ... :-()
Ja und? make dist ist ja etwas, was üblicherweise die Entwickler ausführen. Und da ist (bei den Fontlingen) sowohl das Betriebssystem Linux als auch das Vorhandensein von CVS/Entries gesichert.
"make dist" kann von jedermann, jederzeit an jeden Ort dieser Welt, auf jedem beliebigen OS, auf dem sich Dein Tarball auspacken lässt, ausgeführt werden.
Dabei ist weder sichergestellt, dass CVS zur Verfügung steht, noch ist sichergestellt, noch dass "make dist" nur von Fontlinge-Entwicklern ausgeführt wird.
Theoretisch schon, aber warum sollte jemand außer den Fontlinge-Entwicklern "make dist" ausführen wollen?
Warum sollten wir also das Paket "von Hand" schnüren (und dabei z. B. Tempfiles usw. versehentlich mit einpacken)?
Siehe oben.
Das Problem an deinen Ansatz besteht darin, "Entwickler-umgebung" mit "Installierer-Umgebung", sowie "Releasemanagement" mit "make dist" zu vermischen/verwechseln.
Installierer-Umgebung mische ich da eigentlich überhaupt nicht rein, denn ein User wird üblicherweise nicht "make dist" aufrufen. Wenn er es doch tut und keine CVS-Verzeichnisse hat - sein Pech.
Sprich: make dist ist etwas, bei dem es mir egal ist, wenn es auf $OS != Linux nicht läuft ;-)
Wenn Du meinst, dass *das* ein guter Ansatz ist ... Ich bin es nicht.
Es gibt möglicherweise bessere Ansätze für "make dist" (die mir noch nicht über den Weg gelaufen sind), aber auch deutlich schlechtere (z. B. das komplette Verzeichnis in den Tarball stecken). Bis ich etwas besseres finde, ist die Dateiliste aus CVS/Entries der geschickteste Weg, um z. B. Temp- und Testfiles aus dem Tarball rauszuhalten. Zur Kompatibilität: Das Vorhandensein von "cut" und "test -d" und "echo" sowie die Fähigkeit, Shellfunktionen auszuführen, sind wohl nicht allzu große Anforderungen, die auf fast jedem unixartigen OS vorhanden sein sollten. Und die CVS-Verzeichnisse bekommt man problemlos durch einen (auch anonymous) checkout. Trotzdem: ich baue im Makefile noch einen Test auf "leere Dateiliste" in make dist ein und schreib eine ordentliche Fehlermeldung raus ;-) Gruß Christian Boltz -- Unix: Alles ist ein File, und was kein File ist, hat sich gefaelligst als ein solches zu tarnen. [Wolfgang Weisselberg in linux-liste]
On Tue, 2004-10-12 at 20:49, Christian Boltz wrote:
Hallo Ralf, hallo Leute,
Am Montag, 11. Oktober 2004 06:09 schrieb Ralf Corsepius:
On Mon, 2004-10-11 at 01:11, Christian Boltz wrote:
Am Samstag, 9. Oktober 2004 19:49 schrieb Ralf Corsepius:
On Sat, 2004-10-09 at 15:50, Christian Boltz wrote:
2 Portabilitätsfehler aus deinem Beispiel:
1. "for d in $(SUBDIRS)" ist nicht portabel.
Hast Du ja schon mit David geklärt. Und da ich SUBDIRS=... händisch ins Makefile schreibe, ist das garantiert nie leer.
Irrtum, SUBDIRS ist eine Make-Variable. Diese können von der Kommandozeile aus überschrieben werden:
make SUBDIRS=
Wenn Du so willst...
make RM="rm -rf /" clean
Bin ich dann für die gelöschte Festplatte verantwortlich? ;-) Du hast gerade erkannt, warum es vorteilhaft sein kann, keine Shell/Make-Variablen zu verwenden und Dinge stattdessen hart zu codieren ;-)
(Sprich: ich verstehe Deinen Einwand, aber gegen die Dummheit der User bin ich nunmal ziemlich machtlos.)
ACK, aber ... Anders als "make RM=..." kann "make SUBDIRS=" durchaus sinnvoll sein oder aber implizit in Makefiles auftreten. Der erste Fall kann sinnvoll sein, um ein rekursives Makefile nicht-rekursiv aufzurufen. Der zweite Fall kann auftreten, wenn * man template-isierte Makefiles verwendet (Makefiles includieren Makefile-Fragmente; vgl. z.B. Make.rules im Linux-Kernel) * Makefiles "selbst-rekursiv" sind (eine Make-Regel innerhalb eines Makefiles ruft make mit dem selben Makefile auf). z.B.: debug: make SUBDIRS= CPPFLAGS=-DDEBUG * bei der Rekursionen Variablen verloren gehen oder überschrieben werden (Vgl. info make, Option -e, MAKEFLAGS). Tritt nicht selten auch als Seiteneffekt von Bugs in shells, make oder gar im OS auf.
Recht interessant ist übrigens auch die Implementation von "make dist" auf Basis von CVS/Entries ;-) (fontlinge_rc/Makefile)
Manche Leute kommen auf Ideen ... :-()
Ja und? make dist ist ja etwas, was üblicherweise die Entwickler ausführen. Und da ist (bei den Fontlingen) sowohl das Betriebssystem Linux als auch das Vorhandensein von CVS/Entries gesichert.
"make dist" kann von jedermann, jederzeit an jeden Ort dieser Welt, auf jedem beliebigen OS, auf dem sich Dein Tarball auspacken lässt, ausgeführt werden.
Dabei ist weder sichergestellt, dass CVS zur Verfügung steht, noch ist sichergestellt, noch dass "make dist" nur von Fontlinge-Entwicklern ausgeführt wird.
Theoretisch schon, aber warum sollte jemand außer den Fontlinge-Entwicklern "make dist" ausführen wollen? Z.B. weil jemand dein Paket in einer modifizierten Fassung vertreiben/verwenden will und Dein Paket in sein "Source Code Revision Control-System" (z.B. subversion) importiert hat.
Warum sollten wir also das Paket "von Hand" schnüren (und dabei z. B. Tempfiles usw. versehentlich mit einpacken)?
Siehe oben.
Das Problem an deinen Ansatz besteht darin, "Entwickler-umgebung" mit "Installierer-Umgebung", sowie "Releasemanagement" mit "make dist" zu vermischen/verwechseln.
Installierer-Umgebung mische ich da eigentlich überhaupt nicht rein, denn ein User wird üblicherweise nicht "make dist" aufrufen. Wenn er es doch tut und keine CVS-Verzeichnisse hat - sein Pech. Dir ist schon klar, dass CVS keinesfalls so breit verfügbar ist, wie Du es vermutlich annimmst? In vielen Installationen ist CVS nicht installiert oder aber wird von Firewalls geblockt.
Sprich: make dist ist etwas, bei dem es mir egal ist, wenn es auf $OS != Linux nicht läuft ;-)
Wenn Du meinst, dass *das* ein guter Ansatz ist ... Ich bin es nicht.
Es gibt möglicherweise bessere Ansätze für "make dist" (die mir noch nicht über den Weg gelaufen sind), aber auch deutlich schlechtere (z. B. das komplette Verzeichnis in den Tarball stecken). Verstehe ich nicht. Es hat seine Gründe warum automake's "make dist" so implementiert ist, wie es ist, und warum "make distcheck" noch deutlich restriktiver ist.
Warum nicht tar? Tar hat zwar auch seine Probleme, doch anders als CVS, ist tar praktisch überall verfügbar, relativ portabel, vergleichsweise schnell und setzt kein Netzwerk voraus. Doch warum nicht hart-codierte Dateinamen oder find oder ls nehmen, falls Dir hart-codierte Dateinamen als zu umständlich erscheinen?
Bis ich etwas besseres finde, ist die Dateiliste aus CVS/Entries der geschickteste Weg, um z. B. Temp- und Testfiles aus dem Tarball rauszuhalten. Du verwechselst Releasemanagement mit Entwicklung.
Wenn Du's unbedingt dynamisch machen willst, schreib Dir ein "cut-release"-Script, versteck Deine CVS-Magie darin, lass es die passenden Make-Regeln generieren die Makefile modifizieren. Dann würde nur noch der Releasemanager CVS benötigen, andere aber nicht.
Zur Kompatibilität: Das Vorhandensein von "cut" und "test -d" und "echo" sowie die Fähigkeit, Shellfunktionen auszuführen, sind wohl nicht allzu große Anforderungen, die auf fast jedem unixartigen OS vorhanden sein sollten. .. ist alles POSIX.
Und die CVS-Verzeichnisse bekommt man problemlos durch einen (auch anonymous) checkout. Siehe oben. CVS ist nicht Bestandteil von POSIX.
Ralf
Hallo Ralf, hallo Leute, Am Donnerstag, 14. Oktober 2004 05:06 schrieb Ralf Corsepius:
On Tue, 2004-10-12 at 20:49, Christian Boltz wrote:
Am Montag, 11. Oktober 2004 06:09 schrieb Ralf Corsepius:
On Mon, 2004-10-11 at 01:11, Christian Boltz wrote:
Am Samstag, 9. Oktober 2004 19:49 schrieb Ralf Corsepius:
On Sat, 2004-10-09 at 15:50, Christian Boltz wrote: [...] Wenn Du so willst...
make RM="rm -rf /" clean
Bin ich dann für die gelöschte Festplatte verantwortlich? ;-)
Du hast gerade erkannt, warum es vorteilhaft sein kann, keine Shell/Make-Variablen zu verwenden und Dinge stattdessen hart zu codieren ;-)
Und dabei versuche ich immer, möglichst wenig (wiederholt) hardcoded zu haben, weil das bei Änderungen immer so viel Arbeit ist.
(Sprich: ich verstehe Deinen Einwand, aber gegen die Dummheit der User bin ich nunmal ziemlich machtlos.)
ACK, aber ...
Anders als "make RM=..." kann "make SUBDIRS=" durchaus sinnvoll sein oder aber implizit in Makefiles auftreten.
Der erste Fall kann sinnvoll sein, um ein rekursives Makefile nicht-rekursiv aufzurufen.
So umfangreich sind die Fontlinge wieder nicht ;-) Da ein kompletter make-Lauf nur 3 Sekunden dauert, ist das Tippen von SUBDIRS= verhältnismäßig aufwändig ;-)
Der zweite Fall kann auftreten, wenn * man template-isierte Makefiles verwendet (Makefiles includieren Makefile-Fragmente; vgl. z.B. Make.rules im Linux-Kernel)
Du spielst auf das "Überschreiben" von Variablen an? So viel Überblick habe ich noch, dass das nicht passiert.
* Makefiles "selbst-rekursiv" sind (eine Make-Regel innerhalb eines Makefiles ruft make mit dem selben Makefile auf). z.B.: debug: make SUBDIRS= CPPFLAGS=-DDEBUG
Klar. Verwende ich aber auch nicht ;-)
* bei der Rekursionen Variablen verloren gehen oder überschrieben werden (Vgl. info make, Option -e, MAKEFLAGS). Tritt nicht selten auch als Seiteneffekt von Bugs in shells, make oder gar im OS auf.
... und deswegen gebe ich SUBDIRS nicht von einem Makefile zum anderen weiter. Brauche ich sowieso nur im Haupt-Makefile. ['make dist']
Theoretisch schon, aber warum sollte jemand außer den Fontlinge-Entwicklern "make dist" ausführen wollen?
Z.B. weil jemand dein Paket in einer modifizierten Fassung vertreiben/verwenden will und Dein Paket in sein "Source Code Revision Control-System" (z.B. subversion) importiert hat.
Dann kann er ja notfalls direkt mit tar das Paket zusammenstellen. Oder er fragt einfach nach und macht einen Vorschlag, wie make dist auch für ihn nutzbar sein könnte.
Das Problem an deinen Ansatz besteht darin, "Entwickler-umgebung" mit "Installierer-Umgebung", sowie "Releasemanagement" mit "make dist" zu vermischen/verwechseln.
Installierer-Umgebung mische ich da eigentlich überhaupt nicht rein, denn ein User wird üblicherweise nicht "make dist" aufrufen. Wenn er es doch tut und keine CVS-Verzeichnisse hat - sein Pech.
Dir ist schon klar, dass CVS keinesfalls so breit verfügbar ist, wie Du es vermutlich annimmst? In vielen Installationen ist CVS nicht installiert oder aber wird von Firewalls geblockt.
Ja, aber es ist mir auch klar, dass diejenigen, die 'make dist' verwenden, meist auch CVS verfügbar haben ;-)
Es gibt möglicherweise bessere Ansätze für "make dist" (die mir noch nicht über den Weg gelaufen sind), aber auch deutlich schlechtere (z. B. das komplette Verzeichnis in den Tarball stecken).
Verstehe ich nicht. Es hat seine Gründe warum automake's "make dist" so implementiert ist, wie es ist, und warum "make distcheck" noch deutlich restriktiver ist.
Warum nicht tar? Tar hat zwar auch seine Probleme, doch anders als CVS, ist tar praktisch überall verfügbar, relativ portabel, vergleichsweise schnell und setzt kein Netzwerk voraus.
Moment, Netzwerk setzt meine Lösung auch nicht voraus. Das Release wird auch per tar gepackt, nur wird eben die Dateiliste aus CVS/Entries zusammengestellt. Falls jemand CVS/Entries nicht hat, ginge vermutlich auch make DISTFILES="`find -type f`" DISTDIRS=`find -type d` dist Ohne diese Angabe wird CVS/Entries ausgewertet: DISTDIRS = $(shell function cvsdirlist { cut -d/ -f2 -s $$1/CVS/Entries | while read line ; do if test -d $$1/$$line ; then echo $$1/$$line ; cvsdirlist $$1/$$line ; fi ; done } ; test -f CVS/Entries && cvsdirlist . ) DISTFILES = $(shell function cvsfilelist { cut -d/ -f2 -s $$1/CVS/Entries| while read line ; do if test -d $$1/$$line ; then cvsfilelist $$1/$$line; else echo $$1/$$line; fi; done } ; test -f CVS/Entries && cvsfilelist . ) BTW: Wenn man den Code etwas netter formatiert, ist das Ganze sogar lesbar ;-) Einen Test auf "DISTDIRS leer" und "DISTFILES leer" habe ich inzwischen übrigens eingebaut.
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 ;-)
Bis ich etwas besseres finde, ist die Dateiliste aus CVS/Entries der geschickteste Weg, um z. B. Temp- und Testfiles aus dem Tarball rauszuhalten.
Du verwechselst Releasemanagement mit Entwicklung.
Wenn Du's unbedingt dynamisch machen willst, schreib Dir ein "cut-release"-Script, versteck Deine CVS-Magie darin, lass es die passenden Make-Regeln generieren die Makefile modifizieren.
Dann würde nur noch der Releasemanager CVS benötigen, andere aber nicht.
Ich denke drüber nach, aber mit folgender Abweichung: - es bleibt alles im Makefile. - falls CVS/Entries nicht existiert, könnte ein Fallback auf find stattfinden. (+ Hinweis auf STDERR) Gruß Christian Boltz -- Wir waren vor einiger Zeit schonmal "soweit fertig". Dann kam Gerald, fand 1000 Sachen Scheisse, hat 500 Sachen nicht begriffen und 250 falsch gemacht. :-)))))) [Ratti in fontlinge-devel]
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 ;-)
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. Schlieslich sorgt ein autoconf dafür, dass alles richtig kompiliert werden kann. So findet es alle relevanten Quelldateien und deren Header. Diese Liste der Dateien könnte man doch als Basis für ein 'dist' verwenden. Optional ist immer noch die CVS/Entries Methode eine gute Wahl. Ich meine dabei nur, weitere Dateien - wie Doku oder ähnliches. Lothar ---- My home: www.lollisoft.de ----------------------------- Lothar Behrens | Independent: lothar.behrens@gmx.de Rosmarinstr 3 | My public project: 40235 Düsseldorf | http://sourceforge.net/projects/lbdmf | -> Need comments, please visit :-)
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
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 ? (+ einer Liste der Metadateien)
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. 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 -r *.bak Parameter format not correct - Error! Unable to remove file 'lbDB.bak' make[1]: *** [lbDB.dll] Error 8 Der Verursachende Fehler ist mir bekannt. Ich erzeuge schreibgeschützte bak dateien, wenn ich Sourcen verändere. AE kann das trotz eines Schreibschutzes - Es nimmt Ihn kurz raus. Aber warum kann make den Befehl nicht genauso ausführen wie von der Kommandozeile ? Ich Weiß, dies ist eine Linux Liste, aber ich arbeite halt mal mit GNU make unter Windows. Danke Lothar ---- My home: www.lollisoft.de ----------------------------- Lothar Behrens | Independent: lothar.behrens@gmx.de Rosmarinstr 3 | My public project: 40235 Düsseldorf | http://sourceforge.net/projects/lbdmf | -> Need comments, please visit :-)
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 ? (+ einer Liste der Metadateien)
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. 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 -r *.bak Parameter format not correct - Error! Unable to remove file 'lbDB.bak' make[1]: *** [lbDB.dll] Error 8 Der Verursachende Fehler ist mir bekannt. Ich erzeuge schreibgeschützte bak dateien, wenn ich Sourcen verändere. AE kann das trotz eines Schreibschutzes - Es nimmt Ihn kurz raus. Aber warum kann make den Befehl nicht genauso ausführen wie von der Kommandozeile ? Ich Weiß, dies ist eine Linux Liste, aber ich arbeite halt mal mit GNU make unter Windows. Danke Lothar ---- My home: www.lollisoft.de ----------------------------- Lothar Behrens | Independent: lothar.behrens@gmx.de Rosmarinstr 3 | My public project: 40235 Düsseldorf | http://sourceforge.net/projects/lbdmf | -> Need comments, please visit :-)
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. Ralf
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) 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. Ich werde trotz Multiplatform Framework für Windows und Linux wieder verschiedene Mechanismen haben, um meine Quellen zu übersetzen. Ich werde daher weiter mit meiner Lösung arbeiten. Vorteile: 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. MKMK ist frei und könnte um das schreiben der automake input Dateien erweitert werden. Hiermit würde der unerfahrene User die möglichkeit haben, unter Linux einfach neue automake projekte aufzusetzen. Vielleicht gibt es dafür Interresse. Weiter würde ich mich freuen, wenn sich ein paar Tester finden, denn Vier Augen finden bekanntlich mehr Fehler :-) Lothar
Ralf
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
---- My home: www.lollisoft.de ----------------------------- Lothar Behrens | Independent: lothar.behrens@gmx.de Rosmarinstr 3 | My public project: 40235 Düsseldorf | http://sourceforge.net/projects/lbdmf | -> Need comments, please visit :-)
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
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.
Unter Windows verwende ich zwar das GNU make von Cygwin, aber meinen Watcom Compiler und dessen Linker. Ein vollständiges Cygnu make ginge natürlich auch. Müsste ich mal testen. Nur denke ich, wenn ich einen für Windows ausgelegten Compiler verwende, erspare ich mir die Posix Emulation der Cygnu Suite.
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.
Also automake.ams und Watcom Compiler ist nicht so schön ? Oder garnicht möglich ?
Allerdings sollte dir bewusst sein, dass diese Infrastruktur kleiner ist, als es viele WIN/DOS-Pakete sind.
Wie groß ist Cygnu/Cygwin in der minimalen version zum Compillieren ? Das Watcom Packet ist etwa 60 MB als Installer. Microsoft Visual C++ ist sicher noch größer und kommerziell. Und die Freien Konsolen Tools haben da ein Lizenzproblem mit LGPL ?
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, ...
Jaaaa :-) make configure; make; make install ist unter Linux sicher der Standart. Ich sollte auch an einer solchen Version arbeiten, da ich auch Microsoft Visual C++ mit einem IDE Projekt unterstütze. Jedem das seine, ich mag halt einfach überall ein einfaches 'make'.
... "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 ...
Meins erfüllt meine Anforderungen für Windows und Linux. Mir reicht das erstmal. Hilfe für automake.ams nehme ich gerne an :-)
... die meisten dieser Tools überleben nicht sehr lange.
... let the bazaar vote ...
URL?
www.lollisoft.de verweist auf mein Projekt... Lothar ---- My home: www.lollisoft.de ----------------------------- Lothar Behrens | Independent: lothar.behrens@gmx.de Rosmarinstr 3 | My public project: 40235 Düsseldorf | http://sourceforge.net/projects/lbdmf | -> Need comments, please visit :-)
On 22.10.2004 20:30, Lothar Behrens wrote:
make configure; make; make install ist unter Linux sicher der Standart.
_Die_ Standart, nicht _der_ Standart! Oder vielleicht der Standard?!? siehe auch http://de.wikipedia.org/wiki/Standart! MfG & SCNR, Oliver
On 22.10.2004 20:30, Lothar Behrens wrote:
make configure; make; make install ist unter Linux sicher der Standart.
_Die_ Standart, nicht _der_ Standart! Oder vielleicht der Standard?!?
siehe auch http://de.wikipedia.org/wiki/Standart!
Öööö - Naja :-( Ich muss mich kaufen Tüte Deutsch :-) Kapiert: Die Standart wie die Art des Stehens. Lothar PS: Musste nicht nachschauen - was ein Buchstabe bewirkt.
MfG & SCNR,
Oliver
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verf|gbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com
---- My home: www.lollisoft.de ----------------------------- Lothar Behrens | Independent: lothar.behrens@gmx.de Rosmarinstr 3 | My public project: 40235 Düsseldorf | http://sourceforge.net/projects/lbdmf | -> Need comments, please visit :-)
participants (6)
-
Andre Heine -
Christian Boltz -
David Haller -
Lothar Behrens -
Oliver Baum -
Ralf Corsepius