Reform der APIVERSION?

Quote from kls

APIVERSNUM muss auch in der neuen Variante gößer als 20609 sein.

Macht Sinn falls Plugins gezielt auf APIVERSNUM Preprozessor-Instruktionen hängen wollen.

Quote from kls

Die bisherige Möglichkeit, an einer solchen Stelle sofort sehen zu können, bei welcher VDR-Version sich das geändert hat, geht allerdings für künftige Werte von APIVERSNUM verloren.

Geht mit "git blame" recht einfach das auf ein Commit und so auch auf einen Zeitrahmen einzugrenzen.

Für mich klingt das nach einem verdammt guten Vorschlag. Passt damit auch besser zu anderen Libraries die nach interner Struktur versioniert werden und nicht nach der Version der Software, die die Library nutzt.

Damit ergäben sich Dateinamen wie etwa libvdr-osddemo.so.3.

APIVERSNUM braucht die 3 am Anfang, um Punkt 2 von oben zu erfüllen.

Die nächste API-Version sähe dann so aus:

Code
#define APIVERSION      "4"
#define APIVERSNUM   30004
Alle bisherigen #if APIVERSNUM < NNNNN Abfragen im Code bleiben davon unberührt.

Die bisherige Möglichkeit, an einer solchen Stelle sofort sehen zu können, bei welcher VDR-Version sich das geändert hat, geht allerdings für künftige Werte von APIVERSNUM verloren.

finde ich gut

Wäre eine Deprecation von APIVERSNUM denkbar? Was auch immer Plugins beim Übersetzen damit machen, ließe sich auch mit APIVERSION lösen (auch jetzt schon). Einzig die Verwendung innerhalb von SVDRP (wegen Peering?) müsste man sich mal genauer ansehen.

Quote from kls

Irgendwann wird VDRVERSNUM (momentan 20701) in den Bereich von APIVERSNUM kommen, aber das spielt sich nur Code-Intern ab und schlägt nicht auf die Dateinamen durch. Und bis dahin sind es noch mindestens 29 Versionen

Und dann geht die Diskussion wohl wieder von vorne los. Warum nicht gleich einen mutigen Schritt wagen: Nachdem heutzutage ja praktisch jeder Compiler 32-bittig ausgelegt ist, sind Integer-Werte (sieht man einmal vom – unter Linux wohl kaum genutzten – Datenmodell LP32 ab) im Bereich ±2³¹, also ca. ±2G. Damit könnten wir doch folgende Definition nutzen:

// the sole definition of the API version identifier
#define APIVERSIONID      3
// the derived constants
#define QUOTE( v )        #v
#define APISTRING( v )    QUOTE( v )
#define APIVERSION        APISTRING( APIVERSIONID )    // for backward compatibility
#define APIVERSBASE       1000000                      // or (1 << 28) for nice hex
#define APINUMBER( v )    (APIVERSBASE + (APIVERSIONID))
#define APIVERSNUM        APINUMBER( v )

Mit dieser Basis ist die kodierte Versionsnummer bestimmt auf "auf ewig" kollisionsfrei.

Das Konstrukt ist zwar ein bisschen umfangreicher als die zwei Zeilen bisher. Aber dafür hat man nur noch eine einzige Stelle, an der die API-Version definiert wird (somit also keine Redundanz) und kann man mit dem Makro APINUMBER() die APIVERSNUM unabhängig von ihrer internen Codierung in Präprozessor abfragen:

#include <stdio.h>

// the sole definition of the API version identifier
#define APIVERSIONID      3
// the derived constants
#define QUOTE( v )        #v
#define APISTRING( v )    QUOTE( v )
#define APIVERSION        APISTRING( APIVERSIONID )    // for backward compatibility
#define APIVERSBASE       1000000                      // or (1 << 28) for nice hex
#define APINUMBER( v )    (APIVERSBASE + (APIVERSIONID))
#define APIVERSNUM        APINUMBER( v )

int main()
{
    printf( "API version: \"%s\", %d (0x%08X)\n", APIVERSION, APIVERSNUM, APIVERSNUM );
#if APIVERSNUM >= APINUMBER( 3 )
    return 0;
#else
    return 1;
#endif
}

