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.
Keine Änderungen an den Makefiles mehr vor der Version 2.0!
Klaus
Keine Änderungen an den Makefiles mehr vor der Version 2.0!
Jup, schon klar 
Aber den Punkt könnte man ja für später im Hinterkopf behalten.
cu
Nur das, was "make install" macht?
99% der Pakete kommen aus einem Sourcepaket und landen in einem Distributionspaket. Und in den allermeisten fällen wird nur "make install" aufgerufen.
Also wäre doch alles klar?
Im Prinzip ja.
99% der Pakete kommen aus einem Sourcepaket und landen in einem Distributionspaket. Und in den allermeisten fällen wird nur "make install" aufgerufen.
Im Prinzip ja.
Prima. 
Wenn ich in meinem Paket zwei unabhängige install-Targets anbieten würde (z.B. install und install-dev), dann könntest du wahrscheinlich leicht zwei Pakete daraus machen, oder?
Oder was wäre dafür nötig?
Lars.
Ja theoretisch. Ich müsste aber dem Arch Build Standard folgen und der schreibt mir eigentlich vor, dass alles was aus einer Quelle kommt in einem Paket landen muss.
Wie gesagt das sind ganz bestimmte Ausnahmen wann ein Paket gesplittet werden darf/soll
Ja theoretisch. Ich müsste aber dem Arch Build Standard folgen und der schreibt mir eigentlich vor, dass alles was aus einer Quelle kommt in einem Paket landen muss.
Wie gesagt das sind ganz bestimmte Ausnahmen wann ein Paket gesplittet werden darf/soll
Ich will das alles ja auch nicht für alle Plugins, sondern nur für die paar Ausnahmen...
avahi4vdr möchte sowas anbieten, epgsearch hat sowas. Weiß noch jemand von anderen Plugins, die ähnlich wie epgsearch bestimmte Strukturen über die Service-Schnittstelle erwarten?
Für mich kann es im Falle von epgsearch auch bedeuten, dass es eine getrennte Quelle mit den Service-Headern gibt, die dann auch von epgsearch und allen anderen Interessierten benutzt wird.
Nennen wir sie einfach mal "libepgsearch". Da muss ja nicht zwingend eine lib drin sein, die Header reichen ja auch schon für eine "lib" aus.
Dann wäre es Arch-konform und im Debian-Umfeld wäre es auch einfacher, ein extra Paket zu bauen.
Das Makefile von epgsearch könnte man entsprechend anpassen, dass bei "make dist" zwei tarballs entstehen. Wäre das ok?
Lars.
Weiß noch jemand von anderen Plugins, die ähnlich wie epgsearch bestimmte Strukturen über die Service-Schnittstelle erwarten?
Wenn ich das richtig verstanden habe die ganzen Plugins von schmirl: http://vdr.schmirler.de/ - IIRC hatte er angekündigt den Header von svdrpservice in die einzelnen Pakete aufzunehmen.
Weiß noch jemand von anderen Plugins, die ähnlich wie epgsearch bestimmte Strukturen über die Service-Schnittstelle erwarten?
Ja mein Ausgabeplugin SoftHdDevice hat drei Structuren. 1x zum 3D Umschalten, 1x für dfatmo, 1x für sedu atmo.
Johns
Wäre das ok?
Wenn das an mich gerichtet ist: Ich entscheide da gar nichts.
Das ist Klaus' Entscheidung. Wenn ich mich richtig erinnere hatte Klaus schonmal über eine Art Zertifizierung der Plugins laut nachgedacht.
Ich vertraue da voll und ganz Klaus. Auch wenn ich in diesem aktuellen Fall die Opposition (schönes Wort :D) gut verstehen kann.
Wenn das an mich gerichtet ist: Ich entscheide da gar nichts.
Entscheiden brauchst du auch nicht.
Ich würde nur gerne wissen, ob das für dich als Paketbauer in Ordnung wäre oder ob du diesbezüglich andere Bedürfnisse/Wünsche/Vorschläge hast.
Noch befindet sich das alles ja in einem RFC-Stadium.
Lars.
Wenn ihr das wirklich umsetzt (obwohl Klaus gesagt hat, dass er es nicht will). Dann landen die Headerdateien einfach im entsprechenden Plugin-Paket und gut ist.
(obwohl Klaus gesagt hat, dass er es nicht will)
Vor der 2.0 will ich das auch nicht unbedingt.
Und wenn zwei Plugins vom gleichen "lib"- bzw. "dev"-Paket abhängig sind, sehe ich da keinen Widerspruch zu "die Plugins sollten minimal voneinandern abhängig sein".
Eine minimalere, vernünftige Abhängigkeit sehe ich nicht.
Lars.
Moin!
johns:
Eigentlich müsste der include so lauten:
#include <vdr/plugins/softhddevice/service.h>
Und das Plugin-Makefile müsste wie Keine_Ahnung erwähnt hat, ein "install-includes" bekommen (nur die, die es brauchen), das die öffentlichen Header nach $INCDIR/vdr/$PLUGIN installiert.
Das sind aber gerade die Details, die ich eigentlich besprechen wollte...
Ich hoffe, die betroffenen Plugin-Autoren haben Lust, da einen "Standard" mit mir zu erarbeiten. Das würde mich freuen.
Lars.
Zur "harten" Abhängigkeit zwischen den Plugins: Ich will und etabliere da keine harten Abhängigkeiten!
Wenn zwei Plugins die selbe Datenstruktur für eine Kommunikation benutzen wollen, dann gehört die in ein gemeinsam zu nutzendes Headerfile (aka dev-Paket), von dem beide abhängig sind. Aber die Plugins werden dadurch nicht voneinander abhängig!
Bei Distributionen, die keine dev-Pakete kennen, kommt das einer harten Abhängigkeit gleich. Bisher waren Plugins *in sich abgeschlossen*.
Bei deiner Forderung gibt es nur zwei Optionen:
- Plugins, die Schnittstellen nutzen wollen, setzen faktisch diese hart voraus. Man muss für skinelchi also z.B. zwingend im Voraus dafür sorgen, dass die Header vom avards-Plugin, mailbox-Plugin und epgsearch-Plugin vorhanden sind. Bei "Selberbauern" kommt das einem Zwang, diese Plugins im Voraus zu installieren, gleich
- Der Plugin-Autor entscheidet sich diese Schnittstellen nicht als zwingende Abhängigkeit zu sehen. Dann muss der Plugin-Autor massiv mit bedingter Kompilierung arbeiten. Wenn man das "Service-Plugin" später noch nachinstalliert, müssen die abhängigen Plugins dann neu gebaut werden. Das war bisher nicht nötig.
Bisher hat es ausgereicht, einfach das Plugin, das man nutzen will, zu kompilieren. Und um ehrlich zu sein war gerade das eines der Dinge, die ich an der Service-Schnittstelle vom VDR als sehr vorteilhaft angesehen habe.
Zitat
Build-Abhängigkeiten hat es schon immer gegeben und wird es immer geben. Aber es ist keine Abhängigkeit zwischen den Plugins!
Es gibt Distributionen ohne diese dev-Pakete und auch Selberbauer haben keine Dev-Pakete. Für viele kommt das also einer Abhängigkeit gleich.
@Mods: Als nett gemeinte Unterstützung:
Verschoben werden muss Post 56, 58-89, 92-100 und Post 101-102 sollten dann gelöscht werden.
Für viele kommt das also einer Abhängigkeit gleich.
Ja das ist eine Art Abhängigkeit. Diese Abhängigkeit entsteht aber nicht durch den Vorschlag von mini73, sondern diese Abhängigkeit ist einfach da.
Ein Plugin bietet eine Service-Schnittstelle an, ein anderes Plugin will sie benutzen. Egal was du machst, diese Abhängigkeit bekommst du nicht weg.
Dein Vorschlag das Problem mit Versionsnummern zu lösen und den Enduser dann auf einer Fehlermeldung sitzen zu lassen ist einfach schlecht, weil der Enduser das Problem eventuell nicht lösen kann.
Ein Selbstbauer, der gleichzeitig Enduser ist, ist sehr wohl in der Lage die Abhängigkeiten schon während der Compile-Zeit aufzulösen. Lösen muss er das Problem doch sowieso, warum erst vor sich herschieben?
Es gibt nur zwei Möglichkeiten diese Abhängigkeiten zu verhindern:
Gerald
Ich versuche mal meine Sicht als Plugin-Entwickler darzulegen.
Als ich damals die Service-Schnittstelle anderer Plugins (ich nenne sie im folgenden mal Service-Plugins) nutzen wollte stand ich auch vor dem Problem, dass die Header-Files des Service-Plugins nicht verfügbar waren. Ich konnte aber auch nicht voraussetzen, dass man erst das Service-Plugin (Quelltext) installieren muss, um mein Plugin zu übersetzen.
Deshalb habe ich mich entschieden, die Header-FIles der Service-Plugins in meinen Plugins mitzuliefern. Damit ist mein Plugin immer übersetzbar - ob die Service-Schnittstelle genutzt werden kann wird sowieso zu Laufzeit entschieden, nämlich ob das Service-Plugin geladen ist und es die Schnittstellenversion unterstützt.
- Wenn sich jetzt die Schnittstellenversion des Service-Plugins ändert, dann muss ich sowieso mein Plugin anpassen, dann kann ich auch grade das neue Header-File mitliefern.
- Wenn das Service-Plugin z.B. zu Schnittstelle_V1 zusätzlich Schnittstelle_V2 bietet, dann funktioniert mein Plugin auch noch mit Schnittstelle_V1 - da hätte ich also keinen Vorteil von einem aktuelleren Header-File.
Nach der reinen Lehre wäre es zwar richtig, die Header-Files irgendwo zusammenzufassen, aber ich sehe das eher pragmatisch und liefere die Header-Files einfach in meinem Plugin mit, denn es wird ja zur Laufzeit entschieden, ob der Service in der passenden Version zur Verfügung steht. Ich mache es also den Distri-Entwicklern einfacher, da ich keine Abhängigkeiten zum Quelltext (bzw. installierten Header-Files) anderen Plugins einführe.
Außerdem musste ich noch nie ein Plugin an eine neue Service-Schnittstelle anpassen - die sind äußerst konstant (Mailboxplugin seit 2006, epgssearch/avards seit 2008 ).
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!