[Announce] VDR developer version 1.7.35

  • Zu DVBAPI: Ich verstehe immernoch nicht, warum das nötig ist. Was passiert denn wenn der VDR gegen die Kernel-Header gebaut wird? Es ist doch nicht so, als würde sich stündlich die API ändern. Ich habe das vor einiger Zeit selbst mal getestet und das läuft problemlos.


    Der VDR wird gegen irgendwelche Kernel-Header gebaut, aber nicht gegen die des aktuellen Kernels. Die vom aktuellen Kernel liegen unter:
    /lib/modules/`uname -r`/build/usr/include/linux


    Auf einer Entwickler-Maschine kann man normalerweise mehrere Kernel booten. Da muß man die Kernel-Header frei konfigurieren können oder es müssen die Header vom laufenden Kernel verwendet werden.


    Der vom Compiler vordefinierte Pfad /usr/include/linux ist da einfach falsch.


    Gruß
    e9hack

  • Der VDR wird gegen irgendwelche Kernel-Header gebaut, aber nicht gegen die des aktuellen Kernels.


    Richtig, es ist im Prinzip eine Kopie der Kernel-Header gegen die die glibc kompiliert wurde.


    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

  • Ich habe gerade mal Version 10 des Patches ausprobiert.


    Wenn USE_FHS=1, dann will

    Code
    make plugins


    die Plugins nach /usr/local kopieren. Ich würde erwarten, daß die Plugins nur gebaut werden, nicht installiert. Ist das so gewollt?

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

  • Ist mir auch gerade aufgefallen. Habe vergessen das neue Make.config.template zu nehmen. Sorry.


    Trotzdem ist es so, wenn ich LCLBLD auskommentiere, beim make versucht wird, die Plugins nach /usr/local zu kopieren.

    SAT Hardware: Gibertini SE75 | DuraSat Dur-Line UK-24 | DD OctopusNET V2 Rack (Firmware 1.1.6) mit MaxS8
    Server: Asus M5A78L-M/USB3 | Sempron 145@2Cores | 8GB ECC RAM | PicoPSU | Debian Stretch 64Bit | VDR 2.4.5 mit SAT>IP, epgsearch, live, markad
    Clients: RaspberryPI 2/3 | Yocto Poky Linux (Openembedded) 3.2+git | Linux Kernel 5.4.72 | VDR 2.4.5 mit SAT>IP, RpiHDDevice, SkinDesigner, Remote, Extrecmenu, Femon, Mlist


    R.I.P: Gigaset M740 mit VDR von open7x0.org

  • Ja - aber ich glaube im Satz von glotzipapa fehlt ein "unterhalb"... ;)
    Wenn die LCLBLD definitionen nicht greifen, greifen die defaults aus Makefile, und da steht PREFIX auf /usr/local - LIBDIR wird im Makfile: LIBDIR ?= $(PREFIX)/lib/vdr.


    Ich habe noch ein paar Kleinigkeiten. In Make.config greift

    Code
    LIBDIR     ?= $(PLUGINDIR)/lib

    niemals, weil es ja schon in Makefile belegt wurde. Ich habe mir hier so geholfen:

    Code
    ifndef PLUGIN
    LIBDIR     = $(PLUGINDIR)/lib
    endif

    Wenn also LCLBLD gesetzt ist, und es kein Plugin ist, dann greift es - dann wird auch u.a. eine vdr.pc mit den Werten aus Make.config erzeugt.
    Außerdem gibst Du im Makefile zwar CINCLUDES (siehe auch die Überschreibe-Problematik mit = anstatt von += in meinem anderen Posting) ans vdr.pc weiter, aber nicht mehr im compiler-Aufruf für die targets. Ich habe es bei mir in die implizite Regel eingebaut:

    Code
    %.o: %.c
            $(CXX) $(CXXFLAGS) -c $(DEFINES) $(INCLUDES) $(CINCLUDES) $<

    Und damit die Compiler-Optionen für die Header vom Media-Build-Experimental auch in allen Compler-Aufrufen auftauchen (sonst übersetzt das nämlich nicht mit diesen Headern, habe ich in Make.config vor dem ifdev PLUGIN

    Code
    DVBDIR   = /usr/local/src/media_build_experimental/linux/include/uapi
    ifdef DVBDIR
    CFLAGS  += -D__user= -D__u8=uint8_t
    endif


    Verstehe das jetzt nicht falsch, wenn Du das Bauen gegen die Treiber-Header für überflüssig hälst, dann lass es ganz raus, dann müssen die INCLUDES aber auch nicht in die CFLAGS bzw. CXXFLAGS des vdr.pc. Ganz oder gar nicht - ich kann mit beidem leben und mich selbst drum kümmern, ich schreibe es hir nur, damit sich keiner wundert, warum er so schöne -Iblafasel/uapi Zeilen in vdr.pc hat, aber es nirgendwo ankommt... ;)


    Gruß, Ingo

  • Ach, einen habe ich noch - der geht aber eher an Plugin-Entwickler: mir war skinnopacity (mit neuem 1.7.35 Makefile) auf die Nase gefallen, weil dort das INCLUDES += im Makefile nicht mehr anzog (wegen des INCLUDES hinter make im Aufruf aus dem vdr-Makefile). Im Pluginverzeichnis bauen ging - "von oben" bauen ging nicht. Ein "override" vor INCLUDES wird für die PLUGIN-makefiles also vrrpflichtend, wenn der Aufruf so bleibt.


    Gruß, Ingo

  • Copperhead: Dein "INCLUDES=" sollte so aber eigentlich garnicht mehr beim Plugin ankommen... Schreibe mal ein "export" davor und teste dann nochmal. Variablen, die im Makefile definiert werden, sind nicht gleichbedeutend mit Umgebungsvariablen der Shell.


    Edit: Sehe gerade, dass es sich hier ja um einen puren Shell-Block handelt. Es sollte reichen das Semikolon nach dem

    Code
    INCLUDES="-I$(CWD)/include";

    wegzulassen. Variablenzuweisungen, die der nachfolgende Befehl im Environment haben soll, dürfen nicht als eigenständiger Befehl abgeschlossen (Semikolon) werden.

  • Kann irgendwer das von glotzipapa beschriebene Verhalten reproduzieren?


    Ich bin nicht sicher, ob es das selbe Problem ist, allerdings kann ich mit Version 12 des Makefile-Patches ebenfalls nichts installieren, bei mir will ein "make install" alles ins root-Verzeichnis installieren:

    Code
    make[1]: *** [install-lib] Fehler 1
    install -D libvdr-hello.so /libvdr-hello.so.1.7.33
    install: reguläre Datei „/libvdr-hello.so.1.7.33“ kann nicht angelegt werden: Keine Berechtigung
    make[1]: *** [install-lib] Fehler 1


    Die einzige Änderung, die ich in nach dem Kopieren der Make.config.template dann in der Make.config geändert habe, ist

    Code
    PREFIX   = /video

    da ich bisher die komplette Software und den Source unter /video installiert hatte und die libs dann nach /video/lib gewandert sind.

    VDR 2.6.5 Kodi 18.6-Leia
    Debian GNU/Linux 12, Thermaltake DH102, ASUS PRIME N100I-D, CineS2 V6.5.
    Plugins:
    radio v1.1.0-6-g468280f , trayopenng 1.0.2, fritzbox 1.5.3, cdplayer 1.2.4, femon v2.4.0-GIT-d366856, menuorg 0.5.2, extrecmenung v2.0.4, streamdev-server v0.6.3, cecremote 1.5.0, osd2web 0.3.2, softhddevice v2.0.6-GIT97e825d

  • In der Make.config.template findet sich noch

    Code
    VIDEODIR   = /video
    CONFDIR    = $(VIDEODIR)
    CACHEDIR   = $(VIDEODIR)
    RESDIR     = $(VIDEODIR)


    Damit wird alles direkt ins Video-Verzeichnis installiert. Vorher war da sowas wie

    Code
    VIDEODIR   = /video
    CONFDIR    = $(VIDEODIR)/conf
    CACHEDIR   = /var/cache/vdr
    RESDIR     = $(VIDEODIR)/share/vdr


    Ist das beabsichtigt, das jetzt alles direkt in das VIDEODIR installiert wird? Anstatt /var/cache/vdr wäre als Vorgabe aber sowas wie $(VIDEODIR)/cache sicherlich sinnvoller als die alten Einstellungen.

    VDR 2.6.5 Kodi 18.6-Leia
    Debian GNU/Linux 12, Thermaltake DH102, ASUS PRIME N100I-D, CineS2 V6.5.
    Plugins:
    radio v1.1.0-6-g468280f , trayopenng 1.0.2, fritzbox 1.5.3, cdplayer 1.2.4, femon v2.4.0-GIT-d366856, menuorg 0.5.2, extrecmenung v2.0.4, streamdev-server v0.6.3, cecremote 1.5.0, osd2web 0.3.2, softhddevice v2.0.6-GIT97e825d

  • Ich würde an der Stelle mal vorsichtig vorschlagen "LCLBLD" standardmäßig zu kommentieren. Diese Funktion wird eher von den wenigsten genutzt werden. Auch der Fall von "Ulrich Eckhardt" ist eher der Fall "FHS mit verbogenem PREFIX" als der sehr spezielle Fall "alles läuft aus dem Source-Verzeichnis".

  • Anstatt /var/cache/vdr wäre als Vorgabe aber sowas wie $(VIDEODIR)/cache sicherlich sinnvoller als die alten Einstellungen.


    Das per default die epg.data in $(VIDEODIR)/epg.data landet war ja schon immer so und ist anscheinden von Klaus so gewollt.
    Und wenn Plugins CacheDirectory(PLUGIN_NAME_I18N) nutzen dann landet es in $(VIDEODIR)/plugins/<pluginname>. Also kein Grund dort "cache" vorzuhängen, es hängt schon "plugins" vor.


    Also scheint "CACHEDIR = $(VIDEODIR)" als Default korrekt. FHS Nutzer werden es eh auf "CACHEDIR = /var/cache/vdr" setzen. Und "alles im Video Dir" Nutzer werden es halt so lassen wie es ist.


    cu

  • Da die INCLUDES in den Plugins mit += definiert werden geht es auch so.


    ...hätte ich bis gestern auch so gesehen. Vieleichtbhabe ich aber gerade einen Konoten im Hirn - ich sehe im Moment vor lauter ?=, +=, =, ifdef und ifndev den Wald nicht mehr... :( (ich glaube Du weisst noch viel besser, was ich meine...)


    Zwei Sachen laufen bei v12 jedenfalls min. Noch in die Wand: im Makefile wird in CINCLUDES immer noch DVBDIR 4 Zeilen später durch ein fehlendes '+' überschrieben. Und die Compiler-Optionen "-D__user= -D__u8=uint8_t" fehlen. Sorry.


    Gruß, Ingo


    P.S.: Ich teste im Moment nur LCLBLD ohne make install mit DVBDIR.
    P.P.S.: So groß, wie das Geschrei nach der Umstellung war, verstehe ich nicht, dass hier nicht viel mehr Leute versuch Copperhead zu unterstützen. Ich sehe es schon kommen: irgendwann kommt eine 1.7.36, und das große Heulen setzt wieder ein.
    P.P.P.S.: Je länger ich mir diese Makefiles ansehe, um so besset finde ich die Idee mit vdr.pc und Patches z.B. als Versionsvermerk in irgendeine config.h zu schreiben, und um so dankbarer bin ich Chopperhead, dass er sich da ran wagt!


  • ...hätte ich bis gestern auch so gesehen. Vieleichtbhabe ich aber gerade einen Konoten im Hirn - ich sehe im Moment vor lauter ?=, +=, =, ifdef und ifndev den Wald nicht mehr... :(


    6.7 The override Directive


    If a variable has been set with a command argument (see Overriding Variables), then ordinary assignments in the makefile are ignored. If you want to set the variable in the makefile even though it was set with a command argument, you can use an override directive, which is a line that looks like this:


    override variable = value


    or


    override variable := value


    To append more text to a variable defined on the command line, use:


    override variable += more text


    See Appending More Text to Variables.


    Variable assignments marked with the override flag have a higher priority than all other assignments, except another override. Subsequent assignments or appends to this variable which are not marked override will be ignored.


    The override directive was not invented for escalation in the war between makefiles and command arguments. It was invented so you can alter and add to values that the user specifies with command arguments.


    For example, suppose you always want the ‘-g’ switch when you run the C compiler, but you would like to allow the user to specify the other switches with a command argument just as usual. You could use this override directive:


    override CFLAGS += -g


    You can also use override directives with define directives. This is done as you might expect:


    override define foo =
    bar
    endef


    See Defining Multi-Line Variables. Quelle:GNU make


    Und wie gesagt: habe ich mir gestern raus gesucht, als skinnopacity in die Wand lief, hätte sonst auch gedacht, das += ohne override anhängt. Hier lernt man fürs Leben... ;)


    Gruß, Ingo

  • Anbei neuer Patch. Mal wieder ohne LCLBLD. Das stört mehr, als dass es hilft.


    Ich habe mir jetzt extra einen alten VDR 1.7.33 hergelegt. Danke an Mreimer für den Tipp.


    Mit der beiliegenden Make.config sollte das alte Verhalten wieder hergestellt sein. Ohne Make.config wird FHS kompatibel gebaut und installiert.


    Edit: Ich habe natürlich die Flags für media_build vergessen... Fu**

Jetzt mitmachen!

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