Re: Make Problem

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]


-- 
Um die Liste abzubestellen, schicken Sie eine Mail an:
    suse-programming-unsubscribe-IBi9RG/[email protected]
Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken
Sie eine Mail an: suse-programming-help-IBi9RG/[email protected]