Ein paar Verständnisfragen zum "neuen" Buildsystem

    Hallo Zusammen,


    nachdem ich es endlich geschafft habe, alle bei mir installierten Plugins auf das neue Buildsystem umzustellen, bin ich nun dabei auch meine Build-, und Installscripts umzustellen.


    Nun ist mir aufgefallen, dass ein "make" im $VDRDIR, zwar alles, incl. den Plugins baut und die *.so Files auch gleich nach "$VDRDIR/PLUGINS/lib" kopiert, aber ein "make install" jedoch nur das VDR Binary nach $BINDIR kopiert.


    Ist das so gewollt? Bug oder Feature?


    Sollte ein "make install", oder meinetwegen auch ein "make install-plugins" die Plugins nicht von "$VDRDIR/PLUGINS/lib" nach "$LIBDIR/plugins" kopieren?

    Das "make install" wird vom VDR-Makefile nur durchgereicht.


    Das Plugin-Makefile selber muss also fähig sein die Installation durchzuführen. Gerade einige der ersten "Reparatur-Patches" für Plugin-Makefiles hatten noch keine funktionierende "install"-Routine.


    Beispiel direkt aus dem VDR-Source:
    http://projects.vdr-developer.…dvbhddevice/Makefile#n108


    Während der Sinn bei ganz einfachen Plugins, die nur ihr ".so" platzieren, noch nicht ganz einleuchten mag macht das bei komplexeren Plugins durchaus Sinn:


    http://projects.vdr-developer.…ty.git/tree/Makefile#n133


    Die vielen Schritte, die hier vom "make install" abgenommen werden mussten "damals" noch alle manuell durchgeführt werden.


    Da die Plugin-Makefiles in sich abgeschlossen sind musst du außerdem nicht aus dem VDR-Source raus bauen. Einfach sicherstellen, dass der VDR installiert ist und dann von überall wo du willst einfach im Plugin-Source mit "make" und "make install" (ggf. "make DESTDIR=... install") kompilieren und installieren.

    Ich verstehe den Teil sehr gut, der für mich relevant ist. Und der ist, dass Plugins jetzt nicht mehr im VDR-Sourcetree gebaut werden müssen. Endlich "make" und "make install" direkt im Plugin-Source. Und zwar wo auch immer ich das Plugin hinentpackt habe.


    Die Rückwärtskompatibilität wurde damals bei der Einführung lange diskutiert, mehrfach getestet, optimiert und zuletzt von denen, die sie benötigen, auch für gut befunden. Ich selber habe diesen Teil aber nie ausprobiert. Schon möglich, dass du einen Fehler gefunden hast. Aber auch möglich, dass z.B. deine Make.config für die Fehlfunktion verantwortlich ist. Ein paar mehr Infos (z.B. komplette Ausgabe von einem "make install-plugins" und die Make.config) könnten da helfen.

    Man möge mich berichtigen wenn ich falsch liege, aber für mich sieht das so aus als würde dein VDR die Plugins, so wie du das konfiguriert hast, direkt unter /usr/local/src/vdr-2.1.6/PLUGINS/lib/ erwarten. Demnach läuft schon alles so wie du es haben willst. Wenn du die Plugins wo anders möchtest, dann müsstest du das "LIBDIR" an die entsprechende Stelle konfigurieren und dann nochmal testen.

    Man möge mich berichtigen wenn ich falsch liege, aber das:


    Code
    # Default directories (adjust as necessary or desired):
PREFIX    = /usr
VDRDIR    = $(PREFIX)/local/src/VDR
BINDIR    = $(PREFIX)/bin
#INCDIR    = $(PREFIX)/include
#LIBDIR    = $(PREFIX)/lib/vdr
...


    bedeudet doch, dass der VDR die *.so nach "$(PREFIX)/lib/vdr" kopieren sollte??

    Warum denn das????


    "Default directories (adjust as necessary or desired" <-- bedeutet doch wohl, "bei Bedarf"!


    Anders gesagt, wird das "Kommentarzeichen" nicht entfernt, wird "$(PREFIX)/lib/vdr" genommen.

    Falsch. Damit überschreibst du unter anderem auch "LIBDIR" und das wirkt sich auch auf die Installation aus.


    Gebaut wird immer im VDR-Sourcetree. Verteilt wird erst mit "make install". Die Idee hinter "LCLBLD" ist, dass auch bei "make install" nicht verteilt wird.


    Gedacht war das für diejenigen, die den VDR auch im Betrieb im Source-Verzeichnis zusammenhalten wollen. Installiert wird dann eigentlich garnichts. Nur "make" und direkt danach mit "./vdr" ausführen.


    Ich stimme dir in sofern zu, dass der Kommentar über diesem "LCLBLD"-Block so irreführend ist... Vermutlich willst du garkein "LCLBLD". Stelle das mal ab.

    Bei "neuen Plugins" nicht mehr. Was willst du denn jetzt? Plugins in "PLUGINS/lib" oder direkt am Ziel? Wenn sie am Ziel sein sollen, dann ignoriere einfach wie die Plugins das intern handhaben. Sie werden am Ziel ankommen und das ist wichtig.

    Das macht durchaus Sinn. Die Plugins bauen in ihrem eigenen Source-Tree (.so liegt also nach dem Bauen im Plugin-Sourcedir). Erst wenn ein "install" kommt wird an's Ziel kopiert. Und eben direkt an's Ziel und nicht erst unnötigerweise nach PLUGINS/lib oder woauchimmer hin. Nehme dir ein beliebiges anderes Programm abseits vom VDR-Universum und du wirst feststellen, dass dieses Verhalten durchaus gängig ist.


    Warum brauchst du die Plugin-so-Dateien an einem Ort an dem der VDR selbst garnicht danach sucht?

    Welchen Sinn sollte es denn machen, die Sourcen eines VDR Plugins woanders zu haben, als im VDR Source Tree??
    Zum Einen brauchen die Plugins, so oder so, die VDR Sourcen und zum Anderem werden sie auch nur dann mit "make" aus dem $VDRDIR mitgebaut.

    Die VDR-Sourcen werden eben nicht gebraucht. Wenn du den VDR installierst, dann installiert er auch seine Header mit. Die reichen aus um Plugins bauen zu können.


    Da der VDR sich auch sauber beim "pkg-config"-System einträgt finden die Plugins die VDR-Header von überall aus. Sie finden auch alle anderen wichtigen Verzeichnisse ganz ohne dafür eine "Make.config" oder ähnliches zu brauchen. Der VDR muss nur installiert sein. Eben so wie wenn ein Programm von "libpng" oder ähnlichen Libraries abhängig ist. Die kann man ja auch überall bauen und muss sie nicht an eine ganz bestimmte Position ablegen.


    Der einzige Grund für ein Platzieren im VDR-Source wäre in der Tat, dass sie bei "make" mitgebaut werden. Das funktioniert auch bestens. Nur ein "PLUGINS/lib" braucht es dafür eben nicht mehr. Für Distributoren ist das aber keine wirkliche Option weil da ohnehin jedes Plugin einzeln paketiert wird. Hier ist es ein großer Pluspunkt wenn man den Plugin-Source einfach dort bauen kann wo man ihn ausgepackt hat.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden