incdir in vdr.pc setzen

Zitat von gda

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.

Wer redet von einer Fehlermeldung? Das Service-Plugin bekommt mitgeteilt, dass da ein Plugin anklopft, welches eine alte Schnittstelle nutzen möchte. Statt Fehlermeldung wäre es also durchaus auch eine Option, dass die alte Struktur noch eine bestimmte Zeit im Service-Plugin vorgehalten wird (Übergangszeit) und das anfragende Plugin dann in der von ihm erwarteten Form versorgt wird.

Umstellung auf "Fehlermeldung" kann dann immer noch nach einer angemessenen Übergangszeit erfolgen.

Zitat von Mreimer

Wer redet von einer Fehlermeldung? Das Service-Plugin bekommt mitgeteilt, dass da ein Plugin anklopft, welches eine alte Schnittstelle nutzen möchte. Statt Fehlermeldung wäre es also durchaus auch eine Option, dass die alte Struktur noch eine bestimmte Zeit im Service-Plugin vorgehalten wird (Übergangszeit) und das anfragende Plugin dann in der von ihm erwarteten Form versorgt wird.

Es geht hier aber doch um den Fall, dass es bereits für beide Plugins Versionen gibt, die die neue Schnittstelle kennen. Du weigerst dich aber dich um diese Problematik kümmern zu wollen. Du möchtest dass das alte Plugin A auch noch mit dem neuen Plugin B funktioniert und drückst dem Plugin-Autor Extra-Arbeit auf.

Gerald

Zitat von FireFly

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.

Alles anzeigen

Im Prinzip wollte ich gerade so ziemlich das gleiche schreiben.
Wenn ein Plugin einen Service eines anderen Plugins verwenden will, dann muß es eine ganz bestimmte Version dieses Services verwenden. Und wenn das "Service-Plugin" (um mal "FireFly"s Nomenklatur zu verwenden) hierfür ein Header-File anbietet, dann ist es IMHO am besten, wenn das benutzende Plugin sich dieses Header-File (ggf. mit einer Versionsnummer im Namen) in seine eigene Source mit reinkopiert. Denn *dieser* Stand ist sowieso "eingefroren" - sollte er sich jemals ändern, muß es eine neue Versionsnummer geben.

Ich halte daher den Vorschlag "öffentliche Plugin-Header nach $INCDIR/vdr/plugins/$PLUGIN installieren" für wenig zielführend.

Klaus

Zitat von mini73

Natürlich kann man einfach den Header kopieren und dann ist's gut. Ich finde es einfach nur unkomfortabel.

Was? Das kopieren?

Zitat

Ich würde gerne das Service-Interface (die Header-Datei) aus dem Plugin herauslösen, es vom Plugin unabhängig machen.
Dann muss man nicht mehr kopieren, braucht nur eine Abhängigkeit auf das Service-Interface-Paket und gut.
Und das Service-Plugin bekommt auch eine Abhängigkeit auf das Service-Interface.

Das ist Debian-Denke. Dort ist es wohl beliebt einen Source in möglichst viele kleine Pakete zu teilen

Für Archlinux würde sowas definitiv in einem einzigen Paket enden.

Zitat

Zum Bauen eines Service-Nutzers muss das Service-Plugin nicht installiert sein, nur das Service-Interface. Das ist nichts anderes, als z.B. libjpeg, das von einem Plugin genutzt wird.
Dass der Service-Nutzer zusätzlich immer noch prüfen muss, ob das Service-Plugin installiert ist, ist klar (er bekommt dann beim Service-Aufruf ja sowieso ein "false" zurück).

libjpeg wird unter Archlinux auch komplett installiert, wenn dagegen gebaut wird.

Ich verstehe dich teilweise schon, aber ich finde man kann das mit dem "alles muss an seinem richtigen Ort sein" auch übertreiben. Soll heißen, dass dein Vorschlag in vielerlei Hinsicht auch genau das Gegenteil von dem erreichen könnte, was du erreichen wolltest.

• Bisher können Plugins in *beliebiger* Reihenfolge gebaut werden. Wenn du von globalen Headern ausgehen willst, dann muss eine genaue Reihenfolge eingehalten werden
• "make plugins" wird durch deinen Vorschlag wohl schlicht generell unmöglich, da hier keine Reihenfolge beim Bauen vorgesehen ist
• Wenn Plugin-Autoren anfangen auf die externen Header zu bestehen, dann ist die logische Folge bedingte Kompilierung und Parameter für's Kompilieren ("HAVE_EPGSEARCH=1", ....)

Zitat

Das ist Debian-Denke. Dort ist es wohl beliebt einen Source in möglichst viele kleine Pakete zu teilen

Für Archlinux würde sowas definitiv in einem einzigen Paket enden.

archlinux macht es halt falsch.
ich dachte da soll alles so "schlank" sein. jetzt installiert es absolut alles auf dem system ?
das ist doch totale scheisse sowas

Zitat von hotzenplotz5

archlinux macht es halt falsch.
ich dachte da soll alles so "schlank" sein. jetzt installiert es absolut alles auf dem system ?
das ist doch totale scheisse sowas

Es gibt sehr wohl das Konzept von "builddepends". Dabei wird aber das *ganze* Paket installiert und kann dann nach dem Bauen (da die Abhängigkeit dann nicht mehr von einem Paket benötigt wird) wieder komplett deinstalliert werden.

Für mich ist "fehlende dev-Pakete" mit ein Grund dafür, dass ich mich für Archlinux entschieden habe. Es nervt einfach sich erst zig dev-Pakete suchen zu müssen, wenn man mal eben einen Source bauen will. Die paar KB an Header-Dateien fallen auf heutigen Festplatten kaum mehr auf.

Zitat

Für mich ist "fehlende dev-Pakete" mit ein Grund dafür, dass ich mich für Archlinux entschieden habe. Es nervt einfach sich erst zig dev-Pakete suchen zu müssen, wenn man mal eben einen Source bauen will.

einverstanden.

aber warum willst du andere erziehen ?
warum nicht eine lösung finden die für alle "lager" funktioniert ?

was wäre denn so schlimm wenn für dich auch mit einer "neuen" version alles beim "alten" bleibt ?

Zitat von Mreimer

Es nervt einfach sich erst zig dev-Pakete suchen zu müssen, wenn man mal eben einen Source bauen will.

Das verstehe ich nicht. Du musst doch genauso die Pakete suchen. Das meint... Ob ich fürs bauen erstmal rausfinden muss das ich libusb-dev brauche oder das du rausfinden musst das du libusb brauchts, wo ist der Unterschied?

cu

Zitat von Keine_Ahnung

Das verstehe ich nicht. Du musst doch genauso die Pakete suchen. Das meint... Ob ich fürs bauen erstmal rausfinden muss das ich libusb-dev brauche oder das du rausfinden musst das du libusb brauchts, wo ist der Unterschied?

Ich verstehe es auch nicht, vor allen Dingen weil es Debian/Ubuntu einem so leicht macht das Paket zu finden. Wenn einem der Compiler eine fehlende Include-Datei um die Ohren wirft, dann einfach danach suchen:

apt-file search <include-datei>

und man hat das dev-Paket.

Gerald

Zitat von mini73

Oder, wenn man das nicht will, muss man beim Bauen außerhalb des vdr-Source -I/usr/include/vdr/plugins mitgeben und innerhalb dann -I../
Dann kann man, wie von dir geschrieben, den include so benutzen:

Code

#include <softhddevice/service.h>

Die erste Variante (mit vdr/plugins) finde ich aber schöner, da dann klar ist, dass es ein Header eines vdr-Plugins ist. Außerdem passt es dann auch besser zu den includes von vdr-Headern.
Es gibt ja z.B. Plugins, die genauso wie andere Programme heißen (z.B. femon). Da könnte es sonst Konflikte geben.

Ich wollte es schon nach /usr/include/vdr/plugins/*plugin*/service.h installieren.
Wenn du aber in den Sourcen "<vdr/plugins/*plugin*/service.h>" schreibst, dann funktioniert ohne installieren nichts.
Die Version mit "<*plugin*/service> hätte den schönen Vorteil das sie alles abdeckt.
Man kann eigene Version mitliefern, man kann aus den VDR Sourcen herausbauen und auch globale verwenden.
Ohne muß man über #defines arbeiten. z.b. "#include *PLUGIN*_SERVICE" oder erst installieren und dann bauen.

Mir persöhnlich ist es egal, beide Wege haben ihren Sinn und ich kann beide Seiten vollkommen verstehen.

Johns