Habe mal aktuelles Makefile für 1.7.36 und softhddevice gebaut.
Bevor ich es commite, wären Tests nicht schlecht. Besonders die Distributionsbauer.
Aufruf ist:
make ALSA=0|1 OSS=0|1 VDPAU=0|1 VAAPI=0|1 SCREENSAVER=0|1 SWRESAMPLE=0|1
Rest erfolgt über pkg-config oder Autoerkennung.
Johns
Edit: neue Version http://projects.vdr-developer.…ts/download/1213/Makefile
Stimmt die CFLAGS der immer gebrauchen libs ist verloren gegangen.
ldd libvdr-softhddevice.so | fgrep avcodec
libavcodec.so.53 => /usr/lib64/libavcodec.so.53 (0x00007f156ac3c000)avcodec habe ich und der pkg-config für libavcodec ist drin. Den Rest von ffmpeg brauche ich nicht,
bzw. libswresample ist optional und configurierbar.
Neue Version: http://projects.vdr-developer.…ts/download/1213/Makefile
Johns
Im alten war LIBS nach den O-Files.
--- Makefile.old 2013-01-28 20:00:22.211902101 +0100
+++ Makefile 2013-01-28 20:00:58.514899883 +0100
@@ -164,7 +164,7 @@
$(OBJS): Makefile
$(SOFILE): $(OBJS)
- $(CXX) $(CXXFLAGS) $(LDFLAGS) $(LIBS) -shared $(OBJS) -o $@
+ $(CXX) $(CXXFLAGS) $(LDFLAGS) -shared $(OBJS) $(LIBS) -o $@
install-lib: $(SOFILE)
install -D $^ $(DESTDIR)$(LIBDIR)/$^.$(APIVERSION)Vielleicht hast einen Single Pass Linker.
Johns
Moin,
ich versuche gerade meine PLugins mit vdr-1.7.36 und den neuen Makefiles zu compilieren.
Mit dem neuen Makefile von johns wird softhddevice compiliert.
Vdr arbeitet auch mit dem uebersetzten Plugin, nur wenn ich die Plugin/Einstellungen zu softhddvice oeffne, schmiert der vdr ab.
Das Ganze habe ich uebrigens auch mit dem neuen Makefile zu graphtft.
Weiss jemand was hier falsch laeuft ?
Ich baue den vdr und die plugins mit LCLBLD.
Danke
Noch ein Hinweis..> Benutze ich die alten Makefiles habe ich diesen Fehler nicht. Dann kann ich ganz normal die Einstellungen zu den Plugins aendern.
Hallo,
hat jemand schon die Makefiles von streamdev umgestellt?
Moin,
kommt es nur mir so vor oder wird das Wirrwarr immer größer?? Da sich ja auch vom vdr 1.7.34 bis zum 1.7.36 noch einiges geändert hat, sind einige der Makefile Patches schon wieder nicht mehr up to date 
Des weiteren habe ich den Eindruck, dass viele neue Makefiles noch buggy sind, hier wird mal ein Problemchen gemeldet, dort wird mal gejammert und das ganze versackt dann wieder...koordiniertes Bugfixing ist hier nicht zu erkennen. Das ist doch alles Bullshit!
Der Effekt ist, dass aktuell anscheinend keiner mehr irgendwas macht. Wer setzt denn VDR 1.7.36 produktiv ein?? Da ich zum 1.7.34 bzw. 1.7.36 aufgrund der Mindestvoraussetzung meines Skins gezwungen bin, habe ich mich mal durchgewurschtelt und für mich eine laufende Umgebung mit 1.7.36 zusammengezimmert...aber Rund ist das keineswegs. Tester für nOpacity habe ich auch so gut wie keine mehr, weil sich eben keiner den Stress des Upgrades antun will...mich nervt das ehrlich gesagt ziemlich an!
Copperhead: was ist denn nun mit deinem Versprechen, dich darum zu kümmern? Hast du die Lust verloren, als du gemerkt hast, was für eine Arbeit das ist? Du hast wohl den besten Überblick über die Änderungen und hast sie auch angezettelt...also lass deinen Aussagen auch mal Taten folgen und stelle doch mal zumindest für die 30 - 50 wichtigsten Plugins korrekte Makefiles für den VDR 1.7.36 an einer zentralen Stelle zur Verfügung. Wenn es schon neue Makefiles gibt, dann sollten die von dir nochmal geprüft werden, das Vorhandensein kann dann auch in dieser Liste vermerkt werden...
Es kann dich nicht sein, solch eine folgenschwere Änderung durchzuführen und dann den ganzen Dreck einfach liegen zu lassen!
Cheers Louis
Ich setze die 1.7.36 seit gestern produktiv ein (mit graphtft und Mainmenuhooks-Patches). Ich baue aber auch mit "make LCLBLD=1" und kopiere mit dann meine Libs, Configs und Bin Datei hin, wo ich sie hinhaben will. Die Makefiles hab ich nicht angefasst. Das lief alles durch bis auf ein paar Hinweise, dass manche Makefile noch angepasst werden müssen.
skinnopacity hab ich auch mal installiert (git). Nutze aber derzeit noch anthra-OSE. Aber wenn am Skin mal was gestest werden muss, sag bescheid.
Hallo,
hat jemand schon die Makefiles von streamdev umgestellt?
Habs jetzt mal selber gemacht. Muss aber noch testen
Copperhead: was ist denn nun mit deinem Versprechen, dich darum zu kümmern? Hast du die Lust verloren, als du gemerkt hast, was für eine Arbeit das ist? Du hast wohl den besten Überblick über die Änderungen und hast sie auch angezettelt...also lass deinen Aussagen auch mal Taten folgen und stelle doch mal zumindest für die 30 - 50 wichtigsten Plugins korrekte Makefiles für den VDR 1.7.36 an einer zentralen Stelle zur Verfügung. Wenn es schon neue Makefiles gibt, dann sollten die von dir nochmal geprüft werden, das Vorhandensein kann dann auch in dieser Liste vermerkt werden...
Es kann dich nicht sein, solch eine folgenschwere Änderung durchzuführen und dann den ganzen Dreck einfach liegen zu lassen!
Eine einheitlichere Lösung wäre wohl besser gewesen, so das z.B. die eigentliche Makefile-Logik in einer zentralen Datei definiert wird, und die Plugin-Makefiles sich auf das Plugin-Spezifische beschränken: Name des Plugins, eventuell explizite Liste der Sourcen, der Objekte, natürliche eigene Abhängigkeiten und Checks dafür, eigene Targets nach einem geregeltem Schema die vom Zentralen Makefile noch bei Bedarf mit "ge-hookt" werden, gegebennefallös auch eigene Flags. Das führt dazu, das das alles letztendlich durch eine Datei gesteurt wird, die im VDR-Sourcenverzeichnis liegt, oder mit den Headern mit installiert wird, und somit VDR-Versionsgebunden und unter Klaus' Kontrolle liegt, und die einzelnen Makefile-Plugins sehr einfach gehalten werden können, und Änderungen am zentralen Makefile "von selbst" mitmachen, sofern sich nichts an die vereinbarte Schnittstelle der Variablenzuweisung und Targets-Verknüpfung ändert. Natürlich sollte man in so einem Fall gemäss dem KISS-Prinzip alte VDR-Versionen einfach bloß mit einem zusätzlichen "alten" Makefile unterstützen, wenn überhaupt gewünscht wird. Ein Beispiel dieses Modells: die neuen "Subplugin"-Makefiles die das UPnP-Plugin seit etwa 3 Monaten hat, erlauben sowohl das Bauen aller "Subplugins" wenn man das Hauptplugin baut, als auch das Einzelne Bauen eines Subplugins im entsprechenden Unterverzeichnis (ähnlich wie wir es bei VDR und seinen Plugins haben wollen), das kann man sich in den Sourcen mal angucken, dort heissen die Subplugins zwar "Plugins" und liegen in einem dementsrechend genannten Verzeichnis, aber sie alle "rufen" Makefile.plugins auf, welches das Ganze nur für die Plugins nur kontrolliert, und dessen Targts aus dem zentralen Makefile aufgerufen werden können, aber auch einzeln aus den Subplugins.
Lucian
Das wäre aber wieder eine extreme Sonderlösung. Zumindest meiner Meinung nach also alles andere als KISS. Noch einfacher wie jetzt kann man die Plugin-Makefiles kaum noch gestalten. Und wenn alles über eine zentrale Logik gequetscht werden muss, dann wird das ganze auch noch extrem unflexibel. Was ist z.B. mit Sourcen die mehrere Plugins enthalten? Beispiel stremdev oder epgsearch.
Moin!
Eigentlich sollen die alten Makefiles doch noch funktionieren, oder? Dann nimm doch einfach erst mal die, bis sich ein entsprechender Maintainer gefunden hat.
Und alle Plugins, für die sich niemand mehr verantwortlich fühlt, einfach ignorieren oder selbst machen. Anders wird das nichts.
Ich sehe auch nicht, dass es jemals etwas wird, dass sich "die Community" um die verwaisten Plugins kümmert. Entweder findet sich jemand berufen und tut es oder das Plugin ist wohl nicht so wichtig, dass sich jemand damit auseinandersetzen will.
Es muss auch kein "Profi" oder "alter Hase" sein, es darf ja gerne mal jemand neues sich mit der Pflege eines Plugins auseinandersetzen.
Um die Arbeit zu relativieren:
Ein Maintainer ist meiner Meinung nicht dazu da, um das Plugin weiter zu entwickeln, sondern in erster Linie, die Patches, die von einem Kreis von Testern für gut und richtig befunden werden, in "das" Upstream-Repository zu übernehmen.
Und es darf auch keiner erwarten, dass eine einzelne Person sich um 50 Plugins kümmern soll. Das ist dermaßen viel Arbeit, das kann keiner ernsthaft übernehmen wollen. Und selbst wenn, dann prophezeihe ich, dass derjenige nicht lange dabei bleibt. Auf Dauer kann das keiner leisten.
Also: wer auch immer ein Plugin benötigt, dass nicht mehr aktiv gepflegt wird, der lerne bitte die Grundlagen von git, besorgt sich ein Repository bei github oder projects.vdr-developer.org und pflege dieses.
Oder: ernsthaft darüber nachdenken, ob das Plugin ernsthaft gebraucht wird... 
Lars.
Das wäre aber wieder eine extreme Sonderlösung. Zumindest meiner Meinung nach also alles andere als KISS.
Warum "Sonder"? Die Idee wäre doch, das Ganze zu vereinheitlichen, und des für Plugin-Entwickler KISS zu machen, wenn die Lösung dann mal gut getunt in zentraler Stelle abgelegt wird ist es doch vertretbar dass man bei deren Findung Einiges an Kreativität investiert hat, danch hat man es ja leichter und das zahlt sich dann aus.
Noch einfacher wie jetzt kann man die Plugin-Makefiles kaum noch gestalten.
Ich sage ja nicht daß sie nicht einfach sind, aber sie haben sich andauernd geändert, so haben wir viele Plugins die "behaupten" neu angepasst zu sein, aber doch nicht den letzten Stand haben, mit extremsten Folgen bis hin zu Makefile-1.7.36 installiert die Targets nicht mehr, oder im falschen Verzeichnis, oder jetzt habe ich plötzlich unresolved Symbols, wo es mit vdr-1.7.34(5) dass ja auch neue Makefile hatte doch ging, usw.
Und wenn alles über eine zentrale Logik gequetscht werden muss, dann wird das ganze auch noch extrem unflexibel.
Nicht, wenn man es dafür auslegt, gewisse Freiheiten die Sinn machne (sprich: Definieren einer Art von Schnittstelle) vorzusehen. Vielleicht liege ich falsch, aber Deine Beurteilung beruht möglicherweise auf das Vorurteil was von gewissen Wörtern unde deren allgemenen Bedeutung ("zentrale Logik") geweckt werden, aber hast Du Dir tatsächlich mal diese Makefile von denen ich sprach angescheut, und ausprobiert, wie man die Dinger tatsächlich bauen kann?
Was ist z.B. mit Sourcen die mehrere Plugins enthalten? Beispiel stremdev oder epgsearch.
Sehr ähnlich mit dem, was ich beim UPnP-Plugin gemacht habe wäre eine
Lösung, diese mehreren Plugins einfach in Unterverzeichnisse zu packen
und dem VDR-Buildsystem über ein einziges Makefile darüber als eines zu
"verkaufen".
Lucian
Sonderlösungen bei Plugins wird es immer geben und Klaus wird kaum alle diese und auch zukünftige Anforderungen selber pflegen und irgendwo zentral ablegen wollen.
Ich finde man sollte den Plugin-Autoren so viel Freiheiten wie möglich lassen. Gerade das neue System macht da einiges möglich, da erstmals alles auf halbwegs allgemeinen Standards basiert (pkg-config für Abfragen der Werte, Include-Dir, ...).
Und "unresolved symbols" sollte es eigentlich nicht geben. Hast du da einen konkreten Fehlerfall?
Also: wer auch immer ein Plugin benötigt, dass nicht mehr aktiv gepflegt wird, der lerne bitte die Grundlagen von git, besorgt sich ein Repository bei github oder projects.vdr-developer.org und pflege dieses.
Oder: ernsthaft darüber nachdenken, ob das Plugin ernsthaft gebraucht wird...
Du hast natürlich Recht. Schön wäre es nur gewesen, wenn man die Makefiles nun eh' überarbeitet hat, sie noch robuster gegen Änderungen in VDR-Versionen zu machen und gleichzeitig einfacher. Auf die Art würde die Arbeit, so viele Plugins anzupassen am Schluss geringer sein, mehr Leute würden sich zutrauen es anzupacken, weil es immer auch eine Frage des Aufwands ist.
Lucian
An den Makefiles wird für die 2.0 nichts mehr geändert (es sei denn Bugfixes)!
Wer keine Lust hat, sein Makefile anzupassen, soll gefälligst das alte Makefile nehmen, denn damit geht es ja mittlerweile auch - und so wie's aussieht wird dieser Kompatibilitätsmodus wohl auch in der 2.0 noch drin sein müssen, sonst geht das Geflenne dann wieder los...
Klaus
Und "unresolved symbols" sollte es eigentlich nicht geben. Hast du da einen konkreten Fehlerfall?
Naja, z.B. VNSI-Server oder sein Kollege, XVDR, dann wenn ein ext-Patch (VASARAJANAULOJA denke ich) seine Hände im Spiel hat, Live-Plugin, zeitweise gab es Probleme bei softhddevice die in anderen Threads ja auch diskutiert wurden
Moin!
Zoolook: Wie wäre es, wenn du einfach mal etwas entsprechendes baust? Dann hat man eine Diskussionsgrundlage. Das ist besser als "eigentlich müsste man...". Dabei stellt man dann auch fest, ob das, was man sich ausgedacht hat, wirklich umsetzbar ist, bevor man sich wieder in endlose Diskussionen verstrickt, die zu keinem Ziel führen. Wenn man eine funktionierende Lösung hat, kann die immer noch verbessert und getestet werden. Wenn man merkt, dass der Gedanke nett, aber nicht umsetzbar ist, dann erspart man sich die Streitgespräche darüber.
Allerdings ist Klaus momentan nicht mehr so gut auf Makefile-Änderungen zu sprechen... Aber für die 2.1 kann man ja dann wieder drüber nachdenken.
Ist die "Schnittstelle" zu den Plugin-Makefiles jetzt eigentlich irgendwo im vdr dokumentiert? Das ist häufig das, was immer vergessen wird.
- Welche Targets muss ein Plugin-Makefile unterstützen?
- Wann werden sie aufgerufen?
- Woher bekommt das Plugin die Einstellungen, die es braucht, um die entsprechende vdr-Konfiguration auslesen zu können?
Lars.
P.S.: Während des Tippens kamen natürlich noch ein paar andere Beiträge...
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
