[ANNOUNCE] VDR developer version 1.7.34

Zitat von Copperhead

Das müsste nicht per pkg-config abgefragt werden. Es ist nicht vorgesehen, dass Plugins untereinander Defines austauschen.

Es geht ja auch nicht darum, sondern darum das die Plugins wissen müssen welche Patches im VDR aktiv sind.

USE_PINPLUGIN meint ja nur das der VDR mit dem pinplugin Patch gepatcht ist. Ob das pin Plugin vorhanden ist oder nicht ist epgsearch ja vollkommen egal.

Also konkret ein beispiel aus dem epgsearch Code

fullaux = UpdateAuxValue(fullaux, "epgsearch", aux);
         }
#ifdef USE_PINPLUGIN
         aux = "";
	 aux = UpdateAuxValue(aux, "protected", timer->FskProtection() ? "yes" : "no");
         fullaux = UpdateAuxValue(fullaux, "pin-plugin", aux);
#endif
         SetAux(timer, fullaux);

Ohne pinplugin Patch gibt es timer->FskProtection() ja nicht.

Zitat von Copperhead

Mir war schon klar, dass es mit dieser Makefileänderung am Anfang zu größeren Problemen kommen wird. Bitte habt etwas Geduld.

War ja keine Ungedult sondern nur ein Hinweis

Ist schon klar das solche Änderungen nicht punktgenau 100%ig perfekt kommen können, bei sowas ergeben sich zwangsläufig immer kleinere Nacharbeiten.

BTW: Und PLUGIN_EPGSEARCH_SEP/PLUGIN_EPGSEARCH_MAX_SUBTITLE_LENGTH?

cu

Zitat von kls

Hmm, vielleicht sollte ich mal eine "Zertifizierung" für VDR-Plugins einführen... ;-).

Ja, bitte

Zitat von kls

[...] Hmm, vielleicht sollte ich mal eine "Zertifizierung" für VDR-Plugins einführen... ;-).

Oder besser noch, die wichtigsten Patche, die seit Jahren existieren, gleich in den vdr einbauen,

Zitat von 3PO

Oder besser noch, die wichtigsten Patche, die seit Jahren existieren, gleich in den vdr einbauen,

Passiert doch ständig Wenn ich das recht verstehe ist z.B. der graptft Patch auch gerade überflüssig geworden.

cu

Zitat von Keine_Ahnung

BTW: Und PLUGIN_EPGSEARCH_SEP/PLUGIN_EPGSEARCH_MAX_SUBTITLE_LENGTH?

Mit meinem Patch sollte "make PLUGIN_EPGSEARCH_SEP=blahblub PLUGIN_EPGSEARCH_MAX_SUBTITLE_LENGTH=blahblub" passen

Der zweite Wert sollte aber sinnvollerweise aus dem VDR gelesen werden. Wie C-3PO schon angemerkt hat, ist der im VDR bisher auf 40 statt auf 255.

Edit: Was Pin-Plugin angeht habe ich gerade von Klaus erfahren, dass das nach 2.0 obsolete wird. Für die Zeit bis dahin sollte es reichen, wenn der Patch gegen den VDR irgendwo in der Make.config oder Makefile folgendes hinzufügt.

DEFINES+= -DUSE_PINPLUGIN

Über mehrere Umwege landet es dann schließlich doch im Plugin.

Wenn ein Pluginentwickler die Makefiles von mir umgestellt haben möchte --> PN
Da ich möchte, dass das so schnell wie möglich über die Bühne geht, mache ich es gerne selber.

Zitat von Copperhead

Mit meinem Patch sollte "make PLUGIN_EPGSEARCH_SEP=blahblub PLUGIN_EPGSEARCH_MAX_SUBTITLE_LENGTH=blahblub" passen

Das vergisst man aber mal gerne.

Evtl. wäre es gut ein make.plugins (analog zur make.config die vom VDR verwendet wird) einzufügen welches von den Plugin Makefiles included wird?

Wobei ich jetzt eigentlich dachte sowas soll in die vdr.pc und dann von den Pluginmakefiles per pkg-config ausgelesen werden?

Zitat von Copperhead

Der zweite Wert sollte aber sinnvollerweise aus dem VDR gelesen werden.

Der lässt sich AFAIK nicht aus dem VDR lesen.

Zitat von Copperhead

