Re: Make Problem

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



-- 
Um die Liste abzubestellen, schicken Sie eine Mail an:
    [email protected]
Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken
Sie eine Mail an: [email protected]