Mailinglist Archive: opensuse-programming-de (187 mails)

[Ralf Corsepius <rc040203@xxxxxxxxxx>]

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