Edit: Was Pin-Plugin angeht habe ich gerade von Klaus erfahren, dass das nach 2.0 obsolete wird. Für die Zeit bis dahin sollte es reichen,

Naja, es wird auch nach der 2.0 diese Art von Problemen geben.

Wobei das ja nur die Multipatches betrifft, die Einzelpatches können das ja per define im Quellcode selber setzen.

Zitat von Copperhead

wenn der Patch gegen den VDR irgendwo in der Make.config oder Makefile folgendes hinzufügt.

Das greift aber doch nicht wenn im Pluginverzeichnis selber make aufgerufen wird, oder?

cu

Zitat von Keine_Ahnung

Das greift aber doch nicht wenn im Pluginverzeichnis selber make aufgerufen wird, oder?

Doch normalerweise schon.

Das wird dann auch mitinstalliert und steht dann auch in der vdr.pc-Datei in /usr/lib/pkgconfig

Zitat von Copperhead

Doch normalerweise schon.

Das wird dann auch mitinstalliert und steht dann auch in der vdr.pc-Datei in /usr/lib/pkgconfig

Ah, jetzt habe ich es verstanden. Und um einfach ne pc im vdr Sourcedir zu generieren mache ich ein "make vdr.pc", dann noch ein "make include-dir" und ich kann die Plugins im vdr Quelverzeichnis per make bauen.

OK, manchmal brauchts etwas fürs Verständnis

Bleibt nur noch das Problem das man die Plugins nicht mehr zentral Konfigurieren kann. Könnte man nicht ne vdr-plugin.pc einführen wo die Settings für die Plugins drinstehen? Und die Pluginmakefiles fragen dann die Dinge die sie interessieren (z.B. den Wert von PLUGIN_EPGSEARCH_MAX_SUBTITLE_LENGTH) dort ab.

cu

Zitat von Keine_Ahnung

Bleibt nur noch das Problem das man die Plugins nicht mehr zentral Konfigurieren kann. Könnte man nicht ne vdr-plugin.pc einführen wo die Settings für die Plugins drinstehen?

Jetzt sind wir gerade das Make.global losgeworden, und jetzt soll schon wieder ein neues Filer daherkommen? Ganz sicher nicht!
Plugins sollen nicht voneinander abhängen!

Zitat

Und die Pluginmakefiles fragen dann die Dinge die sie interessieren (z.B. den Wert von PLUGIN_EPGSEARCH_MAX_SUBTITLE_LENGTH) dort ab.

Wieso interessiert es irgendjemanden was EPGSearch für ein "MaxSubtitleLength" hat? Das ist doch schon wieder eine völlig überflüssige Querverbindung.
Das MAX_SUBTITLE_LENGTH in VDR kann ich ja in ein Header-File verfrachten, vielleicht ist damit ja dieses Thema sowieso erledigt.
Ach ja, übrigens steht in timers.c:

#define VFAT_MAX_FILENAME 40 // same as MAX_SUBTITLE_LENGTH in recording.c

Hoffentlich macht das keine Probleme, wenn VFAT_MAX_FILENAME auch auf 255 (0der 240?) gesetzt wird...

Klaus

Zitat von kls

Jetzt sind wir gerade das Make.global losgeworden, und jetzt soll schon wieder ein neues Filer daherkommen? Ganz sicher nicht!
Plugins sollen nicht voneinander abhängen!

Es geht nicht um Querverbindungen sondern um Konfiguration. Das was der VDR in seiner make.config hat (also das der Nutzer bestimmte Sachen (die den Bau beeinflussen) voreinstellt), sowas brauchen die Plugins teilweise ja auch. Also muss das irgendwo abgelegt werden können ohne das man da am Pluginquellcode rumpatcht.

Gut, man könnte ne make.config in jedes Pluginverzeichnis packen (also jedes Plugin hat seine eigene make.config), aber das gibt unnötige Fummelei wenn man Plugins updatet.

Zitat von kls

Wieso interessiert es irgendjemanden was EPGSearch für ein "MaxSubtitleLength" hat?

Das interessiert niemanden, nur epgsearch findet das interesannt. Und irgendwie muss der Nutzer das ja epgsearch mitteilen. Und bissher stands halt in der make.config.

