VDR war mal so schoen einfach zu bauen, man nehme den Source Code, stelle alle Plugins unter PLUGINS/src Verzeichnis und baue. Und dann stellt man die Libs einfach dahin wo es fuer die jeweilige Distri Sinn macht.
Bis irgendwann man jemand auf die glorreiche Idee kam dieses System zu aendern und nun hat man wenigstens jede Menge Grund fuer neue Diskussionen und wundert sich dass manches doch nicht so einfach geht ..
SCNR
Ach ja, die gute alte Zeit... 
Klaus
Ach ja, die gute alte Zeit...
War das nicht die mit den VHS-Kassetten...? 
Mit Make.config, PLGCFG und "make install" lässt sich doch alles abbilden, auch die gute, alte Zeit. Natürlich muss man etwas Geduld mitbringen, bis es in die Plugins eingeflossen ist...
"make install" finde ich ehrlich gesagt wesentlich besser als manuelles Kopieren.
Lars.
Ich finde allein schon "Sub-Plugins" eine schlechte Idee...
Was kommt als nächstes? "Sub-Sub-Plugins"?
Klaus
Sub-plugins gefaellt mir auch nicht, aber gemeinsame Libs fuer Plugins waeren durchaus denkbar ...
"make install" finde ich ehrlich gesagt wesentlich besser als manuelles Kopieren.
Du willst mir doch nicht erklaeren dass irgendein Distributor das manuell gemacht hat ?
Bei mir heisst das
instvdr
das ist noch kuerzer
Du willst mir doch nicht erklaeren dass irgendein Distributor das manuell gemacht hat ?
Bei mir heisst das
instvdr
das ist noch kuerzer
Der Package-Build-Mechanismus von Debian führt "make install" implizit aus. Nur wenn es kein Install-Target gibt, dann muss man was tun. Deshalb möchte mini73 gerne "make install".
Bei einem vernünftigen Makefile sieht der komplette Buildscript von Debian so aus:
#!/usr/bin/make -f
%:
dh $@Gerald
Sub-plugins gefaellt mir auch nicht, aber gemeinsame Libs fuer Plugins waeren durchaus denkbar ...
Hab ich schon versucht, wurde aber abgeschmettert, weil es dann Abhängigkeiten zwischen Plugins geben soll... Viel Erfolg...
Du willst mir doch nicht erklaeren dass irgendein Distributor das manuell gemacht hat ?
Bei mir heisst das
instvdr
das ist noch kuerzer
Klar, dann ändert sich jetzt eben der Inhalt von instvdr...
Lars.
Bei einem vernünftigen Makefile sieht der komplette Buildscript von Debian so aus:
Und mit Debug-Symbolen dann (entsprechende Package-Definition in control vorausgesetzt):
#!/usr/bin/make -f
.PHONY: override_dh_strip override_dh_auto_install
override_dh_strip:
dh_strip --dbg-package=vdr-plugin-avahi4vdr-dbg
override_dh_auto_install:
dh_auto_install --destdir=debian/vdr-plugin-avahi4vdr
%:
dh $@Lars.
Hallo,
ganz schöner Glaubenskrieg hier. Dabei zieht mein Patch überhaupt nur dann, wenn die Plugins eben nicht bei einer Installation in den Rest des Filesystems.
Sie sorgt nur dafür das bei Bedarf eben alle *.so Dateien im PLUGINS/lib Verzeichnis landen. Die LCLBLD Methode wird IMHO sowieso kein Distributor nutzen.
Wenn man diesen Weg wählt, dann muss man sowieso danach selbst dafür sorgen das die *.so Dateien an ihren eigentlichen Zielort gelangen. Zumindest ist
das bei mir so und meiner Meinung nach gibt es LCLBLD überhaupt nur noch für solche Leute wie mich.
Es ist ja nett darüber zu diskutieren was Pluginautoren hätten tun sollen, oder nicht. Dadurch das nicht von vorn herein entsprechende Regeln aufgestellt
wurden, ist es eben soweit gekommen. Klaus hat selber schon bemerkt, dass er besser Richtlinien oder sogar eine Zertifizierung für Plugins hätte einführen
sollen.
Das nutzt jetzt nichts mehr! Das jetzt wieder einzufangen ist so, als würde man versuchen ein Foto aus dem Internet zu löschen. Warum? Weil es zwar viele
Plugins gibt, aber kaum noch Maintainer. Anders ausgedrückt. Warum nutzen alle Windows? Weil sie ihre steinalten Applikationen aus WIndows 95 Zeiten auch
heute noch betreiben können und wollen. MS ist das auch nicht recht, aber wenn man seine Nutzer nicht verärgern will, dann muss man eben kompatibel
bleiben. Warum verkauft Apple wohl iPhones wie blöd? Weil die Leute es einfach haben und keinen Ärger haben wollen.
Wenn dieser Patch überflüssig ist, warum gibt es dann trotzdem den Kompatibilitätsmodus für alte Makefiles? Warum gibt es LCLBLD? Ebenfalls deswegen.
Wenn das mit der 2.1 entfernt werden sollte, dann bricht hier derselbe Shitstorm doch wieder los. Im Moment sind die Leute doch nur ruhig, weil sich alle
Plugins doch noch mit den alten Makefiles bauen lassen. Wie viele Leute versuchen es denn überhaupt mal, einen kompletten VDR nur mit neuen Makefiles
zu bauen? Distributoren mal ausgenommen.
Die reine Lehre die hier von einigen fast fanatisch vertreten wird, ist entweder Realitätsfremd oder einfach egoistisch. Es ist einfach über etwas zu urteilen,
wenn man selbst nicht darauf angewiesen ist.
Duck. 
Gruss, Thomas
... meiner Meinung nach gibt es LCLBLD überhaupt nur noch für solche Leute wie mich.
... Warum gibt es LCLBLD? Ebenfalls deswegen.
Wenn das mit der 2.1 entfernt werden sollte, dann bricht hier derselbe Shitstorm doch wieder los.
LCLBLD gibt es schon auch wegen mir ;-). Und deshalb wird es auch nicht verschwinden.
Plugins, die damit nicht funktionieren, brauch' ich nicht.
Klaus
ganz schöner Glaubenskrieg hier. Dabei zieht mein Patch überhaupt nur dann, wenn die Plugins eben nicht bei einer Installation in den Rest des Filesystems.
Sie sorgt nur dafür das bei Bedarf eben alle *.so Dateien im PLUGINS/lib Verzeichnis landen. Die LCLBLD Methode wird IMHO sowieso kein Distributor nutzen.
Wenn man diesen Weg wählt, dann muss man sowieso danach selbst dafür sorgen das die *.so Dateien an ihren eigentlichen Zielort gelangen. Zumindest ist
das bei mir so und meiner Meinung nach gibt es LCLBLD überhaupt nur noch für solche Leute wie mich.
Oh, Mann, geht es nun um das UPnP-Plugin oder nicht? Da verliert man echt leicht die Uebersicht... Wie auch immer, das Plugin hat eine Homepage auf vdr-developer, einen Autor der nun mal gerade nach einer Zeit in der er das Plugin weit voran gebracht hat, momentan etwas weniger Zeit dafuer hat, jedenfalls liegt schon seit geraumer Zeit ein Patch vor, und ich bin mir da ziemlich sicher, der Autor wird da schon was daraus machen, man sollte ihm nur die Zeit lassen. Ich wuerde schon sagen, dass es mir bei dem Patch gelungen ist, das Plugin mit seinen "Oh Gott, nicht doch, Subplugins" VDR >= 1.7.36 "konform" zu machen (was das Verhalten seines Makefiles, bzw. Aufrufen der typischen Targets in den typischen Szenarien angeht, also make, make install und das Jonglieren mit LCLBLD, und geht darueber hinaus). Deswegen verstehe ich nicht wirklich warum da in diesem Thread so pauschal geurteilt wird, mal ob Subplugins eine Existenzberechtigung haben (hat Methodus mal in einem der spezifischen UPnP-Threads erlaeutert, da waren einige der Teilnehmer in diesem Thread auch beteiligt an der Diskussion), oder das "Distribution XY will das so", usw...
Ciao, Lucian
Moin!
Ich hab nichts gegen Subplugins. Ich habe nur etwas gegen den Vorschlag, sie auch mit libvdr- anfangen zu lassen, weil dann der plugin-loader unter Debian nicht mehr funktionieren würde.
Hat upnp denn mit einem alten vdr alles notwendige in das PLUGINS/lib-Verzeichnis kopiert? Was war denn damals anders?
Lars.
Hat upnp denn mit einem alten vdr alles notwendige in das PLUGINS/lib-Verzeichnis kopiert? Was war denn damals anders?
Das weiss ich allerdings nicht, ich bin auf das Plugin erst wieder aufmerksam geworden, vor etwa 5 Monaten nachdem Methodus wieder anfing, daran zu arbeiten, und habe ihm vor etwa 4 Monaten die Makefiles etwas umgekrempelt, damit er mit den Subplugins flexibler ist und leichter erweitern kann. Zumindest seither würde ich sagen, daß das ging, und nach meinem aktuellem Patch habe ich es explizit mit LCLBLD getestet (was ich selber aber nicht nutze, ich installiere immer, und das auch nicht an der Paketverwaltung vorbei). Von daher sollten die Vorgaben der "Makefile-Schnittstelle" erfüllt sein...
Hier mal eine Version für das Setup-Plugin
Mfg
@ Copperhead
Leider komm ich mit deiner Version vom Makefile für xmltv2vdr nicht klar.
Mit dem beigefügten Makefile klappt es bei mir.
Und was hindert sie daran, der Namenskonvention zu folgen und z.B. "libvdr-upnp-dvb-profiler.so.1.0.0-1.6.0" zu benutzen?
Da bin ich doch beim finalen Überarbeiten der PLUGINS.html für die Version 2.0 auf folgendes gestoßen:
If a plugin needs library files of its own, it can copy them to the lib directory following
the naming convention lib<name>-<library>.so.0.0.1, where <name> is the name of the
plugin, and <library> identifies the plugin's additional library.
If the plugin hello would require the two additional libraries foo and bar, the names would be
libhello-foo.so.0.0.1
libhello-bar.so.0.0.1
Meine Aussage, alle Plugin-Libraries müssten der Konvention "libvdr-..." folgen, ist damit natürlich Quatsch.
So gesehen müsste ich also gerechterweise dem Vorschlag von hier folgend zumindest die Wildcard-Änderung von "libvdr-*.so" nach "lib*.so" übernehmen.
Und da PLUGINS.html streng genommen keine Aussage darüber macht, wo eine Library entstehen soll, die das Plugin selber braucht, muß ich wohl auch die "find"-Änderung übernehmen.
Allerdings würde ich es so machen...
--- Makefile 2013/02/24 10:40:23 2.53
+++ Makefile 2013/03/11 13:00:26
@@ -220,7 +220,7 @@
INCLUDES="-I$(CWD)/include"\
$(MAKE) --no-print-directory -C "$(PLUGINDIR)/src/$$i" VDRDIR="$(CWD)" || failed="$$failed $$i";\
if [ -n "$(LCLBLD)" ] ; then\
- (cd $(PLUGINDIR)/src/$$i; for l in libvdr-*.so; do install $$l $(LIBDIR)/$$l.$(APIVERSION); done);\
+ (cd $(PLUGINDIR)/src/$$i; for l in `find -name lib-*.so`; do install $$l $(LIBDIR)/`basename $$l`.$(APIVERSION); done);\
if [ -d $(PLUGINDIR)/src/$$i/po ]; then\
for l in `ls $(PLUGINDIR)/src/$$i/po/*.mo`; do\
install -D -m644 $$l $(LOCDIR)/`basename $$l | cut -d. -f1`/LC_MESSAGES/vdr-$$i.mo;\
...da mir das mit dem "bash" im Original-Patch nicht gefällt. Die Option "-follow" ist laut "man find" "deprecated", und außerdem sollten an dieser Stelle eigentlich keine Symlinks notwendig sein.
Da das nur das VDR-Makefile selber betrifft, könnte ich das noch für die Version 2.0.0 machen.
Soll ich?
Wenn ja, kann den Patch bitte jemand testen? Ich verwende keine solchen Plugins und habe daher keine passende Testumgebung.
Klaus
....
- (cd $(PLUGINDIR)/src/$$i; for l in libvdr-*.so; do install $$l $(LIBDIR)/$$l.$(APIVERSION); done);\
+ (cd $(PLUGINDIR)/src/$$i; for l in `find -name lib-*.so`; do install $$l $(LIBDIR)/`basename $$l`.$(APIVERSION); done);\
...
ich denke mal das "-" hinter lib sollte weg ?!
+ (cd $(PLUGINDIR)/src/$$i; for l in `find -name lib*.so`; do install $$l $(LIBDIR)/`basename $$l`.$(APIVERSION); done);\
sieht fuer mich besser aus ...
Das find im Patch sollte wohl
Zitat`find -name lib*.so`
und nicht
Zitat`find -name lib-*.so`
heißen.
[Edit]Mist - ein paar Sekunden zu langsam ;)[/Edit]
ich denke mal das "-" hinter lib sollte weg ?!
+ (cd $(PLUGINDIR)/src/$$i; for l in `find -name lib*.so`; do install $$l $(LIBDIR)/`basename $$l`.$(APIVERSION); done);\
sieht fuer mich besser aus ...
Stimmt natürlich.
Ich werte das auch gleich mal als ACK (ebenso von "schmirl").
Klaus
Da das wohl schon einige Zeit so in der Doku stehen dürfte, macht es Sinn das auch im Makefile so umzusetzen. Also von meiner Seite her gerne auch ein ACK.
Zusätzlicher Vorteil wäre, dass eventuell in Plugin-Makefiles bereits integrierte Sonderbehandlung für "LCLBLD" dann wieder rauskönnte...
Moin!
Wäre es nicht besser, das Pattern im zweiten find so zu formulieren, dass es zu PLUGINS.html passt?
Also "lib$$i-*.so".
Lars.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!