[Announce] VDR developer version 1.7.35


    Sollten sie aber (dazu muß das Makefile aber noch entsprechend erweitert werden).


    Klaus

    Was ist hier mit? [Announce] VDR developer version 1.7.35


    Klaus?


    Falls nicht so richtig klar wird worauf ich hinaus will, ich mache heute Abend mal nen Beispiel. Ich danke es würde alle Problme lösen wenn die "im Source starter" damit glücklich wären.


    cu

    Zitat von nvertigo


    ...baust Du mit den Treibern von Ufo? Dann fehelen da die richtigen includes und die CFLAGS.


    Das paßt schon. Das Problem ist, ich möchte, wenn alles compiliert wurde, auch installieren können. Dazu setze ich INCDIR auf das Installationsverzeichnis, wo die Include-Dateien landen sollen. Das ist beim compilieren noch leer. Es wird aber per -I$(INCDIR) dem Compiler mitgegeben, der findet dann nichts. Irgendwie wird im Makefile ein zusätzliches Verzeichnis dazugebastelt. Da kommt als Parameter dann -I/include raus. Das Verzeichnis gibts aber auch nicht.


    Gruß
    e9hack

    Zitat von Keine_Ahnung

    Was ist hier mit? [Announce] VDR developer version 1.7.35


    Klaus?


    Falls nicht so richtig klar wird worauf ich hinaus will, ich mache heute Abend mal nen Beispiel. Ich danke es würde alle Problme lösen wenn die "im Source starter" damit glücklich wären.


    Wie der Parameter heißt, mit dem man das "im Source-Tree-Bauen" aktiviert, ist mir mehr oder weniger egal. Wie bereits gesagt darf es ja auch ruhig der Default sein, daß "make" nur übersetzt und "make install" installiert. Aber wenn der "im Source-Tree-Bauen" Schalter aktiviert ist, dann möchte ich die *.so-Dateien in ./PLUGINS/lib und die *.mo-Dateien in ./locale haben - wie die dort hinkommen ist mir egal. Das muß nicht durch das Plugin-Makefile passieren, es kann durchaus auch im VDR Makefile geschehen. Schließlich entsteht das bzw. entstehen die *.so-Files im Plugin-Verzeichnis (./PLUGINS/src/name) und die *.mo-Dateien im Unterverzeichnis "po" (./PLUGINS/src/name/po). Das VDR-Makefiles kann sie also ruhig explizit von dort holen und an die gewünschte Stelle kopieren. Wenn ein Plugin sich nicht an diese (durch "newplugin" vorgegebene) Konvention hält, dann kann es hier eben nicht mitspielen. Das ist mir dann auch egal.


    Klaus

    Zitat von Copperhead

    e9hack: Bei mir funktionierts.


    kls: Ja dann weiß ich auch nicht. Langsam kotzt mich das ganze richtig an.


    Tja, du hast die "Büchse der Pandora" geöffnet - jetzt mußt du sie auch wieder schließen ;)


    Zitat


    Keiner will auf die Variante verzichten, weil es ja schon immer so war. Allen kann ich es aber auch nicht recht machen.


    Also mir reicht es, wenn die "im Source-Tree-Bauen" Methode funktioniert ;-).
    Aber Spaß beiseite, ich finde es schon auch gut und sinnvoll, wenn künftig jemand, der einen (ins System) installierten VDR betreibt, ein beliebiges Plugin downloaden, es irgendwo übersetzen und einfach installieren kann.


    Klaus

    Mein Ziel ist es die Möglickeit zu haben (1 u 4 aus anderem Post von heute):


    1.) "make" im VDR Source-Verzeichnis soll zur Folge haben, daß


    - VDR selber compiliert wird
    - alle Plugins in ./PLUGINS/src compiliert werden und ggf. ihre *.mo-Files erzeugen
    - alle *.so-Files der Plugins nach ./PLUGINS/lib kopiert werden (mit APIVERSION)
    - alle *.mo-Files (Plugins und VDR) nach ./locale kopiert werden (an die richtigen Stellen)
    - vdr.pc aus VDR Source-Verzeichnis verwendet wird
    - vdr.pc über cflags und cxxflags auf VDR eigene Include-dateien innerhalb des VDR Source-Verzeichnisses zeigt


    4.) "make install" im VDR Source-Verzeichnis soll zur Folge haben, daß


    - alle Dateien (vdr, *.so mit API-Version, *.mo, ..) die zum Starten des VDR notwendig sind, in vordefinierten Verzeichnissen installiert werden
    - wenn Verzeichnisse für Include bzw. vdr.pc definiert sind, auch Include-Dateien und vdr.pc installiert werden
    (benötigt man nicht, wenn es keine Plugins außerhalb des VDR Source-Verzeichnisses gibt)
    - vdr.pc aus VDR Source-Verzeichnis verwendet wird



    Mit der aktuellen Grundstruktur der Plugin-Makefiles kann das nicht funktionieren. Es werden zwei Install-Ziele bzw. -Optionen benötigt. Einmal nach <VDR-Dir>/PLUGINS/libs bzw. <VDR-Dir>/locale und die ander Variante ist LIBDIR bzw. LOCDIR. Man könnte die Plugin-Makefiles so ändern, daß LIBDIR und LOCDIR nicht aus vdr.pc gelesen werden, wenn sie bereits definiert sind. Aus dem VDR Makefile werden dann für 'make' die Plugin-Makefiles per
    'make -C ./PLUGINS/src/<Plugin-Dir z.B. hello> VDRDIR=<VDR-Dir> LOCDIR=<VDR-Dir>/locale LIBDIR=<VDR-Dir>/PLUGINS/lib install'
    aufgerufen. Für 'make install' werden die Plugin-Makefiles per
    'make -C ./PLUGINS/src/hello VDRDIR=<VDR-Dir> install'
    aufgerufen, ohne die Install-Verzeichnisse zu überschreiben. Diese werden dann aus vdr.pc ausgelesen.


    Das könnte man auch für CFLAGS und CXXFLAGS machen, um die richtigen Include-Pfade zu setzen, wenn INCDIR nicht <VDR-Dir>/include ist.


    Die anderen Varianten aus meinem Post sollten damit auch funktinieren.


    Gruß
    e9hack

    Zitat von kls


    dann möchte ich die *.so-Dateien in ./PLUGINS/lib und die *.mo-Dateien in ./locale haben


    Also diese Pfade sind fix und nicht verhandelbar?
    Oder dürfen die Plugins auch (z.B. halt irgendwo unter ./<wählbarer Name (ausser "PLUGINS")>/...) in ./inst/usr/lib/vdr (anstelle von ./PLUGINS/lib) landen?


    Nur um diese Frage jetzt mal definitiv zu klären.


    cu

    Bleibt die Frage, ob es nicht am einfachsten ist, genau das zu erreichen, wenn man die Verzeichnisse einfach "in das VDR-Verzeichnis" reinkonfiguriert. Wenn ich mir die aktuellen Defaults im VDR-Makefile so anschaue, dann ist das aktuell sogar bereits genau so gelöst. Und dann statt "make" halt "make install" zum Bauen.


    Würde bedeuten, dass die ".so" für die Plugins erst im Plugin-Sourceverzeichnis erstellt und danach durch das "install-Target" nach PLUGINS/lib installiert werden... Sonderbehandlung für den Fall "Pfade zeigen in den VDR-Sourcetree" also raus und auch beim "lokalen Build" in Zukunft statt "make" ein "make install" ausführen.


    Problem generell dabei für jede Lösung, die relative Pfade erzwingen will: Relative Pfade in der "vdr.pc" funktionieren nicht, da diese relativ zum VDR-Sourceverzeichnis sind und beim Plugin-Bauen deshalb an die von Plugin-Makefile-Sicht falsche Stelle zeigen. Sie funktionieren auch dann nicht, wenn man sie mutwillig auf "Plugin-Sicht" verbiegt, da dann Plugins mit Unterverzeichnissen wieder das Nachsehen haben.


    Deshalb würde ich von relativen Pfaden absehen wollen. Mir scheint das doch ein sehr exotischer Anwendungsfall zu sein der von jedermann ganz einfach so erschlagen werden kann, dass er seine NFS-Mounts für den "VDR-Source" einfach auf jedem System an die gleiche Stelle einhängt. Und wenn das aus irgendeinem Grund unmöglich ist, dann halt den VDR-Source aus dem NFS-Mount z.B. nach /opt/vdr symlinken und dann über den Symlink aufrufen.


    Wenn ein "inplace-Build" aber garkeine Änderungen am laufenden System machen darf, müsste man noch sicherstellen, dass die "vdr.pc" dann auch irgendwo im VDR-Sourcetree abgelegt wird. Meinetwegen nach "$(CWD)".

    Zitat von Mreimer

    Bleibt die Frage, ob es nicht am einfachsten ist, genau das zu erreichen, wenn man die Verzeichnisse einfach "in das VDR-Verzeichnis" reinkonfiguriert. Wenn ich mir die aktuellen Defaults im VDR-Makefile so anschaue, dann ist das aktuell sogar bereits genau so gelöst. Und dann statt "make" halt "make install" zum Bauen.


    Würde bedeuten, dass die ".so" für die Plugins erst im Plugin-Sourceverzeichnis erstellt und danach durch das "install-Target" nach PLUGINS/lib installiert werden... Sonderbehandlung für den Fall "Pfade zeigen in den VDR-Sourcetree" also raus und auch beim "lokalen Build" in Zukunft statt "make" ein "make install" ausführen.


    Das ist ja auch meine Idee.


    Einfach DESTDIR auf ./inst setzen und dann installiert der sich bei install ins VDR Quellverzeichnis.


    Zitat von Mreimer

    Deshalb würde ich von relativen Pfaden absehen wollen. Mir scheint das doch ein sehr exotischer Anwendungsfall zu sein der von jedermann ganz einfach so erschlagen werden kann, dass er seine NFS-Mounts für den "VDR-Source" einfach auf jedem System an die gleiche Stelle einhängt.


    Ist aber bei absoluten Pfaden (und unterschiedlichen Einhängepunkten) auch kein Problem, denn bei jedem make Aufruf wird als erstes die vdr.pc mit den korrekten absoluten Pfaden neu erstellt.


    Oder man erstellt für den "in place" build relative Pfade im vdr.pc und bei den anderen Build die absoluten.


    cu

    DESTDIR hilft dir hier nicht. Das wirkt nur auf die "install-Methode", wird aber nicht einkompiliert. Die Plugins werden also weiterhin am "richtigen Pfad" erwartet und nicht in deinem DESTDIR.


    Relative Pfade gehen deshalb nicht, weil die Plugin-Makefiles ihre Pfade ja auch via "pkg-config" abrufen. Aus Plugin-Makefile-Sicht passen die aus VDR-Makefile-Sicht erstellten relativen Pfade aber nicht. "make install" des Plugins würde also bei einem LIBDIR von "./PLUGINS/lib" nach "./PLUGINS/src/$PLUGINNAME/PLUGINS/lib" installieren wollen.

    Zitat von Mreimer

    DESTDIR hilft dir hier nicht. Das wirkt nur auf die "install-Methode", wird aber nicht einkompiliert. Die Plugins werden also weiterhin am "richtigen Pfad" erwartet und nicht in deinem DESTDIR.


    Jup, das soll auch nur bei "install" wirken, bei "make all" soll nix kopiert werden. Kopiert wird in "install".



    Edit ich bauchte einwenig um das zu verstehen ;) : Ja, das stimmt. Fürs in-place Starten muss natürlich die runvdr die korrekten relativen Verzeichnisse per Kommandozeile setzen.


    Zitat von Mreimer

    Relative Pfade gehen deshalb nicht, weil die Plugin-Makefiles ihre Pfade ja auch via "pkg-config" abrufen. Aus Plugin-Makefile-Sicht passen die aus VDR-Makefile-Sicht erstellten relativen Pfade aber nicht.


    Doch, wenn beim in-place Build die Pfade korrekt relativ sind passen die fürs Plugin.


    Also das in der vdr.pc (sofern sie im VDR verzeichnis liegt und ein "make plugins" gemacht wird) würde passen
    ---
    cflags=-g -O3 -Wall -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I../../../include
    ---


    Klar, bei der Installation müssen dort absolute Pfade rein.


    cu

    Ist es eigentlich normal, daß in einem Makefile keine Manipulation von Konstanten zulässig ist, wenn diese von extern übergeben wurden?


    z.B. steht im Makefile

    Code
    CFLAGS += -fPIC


all:
	@echo "CFLAGS=$(CFLAGS)"


    Aufgerufen wird mit 'make' oder 'make CFLAGS=-O3', als Resultat erhält man


    CFLAGS=-fPIC


    oder


    CFLAGS=-O3


    Gruß
    e9hack

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden