incdir in vdr.pc setzen

  • :modon


    (Ich löse mal die Diskussion um dieses Thema aus dem Announce-Thread heraus. Wer den Anfang nicht mitbekommen hat, fange bitte hier an zu lesen)


    Ich hab mal versucht zusammenzufügen was zusammen gehört :D
    jo01

    :modoff


    Moin!


    Ich hab ein Plugin, das gerne eine Header-Datei installieren möchte. Über Plugin-Header wurde schon mal hier und da gesprochen, aber noch nicht so richtig.
    Ich würde es gerne unter /usr/include/vdr/<Pluginname>/ ablegen, dafür wäre es schön, wenn INCDIR in der vdr.pc stehen würde.


    In meinem Fall ist eine hilfreiche Klasse, um über die Service-Schnittstelle mit meinem Plugin zu kommunizieren. Es ist nicht davon abhängig, ob das Plugin geladen ist oder nicht, weil alles in der Header-Datei ist.
    https://github.com/flensrocker…lob/master/avahi-helper.h


    Was habt ihr für Meinungen zum Ort des Headers?



    Lars.

    vdr2: yaVDR 0.5/softhddevice @ G540, Intel DH67BLB3, Asus GT610/2GB, DDBridge + 2x DuoFlex C/T
    hdvdr: yaVDR unstable/softhddevice @ E8400, Asus P5Q SE Plus, 1x L4M-TwinCI + Flex C/T, 1x Sundtek MediaTV Pro, GT520
    Plugins: | avahi4vdr | dbus2vdr | dynamite | epg2timer | noepg | pvrinput | sundtek |

    Einmal editiert, zuletzt von jo01 ()


  • Ich hab ein Plugin, das gerne eine Header-Datei installieren möchte. Über Plugin-Header wurde schon mal hier und da gesprochen, aber noch nicht so richtig.
    Ich würde es gerne unter /usr/include/vdr/<Pluginname>/ ablegen, dafür wäre es schön, wenn INCDIR in der vdr.pc stehen würde.


    Wenn, dann /usr/include/vdr/plugins/<Pluginname>/.


    Klaus

  • Moin!


    Dann schlage ich zusätzlich noch folgende Erweiterung von newplugin vor:


    Dann machen es zumindest alle Plugins gleich.


    Lars.


  • In meinem Fall ist eine hilfreiche Klasse, um über die Service-Schnittstelle mit meinem Plugin zu kommunizieren.


    Nutzt du die Service-Schnittstelle überhaupt? Für mich sieht es so aus als würdest du direkt die Instanz des Plugins ansprechen.


    So wie ich das verstanden habe, wird über die Service-Schnittstelle auch eine Version mitgegeben. Das erlaubt es die entsprechenden Header-Datei einfach mit den abhängigen Plugins auszuliefern. Es kommt also nicht zu einer festen Abhängigkeit zwischen Plugins. Man kann auch erst das "abhängige Plugin" bauen und (sofern das vorgesehen ist) dessen Features nutzen ohne dein avahi-Plugin überhaupt kompiliert zu haben. Später kann man sich dann immer noch entscheiden dein Plugin zu kompilieren und die beiden finden sich ohne das das abhängige Plugin erneut gebaut werden müsste.


    Ich will das nur mal zur Diskussion stellen bevor hier neue Pfade geschaffen werden. Installierte Header machen das ganze nicht einfacher und spätestens wenn man auch aus dem VDR-Sourceverzeichnis bauen will wird der zusätzliche Include-Pfad für Mehraufwand sorgen.


    Edit: Sehe gerade, dass deine Implementierung wohl im Wesentlichen stimmt, mit Ausnahme der fehlenden Versionsnummer, die nötig wäre, um die Header-Datei mit Plugins auszuliefern:
    http://projects.vdr-developer.…NS.html#Custom%20services

  • Moin!


    Nutzt du die Service-Schnittstelle überhaupt?


    Stimmt, da hab ich mich versprochen. avahi4vdr stellt seine Schnittstelle per SVDRP bereit, weil dort die Rückgabe besser typisiert ist (auch ein Grund für Plugin-Header, siehe unten epgsearch*).
    Eine Versionsnummer brauche ich nicht, da ich bei der Übergabe der Parameter sehr flexibel und versionsunabhängig bin.


    Die Hilfsklasse erleichtert nur das Zerlegen der zurückgegebenen Parameter. Der Header ist so gehalten, dass man ihn auch in ein anderes Plugin kopieren könnte.
    Für yaVDR werde ich auch noch versuchen, ein entsprechendes -dev-Paket zu schnüren, dann ist man nicht vom Plugin selbst abhängig beim Bauen.
    Nutzen kann man avahi4vdr aber auch ohne diesen Header (siehe dbus2vdr https://github.com/flensrocker…dr/blob/master/bus.c#L115).


    Es gibt aber z.B. andere Plugins (die, über die man nicht spricht), die gerne die Header von dvbhddevice/dvbsddevice haben möchten. Und zumindest die mitgelieferten Plugin-Header könnte man ja mitinstallieren. Da werde ich auch noch einen entsprechenden Patch vorbereiten.


    Ich finde die Abhängigkeit von einem Header bei weitem nicht so schlimm, wie die von einer lib. Und solche Header können ungemein bei der Kommunikation zwischen den Plugins helfen.
    Aber natürlich gehört für das aufrufende Plugin immer ein Test dazu, ob das Plugin überhaupt geladen ist (siehe https://github.com/flensrocker…vdr/blob/master/bus.c#L82 und später der Test auf "!= NULL").


    *) Es gibt ja auch noch andere Plugins, die solche Hilfs-Header haben (z.B. epgsearch/services.h). Bei epgsearch würde ich mir einen Header (hier mit Versionsnummer im Namen) wünschen, den andere Plugins einfach benutzen können.
    Andere Plugins sind dann nicht darauf angewiesen, dass epgsearch geladen ist, können es aber leichter nutzen, falls es geladen ist.
    Das lässt sich mit einer lokalen Variante der Header und einem Test im Makefile leicht regeln (wenn INCDIR/vdr/plugins/PLUGIN nicht vorhanden => INCLUDE += -I./include, wo man dann die kopierte Variante der Header entsprechend ablegt).
    Unter Debian gibt es dafür das "suggests"-Feld, damit kann man Pakete hinzufügen, die die Funktionalität erhöhen, aber nicht unbedingt notwendig sind.
    Für Distributoren wäre es dadurch leichter, die Plugins, die angeboten werden, besser aufeinander einzustimmen, weil man dann eben nicht darauf achten muss, ob die passenden Header aus dem anderen Plugin kopiert wurden.


    Die Patches sind nicht unbedingt nötig im vdr, sie würden aber uns Plugin-Autoren das Leben wesentlich leichter machen. Denn die Abhängigkeiten zwischen den Plugins (live, epgsearch, skinnopacity usw.) sind schon da und wird es auch immer geben.
    Irgendeine schöne Form von Kommunikation/Message-Bus innerhalb des vdrs wäre prima, nicht umsonst denken die Kernel-Entwickler ja auch über einen DBus-ähnlichen Message-Bus innerhalb des Kernels nach. Da ist er natürlich für IPC, aber das kann man auch frei mit "inner process communication" übersetzen. :) "Service" ist zwar schon nett, aber eine gemeinsame Linie für die Benutzung dieser Schnittstelle hilft allen. Und dass man Entwickler zu einem gewissen Stil zwingen muss, ist uns wohl allen klar. Wenn man einem Entwickler Freiheiten lässt, dann nutzt er sie auf alle Fälle aus und überschreitet die Grenze meistens auch noch... :)


    Ich hoffe, ich komme überzeugend genug rüber, um vielleicht noch ein paar Anhänger dieser Idee zu gewinnen. :)
    Ich verstehe aber deine Bedenken, ich hoffe ebenso, dass ich sie zerstreuen kann.
    Deshalb ja die Diskussion, damit wir hoffentlich zu einer Lösung kommen, mit der alle Leben können.


    Lars.

  • Es gibt Distributionen ohne dev-Pakete. Und schon hätten wir doch eine Abhängigkeit zum eigentlichen Plugin-Paket.


    Zudem hat keiner verlangt, dass jemand die Header-Files erst aus einem Plugin kopiert, sondern das passende Header-File sollte vom abhängigen Plugin direkt mitgeliefert werden. Durch die Versionsnummer im über die Service-Schnittstelle übergebenen String ist sichergestellt, dass das Plugin, welches die Service-Schnittstelle anbietet, sich darauf einstellen kann, dass ein "anrufendes Plugin" unter Umständen mit einer veralteten Header-Datei gebaut wurde.


    Und was die "Spezialfälle" mit dvbhddevice und dvbsddevice: Hier werden Header-Files verwendet, die streng genommen garnicht zur VDR-API gehören.

  • Moin!


    Es gibt Distributionen ohne dev-Pakete. Und schon hätten wir doch eine Abhängigkeit zum eigentlichen Plugin-Paket.


    Die installieren aber immer die ganzen Sourcen mit (oder ich brauche ein entsprechendes Beispiel). Und so, wie ich das vorhabe, braucht man keine feste Abhängigkeit. Ich würde nur gerne einen Mechanismus etablieren, mit dem es leichter ist, Plugins und ihre Schnittstellen synchron zu halten.


    Zudem hat keiner verlangt, dass jemand die Header-Files erst aus einem Plugin kopiert, sondern das passende Header-File sollte vom abhängigen Plugin direkt mitgeliefert werden.


    Der Plugin-Autor muss es (regelmäßig) machen. Mein Vorschlag erleichtert die Arbeit von Plugin-Autoren.


    Und was die "Spezialfälle" mit dvbhddevice und dvbsddevice: Hier werden Header-Files verwendet, die streng genommen garnicht zur VDR-API gehören.


    Aber sie gehören zur API der Plugins. Warum sollte man die nicht verwenden dürfen?


    Sie sollten aber nach Möglichkeit minimiert werden anstatt sie zu manifestieren!


    Ich will ja gar keine größeren Abhängigkeiten, sondern nur eine Erleichterung für Plugin-Autoren.
    Die Plugins werden hinterher nicht mehr voneinander wissen als vorher. Bloß statt das kopierte Header-File zu benutzen, wird der installierte Header benutzt.
    Ich bau die Tage mal ein Beispiel, komme aber wahrscheinlich erst am Wochenende dazu.


    Lars.


  • Aber sie gehören zur API der Plugins. Warum sollte man die nicht verwenden dürfen?


    Etwas eigensinnige Definition von "vom Plugin intern verwendete Klassendefinitionen" hast du da ;)



    Ich will ja gar keine größeren Abhängigkeiten, sondern nur eine Erleichterung für Plugin-Autoren.
    Die Plugins werden hinterher nicht mehr voneinander wissen als vorher. Bloß statt das kopierte Header-File zu benutzen, wird der installierte Header benutzt.
    Ich bau die Tage mal ein Beispiel, komme aber wahrscheinlich erst am Wochenende dazu.


    Und ich sehe nach wie vor nicht den Grund was hier einfacher werden soll. Das Plugin teilt dem aufgerufenen Plugin die Version des Headers mit, gegen den es gebaut wurde. Fertig. So ist jedes Plugin in sich abgeschlossen.


    Bei deinem Vorschlag wird das Bauen von Plugins deutlich verkompliziert, weil die Plugins dann in einer ganz bestimmten Reihenfolge gebaut und installiert werden müssen. Zudem ist es nicht möglich später im Nachhinein noch ein Plugin nachzubauen auf das bereits gebaute Plugins dann zugreifen könnten.

  • Die installieren aber immer die ganzen Sourcen mit (oder ich brauche ein entsprechendes Beispiel)


    Das tuen sie nicht. Du musst deinen Horizont nur mal über debianbasierten Systemen hinweg erweitern. Während man da versucht alle Source-Pakete in möglichst viele kleine Stückchen zu zerteilen, bleibt es bei anderen Systemen simpel und übersichtlich.


    Und da muss ich irgendwo auch Mreimer widersprechen. Diverse Headerdateien von Plugins, wenn nicht gleich alle Headerdateien in /usr/include kann Vorteile bringen. Zum Beispiel bei den beiden bösen Plugins.

  • Woher willst du wissen, dass sich für mich nichts ändert? Ich baue meine Pakete alle selber!


    Es ist nunmal Fakt, dass die Service-Schnittstelle ganz bewusst so gebaut ist, dass die Plugins entsprechende Header direkt im Source haben können. Eben mit dem Hintergrund, dass ich z.B. erstmal einen bestimmten Theme bauen kann der z.B. Unterstützung für bestimmte Plugins mitbringt. Wenn ich mich später entscheide eines dieser "Zusatz-Plugins" doch noch zu bauen, dann nutzt diese der Theme direkt ohne das er erneut gebaut werden muss.


    Dazu kommt, dass dann der Theme-Author (wenn er die Header nicht mehr mitliefern darf oder soll) eine Prüfung einbauen muss, ob das Plugin, für das es prinzipiell Support hätte, überhaupt vorhanden oder gewünscht ist. Das wird eine ganze Ladung bedingte Kompilierung. Was ist daran dann einfacher? Nach dem aktuellen Stand kann der Plugin-Autor einfach immer mit Support für alle möglichen Plugins bauen auch wenn diese garnicht installiert sind.

  • Durch die Versionsnummer im über die Service-Schnittstelle übergebenen String ist sichergestellt, dass das Plugin, welches die Service-Schnittstelle anbietet, sich darauf einstellen kann, dass ein "anrufendes Plugin" unter Umständen mit einer veralteten Header-Datei gebaut wurde.


    Die Vorgehensweise von mini73 sorgt dafür, dass so eine Situation gar nicht vorkommen kann, da die betroffenen Pakete nicht gegen möglicherweise verschiedene Header-Files gebaut werden. Da die Header-Files auf dem Build-System exakt nur einmal vorhanden sind, können sie auch nicht auseinander laufen. Wenn man dann noch, mit Hilfe von distributions-spezifischen Mechanismen, dafür sorgt, dass alle betroffenen Pakete bei Änderungen neu gebaut werden, gibt es dann auch kein Problem das man auf den Endanwender abschieben muss.


    Ich erwarte ja gar nicht, dass jeder Ubuntu/Debian mag, aber es sind nicht die einzigen Distributionen die mit Hilfe von Dev-Paketen sehr erfolgreich solche Probleme lösen. Technisch gesehen macht ArchLinux es übrigens genau so, nur dass eben das normale Paket quasi das Dev-Paket enthält. Die Header zu kopieren, mit der Gefahr, dass sie auseinander laufen und dann während der Laufzeit zu prüfen ob das passiert ist, ist für mich völlig unakzeptabel.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470


  • Und da muss ich irgendwo auch Mreimer widersprechen. Diverse Headerdateien von Plugins, wenn nicht gleich alle Headerdateien in /usr/include kann Vorteile bringen. Zum Beispiel bei den beiden bösen Plugins.


    Ist nun die Frage, ob diese Dateien, die halt speziell von zwei Plugins genutzt werden (obwohl sie eigentlich kein Bestandteil von irgendeiner API sind!) wirklich extra mit installiert werden sollten.


    Mache da dochmal einen Patch für, der die entsprechenden Header-Dateien mit ablegen würde. Dann kann Klaus sich das mal anschauen.

  • Die Header zu kopieren, mit der Gefahr, dass sie auseinander laufen und dann während der Laufzeit zu prüfen ob das passiert ist, ist für mich völlig unakzeptabel.


    ... aber von der VDR-API im Moment genau so vorgesehen um solche Abhängigkeiten eben nicht zu haben.


    Einfacher wird durch eine zentrale Platzierung der Header auf jedem Fall nichts. Als Beispiel würde ich da mal skinelchi hernehmen. Hat Support für "avards", "mailbox" und "epgsearch". Wenn der Author jetzt nicht in das README schreiben will "du musst erst Plugin X, Y und Z bauen *und* installieren bevor du mein Plugin bauen kannst", dann bräuchte es für all diese Service-Header entsprechende Checks. Bedingte Kompilierung inklusive.

  • Mache da dochmal einen Patch für, der die entsprechenden Header-Dateien mit ablegen würde. Dann kann Klaus sich das mal anschauen.


    Gegenvorschlag: Mach du doch mal einen Patch gegen die beiden Plugins, dass diese Headerdateien nicht mehr gebraucht werden.


    Edit: Und erkläre das dann mal manio, warum das so sein muss/soll

  • Da muss ich jetzt auch mal meinen Senf dazugeben... ;)


    Es geht (wenn ich das recht verstanden habe) doch nur um eine Vereinbarung. Und zwar die Vereinbarung das Headerfiles von Plugins unter "./include/vdr/plugins/<pluginname>" abgelegt werden.
    Und der Wunsch ist das diese Vereinbarung dardurch offiziell Dokumentiert wird das man das ins Plugin Makefiletemplate reinschreibt.
    Ist doch nicht schlimm und schafft keine Querabhängigkeiten.



    Ich finds logisch, für ein Plugin was eine Service Schnittstelle anbietet wird ein vdr-plugin-<pluginname>-dev Paket mitgebaut welches das Service Headerfile nach /usr/include/vdr/plugins/<pluginname> installiert.
    Plugins die diese Serviceschnittstelle nutzen sind halt vom vdr-plugin-<pluginname>-dev Paket abhängig (als Bauabhängigkeit) und wissen automatisch wo sie das Headerfile finden.



    Klingt für mich sinnig und ist auf alle Fälle besser als Teile von Plugins in andere Plugins zu kopieren.



    Wobei (und diesen Punkt habe ich hier noch nicht gesehen) die Plugins dann auch nen "include-dir" Target haben sollten, und diesen müsste der VDR dann in seinem include-dir Target für alle Plugins aufrufen. Dann funktioniert auch ein make plugins im VDR Dir sauber.


    cu


  • Gegenvorschlag: Mach du doch mal einen Patch gegen die beiden Plugins, dass diese Headerdateien nicht mehr gebraucht werden.


    Edit: Und erkläre das dann mal manio, warum das so sein muss/soll


    Ist in diesem Fall eine ganz andere Situation, da keine offizielle API und auch kein Plugin-Service. Die Header-Dateien in den Plugins können sich (schon weil sie nicht mit der Wiederverwendbarkeit im Hintergedanken entwickelt werden, weil ja eigentlich kein API-Bestandteil) mit jeder Version ändern.


    Die Service-Schnittstelle wurde aber, so wie ich das verstehe, bewusst so gebaut, dass Plugins auch dann Support für andere Plugins einbauen können, wenn diese optionalen Plugins überhaupt nicht installiert sind.

  • Moin!


    Du musst deinen Horizont nur mal über debianbasierten Systemen hinweg erweitern.


    Ich hab überhaupt kein Problem mit anderen Distributionen, deshalb hab ich ja auch geschrieben, dass ich gerne andere Beispiele sehen möchte.
    Du kennst dich doch mit ArchLinux aus. Wenn da ein Paket installiert wird, was passiert dann? Nur das, was "make install" macht?
    Als Paket-Autor entscheide ich, einen Header zu installieren, weil darüber die Kommunikation mit meinem Paket geregelt wird. Also wäre doch alles klar?


    Etwas eigensinnige Definition von "vom Plugin intern verwendete Klassendefinitionen" hast du da ;)


    Im Beispiel epgsearch sind das eben nicht intern verwendete Klassendefinitionen, sondern welche, die von anderen Plugins genutzt werden sollen, weil sie beim Service-Aufruf erwartet werden. Damit ich das für mich eine öffentliche API.


    Bei deinem Vorschlag wird das Bauen von Plugins deutlich verkompliziert, weil die Plugins dann in einer ganz bestimmten Reihenfolge gebaut und installiert werden müssen.


    Nein, von müssen hab ich nie gesprochen. Das abhängige Plugin (nehmen wir mal live als Beispiel) hat immer noch seine lokale Kopie der epgsearch-Header (für den Fall, dass kein -dev-Paket angeboten werden kann). Die werden aber nur dann benutzt, wenn es keine global installierten epgsearch-Header gibt. Im Code gibt es keine ifdefs oder sonstiges, sondern nur im Makefile eine Prüfung "existieren globale epgsearch-Header? wenn nein, füge lokales Include-Verzeichnis mit diesen zu den INCLUDES hinzu". Im Plugin selbst steht immer "#include <vdr/plugins/epgsearch/services.h>", unterhalb von live gibt's dann einfach eine Datei "includes/vdr/plugins/epgsearch/services.h". Nur falls "INCDIR/vdr/plugins/epgsearch" nicht existiert, wird "INCLUDES += ./include" hinzugefügt.


    Woher willst du wissen, dass sich für mich nichts ändert? Ich baue meine Pakete alle selber!


    Weil ich Patche eigentlich immer so baue, dass das neue Verhalten optional genutzt werden kann und das alte standardmäßig erhalten bleibt.


    Es ist nunmal Fakt, dass die Service-Schnittstelle ganz bewusst so gebaut ist, dass die Plugins entsprechende Header direkt im Source haben können.


    Das dürfen (und müssen) sie auch weiterhin. Ich möchte nur eine einfache Möglichkeit haben, die originalen Header des anderen Plugins nutzen zu können.
    Das macht mir das Entwickeln von Plugins einfacher und auch als Distributor hat es Vereinfachungen zur Folge, weil ich dann (in meiner Distribution) die Buildabhängigkeiten entsprechend setzen kann, so dass alles in der richtigen Reihenfolge gebaut wird und alle beteiligten Pakete die gleichen Schnittstellen benutzen.
    ArchLinux mag zwar per se keine -dev-Pakete haben, aber unmöglich wäre es nicht, welche zu erstellen, eben um die Abhängigkeiten zu trennen.
    Beide Plugins wären dann vom "Interface"-Paket abhängig.


    Das ist doch ein ganz normaler Pattern in der Software-Entwicklung. Es gibt interface-Dateien, in denen die Schnittstellen geregelt sind, und die, die sie nutzen/zur Verfügung stellen, benutzen dieses Interface.


    Die Header-Dateien in den Plugins können sich (schon weil sie nicht mit der Wiederverwendbarkeit im Hintergedanken entwickelt werden, weil ja eigentlich kein API-Bestandteil) mit jeder Version ändern.


    Genau deshalb will ich doch diese Vereinbarung... :) Damit ich fehlerhafte Zusammenhänge schneller und leichter finde.


    Keine_Ahnung hat es schon ziemlich genau getroffen.


    Lars.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!