Hallo zusammen,
ZitatP.P.S.:
So groß, wie das Geschrei nach der Umstellung war, verstehe ich nicht, dass hier nicht viel mehr Leute versuch Copperhead zu unterstützen. Ich sehe es schon kommen: irgendwann kommt eine 1.7.36, und das große Heulen setzt wieder ein.
dann will ich dem Aufruf mal Folge leisten... 
Ich verfolge die Diskussion schon seit Weihnachten (also praktisch vom ersten Tag an) und habe seidem versucht, auf Basis eurer Gedanken mit meiner eigenen Installation ein wenig voranzukommen. Grundsätzlich stimme ich Klaus zu, dass das Make-System überschaubar gehalten sein sollte. Deshalb bin ich kein Fan von noch mehr Make-Include-Dateien und im Grunde genommen auch nicht von etlichen Schaltern (LCLBLD etc.).
Gestern habe ich auf Basis von "vdr-1.7.35-makefilefix6.diff" endlich eine Lösung gefunden, die zumindest bei mir schon ganz ansehnliche Ergebnisse liefert. Ihr findet alle Makefiles meines VDR-Trees als Attachment, damit man sich das Zusammenspiel mal ansehen kann:
Im Prinzip habe ich – bis auf softhddevice und xineliboutput, die mir für den Moment zu kompliziert waren – bei allen Plugins das Makefile von "hello" genommen und passend "aufgebohrt", sprich: die Teile aus dem "alten" Makefile eingefügt, die noch rein mussten. Auf die Details von "clean" und "dist" habe ich allerdings nicht ganz so viel Sorgfalt verwendet, die können also noch unvollständig adaptiert sein.
Grundsätzlich lässt sich mit diesem Satz der VDR aus seinem Source-Verzeichnis heraus per "make" und "sudo make install" übersetzen und installieren. Plugins mit neuen Makefiles legen bei "make" ihre Ergebnisse in ihrem eigenen Verzeichnisbaum ab, alte Makefiles wie gewohnt in "./locale" und "./PLUGINS/lib". Das folgende "make install" sammelt die Ergebnisse auf, indem es die Dateien neuer Makefiles aus den Plugin-Verzeichnissen in die Installationsverzeichnisse kopiert, während es für alte die Dateien aus "./locale" und "./PLUGINS/lib" kopiert. Dies hat u.a. den angenehmen Nebeneffekt, dass sich z.B. das Binary "markad" (aus dem "command"-Verzeichnis) auch gleich richtig mitinstalliert.
Abweichend vom bisherigen Prinzip muss man allerdings auch "make install" aufrufen, wenn die Plugins ihre Ergebnisse in "./locale" und "./PLUGINS/lib" ablegen sollen. Aber wäre das ein Problem – außer dass es anders ist als bisher, dafür aber konsequent ohne Fummeleien und problematischen Sonderbehandlungen innerhalb des Makefiles?
Prinzipiell sollten sich Plugins mit neuem Makefile auch in ihren Verzeichnissen übersetzen und von dort aus installieren lassen, sofern sie "vdr.pc" finden. Leider greifen sie bei mir ins Leere, aber vielleicht hat ja jemand den richtigen Kniff, wie dazu die folgende Zeile geändert werden müsste:
PKGCFG = $(if $(VDRDIR),$(shell pkg-config --variable=$(1) $(VDRDIR)/vdr.pc),$(shell pkg-config --variable=$(1) vdr || pkg-config --variable=$(1) ../../../vdr.pc))Auch wenn ich das nur mit einem Plugin exemplarisch getestet habe, sollte das Ganze auch außerhalb des VDR-Baums funktionieren, sofern man dem Makefile beim Aufruf das VDRDIR explizit mit übergibt, sodass "vdr.pc" gefunden werden kann. Denn mehr wird auch beim "normalen" Build nicht übergeben.
Der folgende Codeteil wäre im VDR-Makefile dann prinzipiell verzichtbar, zumindest wenn man die implizite Installation innerhalb des VDR-Baums (dessen sichere Erkennung nicht trivial ist) nicht benötigt:
if [ "$(LIBDIR)" = "$(CWD)/PLUGINS/lib" ] && [ "$(LOCDIR)" = "$(CWD)/locale" ]; then\
target="install";\
fi;\Mir ist schon klar, dass ich mit solchen Gedanken recht spät dran bin – zumal als "Neuer" im Thread. Aber vielleicht noch nicht zu spät...?
Danke an dieser Stelle an alle, die sich so rührig um den VDR kümmern. Was täte ich nur ohne dieses geniale Teil? 
Viele Grüße
Stefan