Liefert: API version: "3", 1000003 (0x000F4243), exit code 0

Dieser Ansatz ist zudem unabhängig davon, wie die Basisnummer gewählt ist, sofern sie nicht kleiner ist als die derzeitige APIVERSNUM, sprich: 20609. Dass die "kodierte" Versionsnummer (also Basis + API-Version) im Code nicht mehr in Erscheinung tritt, wäre ein weiterer Vorzug.

Was meint ihr?

Danke & Grüße

Stefan

[optional]

{VDR,API}VERSION könnte entfallen und durch Funktionen ersetzt werden, die aus {VDR,API}VERSNUM diese strings generieren.

Kein Grund, das zur compile time zu ermitteln, weil "ist ein String, damit sind Abfragen wie" (..) "nicht möglich.". Dann aber möglichst auch vom uppercase weg, um von macros/defines zu unterscheiden.

[/optional]

Was ich btw. nicht verstehe, wenn sich denn die API von 2.6.9 zu 2.7.1 so gar nicht geändert hat, wie können so viele Plugins 'fail to compile'? Ist es nicht eher doch so, dass die API hätte erhöht werden müssen, weil eben jene convenience macros nun weg sind? (Zusatzfrage, hätten die nicht per default einen build verhindern sollen, sobald etwas deprecated ist?)

Und würden nicht all diese Plugins vom 2.6.9, wenn denn nicht neu gebaut weil kompatibel zu 2.7.1, irgendwann einen segfault bringen müssen?

Mir wäre DEPRECATED_FOO_BAR ohne default lieber, Plugin maintainer/Entwickler hätten sofort die Info und nicht erst Jahre später. Da waren Änderungen von 2.4.2 bei..

#ifdef DEPRECATED_FOO_BAR

/* deprecated: see 2.4.2:HISTORY */

(..)

#endif

Quote from kls

Nur scheitert er bereits daran, dass {VDR,API}VERSION vom Makefile aus config.h extrahiert werden, das müssen also "echte" Strings sein.

Im Makefile des VDR findet sich diese Zeile:

APIVERSION = $(shell sed -ne '/define APIVERSION/s/^.*"\(.*\)".*$$/\1/p' config.h)

Bei dem vorgestellten Ansatz bräuchten wir künftig dann APIVERSIONID, denn die geht ja in die Namen der Shared Libs ein. Aus:

install -D $$l $(LIBDIR)/`basename $$l`.$(APIVERSION)

… wird künftig dann ja:

APIVERSIONID = $(shell sed -ne '/define APIVERSIONID/s/^.* \([0-9]*\).*$$/\1/p' config.h)
...
@echo "apiversion=$(APIVERSIONID)" >> $@
...
install -D $$l $(LIBDIR)/`basename $$l`.$(APIVERSIONID)

Und die Makefiles der Plugins benötigen genau diese APIVERSIONID aus vdr.pc, um den Namen der Shared Libs bei der Installation richtig zu setzen. Hier der Auszug aus dem Makefile des Plugins Live:

### The version number of VDR's plugin API:
APIVERSION := $(call PKGCFG,apiversion)
...
### Installed shared object file:
SOINST := $(DESTDIR)$(LIBDIR)/$(SOFILE).$(APIVERSION)

Wir hatten vor Jahren mal eine Phase, in der so gut wie alle Makefiles umgestellt werden mussten. Deshalb gehe ich davon aus, dass fast alle (wenn nicht sogar alle) sich die Information aus vdr.pc holen. Wenn nicht, wäre es Zeit, sie endlich auf den aktuellen Stand zu bringen.

Wenn mein Bild nicht ganz falsch ist, müsste der Ansatz doch machbar sein.

Quote from kls

{VDR,API}VERSION werden vom Makefile aus config.h extrahiert, das muss also ein String sein.

Ist kein Macro, was für compile time Vergleiche verwendet werden kann, wird überall nur als ein const char* verwendet.

#define VDRVERSION VdrVersion()

#define APIVERSION ApiVersion()

const char* VdrVersion(void) { /* using VDRVERSNUM */ (..) }

const char* ApiVersion(void) { /* using APIVERSNUM */ (..) }

Quote from kls

Jedes Mal, wenn es eine neue VDR-Version gibt, bei der die APIVERSION nicht hochgezählt wird (weil sich das API nicht geändert hat), kommt wieder das Argument, dass es "irritierend" sein, wenn VDRVERSION und APIVERSION sehr ähnlich, aber doch nicht gleich sind.

Ich habe mich da vermutlich zu verkürzt ausgedrückt - mir ging es vor allem darum, dass die API-Version praktische Kompatibilität signalisiert - und wenn die ohne Rücksicht auf die Werte von Defines wie DEPRECATED_SCHEDULE_GET_EVENT, DEPRECATED_SECTIONSYNCER_SYNC_REPEAT und DEPRECATED_CCONTROL unverändert bleibt, dann passt die API des gebauten VDR einfach nicht zu allen Plugins, die gegen den den VDR 2.6.9 gebaut wurden.

Quote from kls

Um das Ganze abzukürzen: kommt dein Vorschlag ohne Änderungen in bestehendem Plugin-Code aus?

Kann ich nicht einschätzen, denn ich kenne nur einige davon. Doch ich bin optimistisch:

• Neue Versionsabfragen können das neue Schema nutzen.
• Alte Versionsabfragen sollten weiterhin funktionieren.
• Makefiles nach dem "neuen" Schema (siehe oben) sollten passen.

Letztlich müsste man es wohl mal ausprobieren.

PS: Ich habe seinerzeit bei mir alle Makefiles konsequent auf das neue Schema umgestellt und nutze ausschließlich diese, selbst wenn Plugin-Maintainer ihre Makefiles nicht umgestellt oder meine damals geposteten Patches übernommen haben. Insofern kann ein Test bei mir lokal natürlich klappen, wohingegen ein abweichendes "originales" Makefile vielleicht an der Extraktion der Versionsnummer aus config.h scheitert. In diesem Fall würde ich aber eher dafür plädieren, die Makefiles alten Plugins endlich auf den aktuellen Stand zu bringen als eine Evolution daran scheitern zu lassen.

Quote from shofmann

In diesem Fall würde ich aber eher dafür plädieren, die Makefiles alten Plugins endlich auf den aktuellen Stand zu bringen als eine Evolution daran scheitern zu lassen.

Das setzt aber voraus das jemand die Arbeit macht. Ich unterstütze ja gerne und mittlerweile ist das zumindest in der Theorie einfacher denn je, weil man eigentlich für jedes Plugin auch ein Repo hätte. Aber dafür müsste auch jemand Pull-Requests auf https://github.com/vdr-projects anlegen, denn so gerne ich auch wollen würde: Die Zeit, hier Patches einzusammeln und in die verschiedenen Repos zu committen habe ich einfach nicht mehr.

Edit: Wobei ich absolut keinen Überblick habe ob es tatsächlich noch relevante Plugins mit altem Makefile gibt. Ich hatte selber mal ein paar angepasst die bei vdr4arch mitgebaut werden. Aber z.B. bei yaVDR sind ja viel mehr Plugins dabei. Vielleicht kann man sowas mit ein paar kreativen "greps" auswerten um zu wissen wie viele alte Makefiles noch im Umlauf sind?

Quote from shofmann

Letztlich müsste man es wohl mal ausprobieren.

OK, ich habe mal die folgenden Patches auf VDR 2.7.1 angewandt:

• 0001 Changed API version to new approach.zip

… und damit alles neu gebaut. Hier die vdr.pc:

pkgconfig/vdr.pc
vdrrootdir=/usr/local/vdr
bindir=/usr/local/vdr/bin
incdir=/usr/local/vdr/include
mandir=/usr/local/vdr/man
videodir=/srv/vdr/video
configdir=/usr/local/vdr/share/vdr
argsdir=/usr/local/vdr/share/vdr/conf.d
cachedir=/usr/local/vdr/cache
resdir=/usr/local/vdr/share
libdir=/usr/local/vdr/lib
locdir=/usr/local/vdr/locale
plgcfg=/usr/local/vdr/share/vdr/plugins.mk
apiversion=3
cflags=-g -O3 -Wall -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include
cxxflags=-g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include


Name: VDR
Description: Video Disk Recorder
URL: http://www.tvdr.de/
Version: 2.7.1
Cflags: ${cflags}

Mit den Makefiles nach neuem Stand lief alles problemlos durch. Hier die Binaries:

libvdr-conflictcheckonly.so.3
libvdr-devstatus.so.3
libvdr-dvbhddevice.so.3
libvdr-dvd.so.3
libvdr-dvdswitch.so.3
libvdr-epgsearchonly.so.3
libvdr-epgsearch.so.3
libvdr-epgtableid0.so.3
libvdr-extrecmenung.so.3
libvdr-femon.so.3
libvdr-hello.so.3
libvdr-live.so.3
libvdr-markad.so.3
libvdr-mlist.so.3
libvdr-osd2web.so.3
libvdr-osddemo.so.3
libvdr-osdteletext.so.3
libvdr-pictures.so.3
libvdr-quickepgsearch.so.3
libvdr-recsearch.so.3
libvdr-remote.so.3
libvdr-satip.so.3
libvdr-screenshot.so.3
libvdr-skincurses.so.3
libvdr-skinelchihd.so.3
libvdr-skinenigmang.so.3
libvdr-skinlcarsng.so.3
libvdr-skinnopacity.so.3
libvdr-status.so.3
libvdr-streamdev-client.so.3
libvdr-streamdev-server.so.3
libvdr-svccli.so.3
libvdr-svcsvr.so.3
libvdr-svdrpdemo.so.3
libvdr-systeminfo.so.3
libvdr-undelete.so.3
libvdr-xineliboutput.so.3
libxineliboutput-fbfe.so.2.2.0
libxineliboutput-sxfe.so.2.2.0
libxineliboutput-wlfe.so.2.2.0

Bleibt anzumerken, dass xineliboutput schon ewig libxineliboutput-*.so.2.2.0 installiert, hier zum Beispiel beim VDR 2.6.7:

...
libvdr-undelete.so.2.6.7
libvdr-xineliboutput.so.2.6.7
libxineliboutput-fbfe.so.2.2.0
libxineliboutput-sxfe.so.2.2.0
libxineliboutput-wlfe.so.2.2.0

Das hat also nichts mit der Änderung zu tun.

PS: Einige Makefiles enthalten noch einen Kompatibilitätsabschnitt, der sich – wenn die APIVERSION[/tt nicht per pkgconfig abrufbar ist – diese über die Verzeichnishierarchie aus den VDR-Headern extrahiert. Diese Abschnitte waren hier inaktiv, sollten entweder entfernt oder müssten bezüglich der Extraktion der [tt]APIVERSION – ähnlich wie im obigen Patch – nachgezogen werden.

Quote from M-Reimer

Die Zeit, hier Patches einzusammeln und in die verschiedenen Repos zu committen habe ich einfach nicht mehr.

das kann ich wunderbar verstehen - aber weshalb nicht einfach alte zoepfe abschneiden.

bin ueberzeugt, dass jede menge plugins irgendwie am leben gehalten werden,

damit sie compilieren und starten, aber genutzt werden sie von niemandem mehr.

daher alles, was ab vdr 2.4.2, innerhalb der der zu diskutierenden zeit (2 monaten) nicht mehr baut

und funktioniert, ab in die tonne. da wird viel rausfallen

das wuerde auch vdr-anfaengern entgegenkommen

Super, dass schon so viele Experten diese Diskussion hier führen und Laien wie ich mitlesen können.

Obwohl mir noch ein paar bekannte Namen abgehen, bin ich sicher, ihr werdet euch diesmal auf eine Variante einigen, die dann von "allen" Experten/Maintainern auch für gut befunden wird.

Danke jedenfalls für euren regen Einsatz und die spannende Diskussion!!!