Makefile Probleme mit DESTDIR und Gen2VDR

  • Um es zu verdeutlichen:
    LCLBLD kann man eigentlich nur dann sinnvoll verwenden, wenn man verschiedene vdr-Versionen nebeneinander liegen hat und jedes für sich bauen und testen möchte. Dann macht man kein "make install", sondern ruf den vdr direkt aus dem build-Verzeichnis mit den Parametern auf, die man haben möchte. Und die Plugins bleiben dann unter ./PLUGINS/lib und werden von da geladen.


    Lars.

  • Auf den ersten Blick funktioniert es (bis auf das strippen):

    Code
    1. *** Plugin skinflatplus:
    2. $LIBDIR is [/usr/local/lib/vdr]
    3. $LIBDIR is [/usr/local/lib/vdr]
    4. g++ -Wall -march=native -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -c -DUSE_WAREAGLEICON -DPLUGIN_NAME_I18N='"skinflatplus"' -DVDRLOGO=\"vdrlogo_gen2vdr\" -DWIDGETFOLDER='"/usr/local/lib/vdr/skinflatplus/widgets"' -I/usr/local/src/vdr-2.1.6/include -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16 -I/usr/include/ImageMagick-6 -I/usr/include/freetype2 -o config.o config.c


    Ob das bei allen Plugins klappt muss sich noch rausstellen...


    https://dl.dropboxusercontent.…G2V_V5/log/build-vdr2.log


    Das muss sich der Chef mal ansehen ;)

    Mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe wird bestraft, wer eine nukleare Explosion verursacht. [StGB §328 Abs.: 2 Nr.: 3]

    ___

    Gen2VDR V7; VDR 2.4.0; Gehäuse: Antec Fusion V2 Black & iMon LCD (15c2:ffdc); Atric IR-Einschalter Rev. 4; Board: Intel DH77EB, Core i5-3550, Zotac GT630 Zone Edition, 4 GB RAM; DVB: 1x Digital Devices CineS2 Quad V6.5 [VDR-User #1540]

  • Das build_vdr Script macht in der Umgebung von Gen2VDR jede Menge Sinn, auch wenn das manche nicht verstehen wollen bzw koennen ;)
    Das eigentliche Problem an der Sache ist dass der Widgetpath anhand der "fixen Variablen" WIDGETFOLDER im Makefile zur Bauzeit gesetzt wird.
    Sowas macht man eigentlich nicht, denn damit wird es unmoeglich in ein "Uebergangsziel" zu bauen, was z.B. jeder Gentoo ebuild macht.
    Eine saubere Loesung waere das aendern des Makefiles, bzw das Einfuehren eines Paramters fuer das Plugin mit der Pfad zu den widgets.

  • Bitte nicht gentoo mit ebuilds und gen2vdr verwechseln...
    cu Peje

    PCs
  • Debian baut ja auch in ein Übergangsziel, und da funktioniert alles. Dass da DESTDIR zuerst noch falsch war, ist ja geklärt. Und dass man den Pfad per Parameter setzen können sollte, wäre ein nettes Feature. Aber warum ist bei gen2vdr LIBDIR zur Bauzeit nicht so gesetzt, wie es später sein wird? Das bedeutet dann ja auch, dass man den vdr immer mit dem Parameter für das LIBDIR starten müsste. Diese Variablen zur Bauzeit haben ja den Sinn, dass man sie bei einer Distribution schon so vorbelegen kann, dass sie sinnvoll sind. Überschreiben kann man sie ja immer noch.
    Das Makefile ist jetzt eigentlich in Ordnung, dann schlage ich vor, das Plugin um einen Parameter zu erweitern, so dass man den Pfad zur Laufzeit setzen kann. Das kann man leider noch nicht, richtig?


    Lars

  • Nochmal zur Klarstellung:
    Im aktuellen Makefile steht:
    DEFINES += -DWIDGETFOLDER='"$(DESTDIR)$(LIBDIR)/$(PLUGIN)/widgets"
    wozu wird dies benoetigt ? Die LIBDIR des VDR ist zur Laufzeit bekannt, es besteht meiner nach kein Bedarf daran diese dem Plugin zur Bauzeit mit zu geben, es soll diesen zur Laufzeit abfragen.
    P.S. Natuerlich gebe ich gerne fuer jeden der es besser weiss zu dass das Gen2VDR Buildscript Schrott ist und alle anderen alles richtig machen, schliesslich bauen und laufen mit dem Script auch nur > 200 Plugins und momentan nur dieses eine nicht ...

  • ... trotzdem hätte man das neue Makefile-System als Anlass nehmen können um zu schauen ob man davon nicht profitieren kann.


    Muss aber natürlich jeder selbst wissen, wie er am besten klarkommt.


    Ich baue meine Plugins schon seit eh und je außerhalb vom VDR. Zu Zeiten des alten Makefile-Systems waren dafür halt diverse Workarounds nötig.


    Unabhängig davon gebe ich helau recht. Das zusätzliche Define ist überflüssig. Das Plugin bekommt den Pfad zum LIBDIR vom VDR genannt. Ein Parameter zum Setzen wäre zwar kein Fehler, dennoch sollte der Default-Pfad zur Laufzeit zusammengebaut werden. Schon deshalb, dass ein in der VDR-Konfiguration gesetztes alternatives LIBDIR überhaupt berücksichtigt wird.

  • helau, wir sind uns einig, dass dort das DESTDIR nichts zu suchen hat, ich dachte, das wäre schon korrigiert.
    Lars


    Dort hat aber auch LIBDIR nichts zu suchen denn LIBDIR kann das Plugin zur Laufzeit rausbekommen, es macht keinen Sinn diesen fest einzukompilieren.
    Wenn er den Pfad unbedingt fest einkompilieren will sollte er einen eigenen Parameter, z.B. WIDGETFOLDER definieren welcher im plugins.mk gesetzt werden kann.
    Einen Pfad fest beim Kompilieren vorzugeben, welcher aber mittels Parameter zur Runtime umgebogen werden kann ist in meinen Augen nicht so ganz das Wahre.

  • Leute calm down :)
    Ich bin gewillt eine allgemeine Lösung anzubieten und es ist nicht bringt uns nicht weiter wenn hier scharfe Töne angeschlagen werden.


    DESTDIR ist im git raus, also es geht nur noch um LIBDIR.
    Das Define ist nötig da ich im Quellcode (meines Wissens) kein Zugriff auf das LIBDIR habe. Nicht so wie bei

    Code
    1. cPlugin::ConfigDirectory(PLUGIN_NAME_I18N))
    2. cPlugin::ResourceDirectory(PLUGIN_NAME_I18N))


    Wenn es doch irgendwie geht -> bitte Beispiel posten dann haben wir das Problem schon gelöst.
    helau : Ich benötige den Pfad da dorthin Scripte kopiert werden die vom Skin aufgerufen werden. Um Sie aufrufen zu können benötige ich den Pfad.
    Am Anfang hatte ich die Scripte im ConfigDirectory da die Scripte Ihre Ausgaben in Dateien im selben Ordner geschrieben haben. Und der Nutzer nur im ConfigDirectory Schreibrechte hat. Dies ist aber nun umgestellt so dass alle Ausgaben unter /tmp/ erfolgen.


    Ich habe kein Problem dieses Define umzubauen so das man dies überschreiben kann. Können damit dann alle leben, sprich ist dies dann auch eine Lösung für das Gen2Vdr build-script?


    Eigentlich wollte ich nun keinen Schritt zurück gehen aber wie sieht es mit dem ResourceDirectory aus? Ist wahrscheinlich nicht FHS konform aber man kann ja durchaus sagen das die Widgets Ressourcen vom Skin/Plugin sind.


    Grüße
    Martin

  • Eigentlich wollte ich nun keinen Schritt zurück gehen aber wie sieht es mit dem ResourceDirectory aus? Ist wahrscheinlich nicht FHS konform aber man kann ja durchaus sagen das die Widgets Ressourcen vom Skin/Plugin sind.

    Halte ich gar nichts von. Das sind ausführbare Dateien. Die gehören da nicht hin. Ich verstehe auch gar nicht, wo jetzt das Problem sein soll. Das DESTDIR bei den Defines raus und es passt doch alles...

  • Wäre es denn gut im Makefile folgendes zu tun: Es gibt einen Parameter WIDGETDIR welcher gesetzt werden kann (z.b. über plugins.mk), wenn dieser aber nicht gesetzt wurde dann nehme ich wie gehabt LIBDIR.
    Wenn das ok ist, könnte jemand mir die kurz im Makefile bauen?


    Copperhead : wie gesagt ich halte auch nichts davon wieder einen Schritt zurück zu gehen. Und wie gesagt DESTDIR ist raus aber das Problem ist derzeit LIBDIR.


    Grüße
    Martin

  • Halte ich gar nichts von. Das sind ausführbare Dateien. Die gehören da nicht hin. Ich verstehe auch gar nicht, wo jetzt das Problem sein soll. Das DESTDIR bei den Defines raus und es passt doch alles...


    Was meinst Du wozu VDR den Parameter -L hat ? Um die Libs auch wahlweise von woanders zu laden. Der Fehler ist nun dass das Plugin keine Chance hat diesen abzufragen ...

  • Der Parameter -L regelt aber auch, wo die Plugins liegen und die gehören zweifellos nach /usr/lib


    Ich halte von diesen Parametern auch nichts. Wo die Dateien liegen ist Sache des Distributors. Das geht den User nichts an, also reicht es aus dies beim Kompilieren zu ändern.

  • So müsste es ungefähr im Makefile aussehen (ungetestet, hab gerade keinen passenden Rechner zur Hand):


    Lars.

  • Der Parameter "-L" gibt an wo die Plugins liegen:


    Quote


    -L DIR, --lib=DIR search for plugins in DIR (default is %s)


    Also *kein* allgemeines "libdir" sondern der Pfad zu den Plugins. Von daher ist es schon korrekt, dass man diesen Pfad nicht ermitteln kann.


    Durchaus legitim ist es aber aus dem Makefile das LIBDIR als Referenz zu nutzen unter der Annahme, dass Distributoren das wohl auf ein valides "libdir" gesetzt haben.


    Das Define davor ist "Nice to have" aber nicht nötig. Ich würde, wenn das in dieser "PLGCFG" verwendet werden soll, aber den Plugin-Namen voranstellen. Also zum Beispiel "SKINFLAT_WIDGETDIR".