Wobei du das jetzt nicht an dem MaxSubtitleLength Ding festmachen solltest, es gibt ja für alle möglichen Plugins haufenweise Sachen zum konfigurieren.
Z.B. für epgsearch PLUGIN_EPGSEARCH_SEP_ITEMS, das muss ja jeder User für sich selber individuell konfigurieren.

cu

@Kaus: Damit die neuen Makefiles mit dem stable vdr bauen muss dessen Makefile nen vdr.pc erstellen. Würdest du dafür nen Patch annehmen und dann ne 1.6.0-4 rausbringen?
Sonst fängt das an alles wild durcheinander zu gehen wenn sich jeder Pluginauthor ne eigene Lösung für das Problem ausdenkt.

BTW: Was ich schon immer wissen wollte... Warum werden in den Makefiles per "@touch $@" alle *.po einmal angefasst auch wenn sich dort nix geändert hat?

cu

Zitat von Keine_Ahnung

Wobei du das jetzt nicht an dem MaxSubtitleLength Ding festmachen solltest, es gibt ja für alle möglichen Plugins haufenweise Sachen zum konfigurieren.
Z.B. für epgsearch PLUGIN_EPGSEARCH_SEP_ITEMS, das muss ja jeder User für sich selber individuell konfigurieren.

In den meisten Fällen sollte es mit DEFINES+= funktionieren. Sollte das mal nicht so sein, ist es eine Kleinigkeit, das zu ändern.

Zitat von Copperhead

In den meisten Fällen sollte es mit DEFINES+= funktionieren. Sollte das mal nicht so sein, ist es eine Kleinigkeit, das zu ändern.

Gib doch mal nen Beispiel wie du das (PLUGIN_EPGSEARCH_SEP_ITEMS) jetzt lösen würdest.

Weil ich vermute mal wir reden hier gerade alle irgendwie aneinander vorbei

cu

Zitat von Keine_Ahnung

Es geht nicht um Querverbindungen sondern um Konfiguration. Das was der VDR in seiner make.config hat (also das der Nutzer bestimmte Sachen (die den Bau beeinflussen) voreinstellt), sowas brauchen die Plugins teilweise ja auch. Also muss das irgendwo abgelegt werden können ohne das man da am Pluginquellcode rumpatcht.

Aber genau dafür wäre doch eine Make.config gedacht - daß man eben nicht am Quellcode "rumpatcht", sondern einfach seine eigene Make.config reinkopiert und fertig. Bei VDR geht das ja auch, also warum nicht bei den Plugins?
Ich finde, wenn ein Plugin schon Compile-Time-Einstellungen braucht, dann sollte sich da jedes Plugin selber drum kümmern und nicht krampfhaft versucht werden, das zu zentralisieren. Im Idealfall hat ein Plugin gar keine zusätzlichen Compile-Time-Einstellungen.

Zitat

Gut, man könnte ne make.config in jedes Pluginverzeichnis packen (also jedes Plugin hat seine eigene make.config), aber das gibt unnötige Fummelei wenn man Plugins updatet.

Eigene Make.config reinkopieren und fertig. Dafür macht man sich mal ein Script und gut is'.

Zitat

Das interessiert niemanden, nur epgsearch findet das interesannt. Und irgendwie muss der Nutzer das ja epgsearch mitteilen. Und bissher stands halt in der make.config.

Aber auch nur in einer *gepatchten* ;-).

Zitat

Wobei du das jetzt nicht an dem MaxSubtitleLength Ding festmachen solltest, es gibt ja für alle möglichen Plugins haufenweise Sachen zum konfigurieren.
Z.B. für epgsearch PLUGIN_EPGSEARCH_SEP_ITEMS, das muss ja jeder User für sich selber individuell konfigurieren.

Und warum *muß* er das? Kann man sowas nicht einfach so machen, daß es "einfach funktioniert" ("it just works")?
Und wenn sowas schon konfigurierbar sein muß, warum dann nicht über die setup.conf? Da kann jedes Plugin seine Parameter ablegen und sie sind zentral und auch nach Updates verfügbar.

Und generell sollte man sich bei jedem Parameter dreimal fragen, ob der *wirklich* konfigurierbar sein *muß*! Wenn ich ein Programm benutze, und ich muß erstmal hunderte von Parametern einstellen, dann reicht's mir schon. Ein Programm soll erstmal einfach funktionieren und das tun, was es soll. Ein paar Feinheiten kann man dann im laufenden Bestrieb noch justieren (Setup). Aber wenn man bein "Bauen" schon zuviel einstellen muß, ist das eher schlecht. Ich habe manchmal den Eindruck, manche überlegen sich erstmal hundert Parameter und denken sich dann eine passende Applikation dazu aus... ;-).

Klaus

Zitat von Keine_Ahnung

@Kaus: Damit die neuen Makefiles mit dem stable vdr bauen muss dessen Makefile nen vdr.pc erstellen. Würdest du dafür nen Patch annehmen und dann ne 1.6.0-4 rausbringen?
Sonst fängt das an alles wild durcheinander zu gehen wenn sich jeder Pluginauthor ne eigene Lösung für das Problem ausdenkt.

Die neuen Makefiles sind für die *aktuelle* Version gedacht - Version 1.6 ist *stable* und da ändert sich auch nichts mehr.
Und ich möchte möglichst bald eine stable 2.0 machen, dann dürfte das Thema 1.6 sowieso erledigt sein ;-).

Aber du kannst selber gerne so einen Patch anbieten ;-).

Zitat

BTW: Was ich schon immer wissen wollte... Warum werden in den Makefiles per "@touch $@" alle *.po einmal angefasst auch wenn sich dort nix geändert hat?

Weil bei mir die *.po Files normalerweise schreibgeschützt sind und aus irgend einem Grund gab es immer wieder Situationen, wo er die neu schreiben wollte, auch wenn sich nichts geändert hatte. Der "touch" hat das dann behoben.

Klaus

kls: If you're going to touch the VFAT code, so it would be better to fix the current implementation rather than break it even more - or remove it completely.

The current 40 character limit works only, if you don't do any extensive nesting directory structure due to Windows API's MAX_PATH of 260 characters. Please, take a look at the paragraph "Maximum Path Length Limitation" at http://msdn.microsoft.com/en-u…/aa365247%28VS.85%29.aspx. There are plenty of implementations having the mentioned character limit, for example Samba.

Zitat von kls

Die neuen Makefiles sind für die *aktuelle* Version gedacht - Version 1.6 ist *stable* und da ändert sich auch nichts mehr.
Und ich möchte möglichst bald eine stable 2.0 machen, dann dürfte das Thema 1.6 sowieso erledigt sein ;-).

Aber du kannst selber gerne so einen Patch anbieten ;-).

Mann-o-mann, was habt ihr da wieder für ein Faß aufgemacht!?! Und dann auch noch ausgerechnet zu Weihnachten. Jetzt kann ich mir erst einmal überlegen, wie ich das Plugin-Makefile so hinbiege, daß es auch mit alten Versionen funktioniert.

Derartige Änderungen, die auf einen Schlag alle Plugins unkompilierbar machen, gehören vorher koordiniert!

Weihnachtliche Grüße

Oliver

Das ist jetzt meine Variante: http://projects.vdr-developer.…ects/plg-ripit/repository
1.6er Nutzer müssen ihr Makefile halt umbenennen, ich überlege aber noch ob ich aus "makefile" -> "makefile.1.7.x" mache so das man das mit nem Symlink konfigurieren kann.

Aber besonderst glücklich bin ich damit nicht. Aber ich hatte auch keine Lust im Makefile mit haufenweise entweder/oder Abfragen rumzubasteln um alle Varianten abzufangen.

cu

Zitat von UFO

[...] Mann-o-mann, was habt ihr da wieder für ein Faß aufgemacht!?! Und dann auch noch ausgerechnet zu Weihnachten. Jetzt kann ich mir erst einmal überlegen, wie ich das Plugin-Makefile so hinbiege, daß es auch mit alten Versionen funktioniert.

Derartige Änderungen, die auf einen Schlag alle Plugins unkompilierbar machen, gehören vorher koordiniert! ...

Das ist halt die VDR Version des 21.12.12.

Zitat von kls

Die neuen Makefiles sind für die *aktuelle* Version gedacht - Version 1.6 ist *stable* und da ändert sich auch nichts mehr.
Und ich möchte möglichst bald eine stable 2.0 machen, dann dürfte das Thema 1.6 sowieso erledigt sein ;-).

Was ist mit der Weiterentwicklung von Plugins? Wenn ich jetzt meine Plugins auf das neue Makefile umstelle, sind Besitzer eines stable VDRs von der Weiterentwicklung meiner Plugins ausgeschlossen.