Plugins mit altem Makefile - Sammlung

Zitat von shofmann

Klaus,

danke für den Hinweis. Aus der Beschreibung in Make.config.template:

Code

# Use 'make LCLBLD=1' to build locale and plugin files under the source directory

würde ich aber verstehen, dass ich LCLBLD=1 setzen muss, wenn ich den VDR samt Plugins ausschließlich von innerhalb des VDR-Sourcebaums (also ohne weiteres Umkopieren der produzierten Files im Rahmen eines Installatiosnvorgangs) betreiben will. Was bei mir aber nicht der Fall ist, da ich die produzierten Files alle von den Source-Verzeichnissen nach /usr/local/vdr-1.7.xy in eine entsprechende Baumstruktur kopiere (siehe meine vdr.pc weiter oben).

Zumal im VDR-Makefile LCLBLD nur dazu führt, dass nach dem Bauen des Plugins eine Mini-Installation nach PLUGINS/lib und PLUGINS/locale durchgeführt wird. Sonst passiert nichts weiter...

Oder habe ich die Bedeutung von LCLBLD komplett falsch interpretiert? Dein Hinweis würde ja das genaue Gegenteil meiner Interpretation nahelegen.

Alles anzeigen

Im Wesentlichen sieht das VDR-Make-Konzept vor, daß man entweder alles nach FHS installiert (Default) oder mit Make.config und LCLBLD=1 alles unterhalb des VDR-Source-Verzeichnisses baut.
Wer irgendwas "dazwischen" haben will, der muß halt schauen, wie er es hinbekommt. Man kann nicht alle nur erdenklichen Fälle automatisieren

Klaus

Früher hatte ich immer im Plugin-Verzeichnis ein beherztes "make all" ausgeführt, wenn ich nur ein Plugin kompilieren wollte. Das Plugin wurde dann nach PLUGINS/lib kopiert. Geht das heute nicht mehr?

Den VDR selbst hatte ich mit make LCLBLD=1 genaut. Das Plugin war skinnopycity. Liegts am makefile des Plugins oder an den neuen VDR-Makefiles? hatte das dann nicht weiter untersucht.

Wenn du den VDR mit "make install" installiert hast, dann kannst du Plugins ab jetzt mit "make" gefolgt von "make install" installieren. Dabei ist es bei den neuen Makefiles egal wohin der Plugin-Source entpackt wurde.

Kann vielleicht jemand arghdirector und burn fixen?

Zitat von shofmann

Hi Christian,

also ich habe DVBDIR überhaupt nicht gesetzt, bei mir liegt es aber unter /usr/local/src/dvb mit symlink auf media_build_experimental, wie in der Anleitung im VDR-Wiki beschrieben. Und ich habe auch /usr/local/src/dvb/linux/include/linux/compiler.h auf /usr/src/linux-headers-$(uname -r)/include/linux/compiler.h verlinkt. Damit übersetzt StreamDev mit dem geposteten Makefile ohne Murren.

Ohne da wirklich Genaues zu wissen, würde ich vielleicht mal versuchen, DVBDIR wegzulassen oder nur auf /usr/src/media_build_experimental zu setzen. Danach unbedingt alle .dependencies-Dateien im VDR-Baum entfernen (die werden beim nächsten Mal dann neu aufgebaut):

Code

find . -name ".dependencies" | xargs rm

Möglicherweise rühren deine Fehlermeldungen von veralteten Einträgen in diesen .dependencies her...

Toi, toi, toi
Stefan

Alles anzeigen

An den alten Dependencies lag es nicht. (Gibt es um die zu löschen nicht auch das make distclean?). Die Aussage das man DVBDIR in der Make.config setzen soll stammt von UFO. In der alten Make.config war das bisher auch immer so und es gab einen auskommentierte Zeile. Die ist allerding im neuen Makefile nicht da und man muss die ganze Zeile nachtragen.

Ich werde am Wochenende mal deinen Weg probieren. Evtl. äußern sich KLS oder UFO mal dazu wie der "offizielle" Weg sein soll die neueren DVB Header einzubinden.

Gruß,
Christian

Zitat von CyberChris

Evtl. äußern sich KLS oder UFO mal dazu wie der "offizielle" Weg sein soll die neueren DVB Header einzubinden.

Die Vorlage für DVBDIR in Make.config.template ist in der 1.7.36 leider "untergegangen".
Wird in der 1.7.37 wieder drin sein:

--- Make.config.template        2013/01/12 13:50:17     2.16
+++ Make.config.template        2013/01/23 10:47:28     2.17
@@ -34,6 +34,7 @@
 #MANDIR    = $(PREFIX)/share/man
 #PCDIR     = $(PREFIX)/lib/pkgconfig
 #RESDIR    = $(PREFIX)/share/vdr
+#DVBDIR    = /usr/src/v4l-dvb/linux
 
 #VIDEODIR  = /srv/vdr/video
 #CONFDIR   = /var/lib/vdr

Wobei es viellelicht gleich besser was mit .../linux/include/uapi sein sollte, oder?

Klaus

Zitat von kls

Die Vorlage für DVBDIR in Make.config.template ist in der 1.7.36 leider "untergegangen".
Wird in der 1.7.37 wieder drin sein:

Diff

--- Make.config.template        2013/01/12 13:50:17     2.16
+++ Make.config.template        2013/01/23 10:47:28     2.17
@@ -34,6 +34,7 @@
 #MANDIR    = $(PREFIX)/share/man
 #PCDIR     = $(PREFIX)/lib/pkgconfig
 #RESDIR    = $(PREFIX)/share/vdr
+#DVBDIR    = /usr/src/v4l-dvb/linux
 
 #VIDEODIR  = /srv/vdr/video
 #CONFDIR   = /var/lib/vdr

Wobei es viellelicht gleich besser was mit .../linux/include/uapi sein sollte, oder?

Ja, denn Userspace-Header liegen bei allen neuen Treibern unter "uapi".

CU
Oliver

Zitat von UFO

Die Vorlage für DVBDIR in Make.config.template ist in der 1.7.36 leider "untergegangen".

Dann finde ich es spannend, dass der VDR sich auch ohne diese Include-Files problemlos übersetzen lässt. Werden die überhaupt gebraucht, oder benötigen nur spezielle Video-Treiber diese? Das DvbHdDevice benötigt sie offensichtlich nicht...

Stefan

It depends - wenn deine Kernel-Sourcen aktuelle genug sind, dann nciht.

Andere Frage in die Runde:

ich hab zwei etwas ältere Systeme, auf denen ich zum Bauen des vdr __KERNEL_STRICT_NAMES benötige - ich habe das in der Make.config auch hinterlegt - das Plugin softsddevice braucht es aber nochmal separat (in dessen Makefile) spezifiziert - ist doch nicht im Sinne des Erfinders oder?

Zitat von shofmann

Dann finde ich es spannend, dass der VDR sich auch ohne diese Include-Files problemlos übersetzen lässt. Werden die überhaupt gebraucht, oder benötigen nur spezielle Video-Treiber diese? Das DvbHdDevice benötigt sie offensichtlich nicht...

Das hängt (zuumindest unter Debian) vom Stand des Paketes "linux-libc-dev" ab, da ist die DVB API drin. Es kann sein das du heute DVBDIR setzen musst, aber nächste Woche nicht mehr (wenn linux-libc-dev zwischenzeitlich in ner neuen Version reinkam).

cu

Zitat von Keine_Ahnung

Das hängt (zuumindest unter Debian) vom Stand des Paketes "linux-libc-dev" ab, da ist die DVB API drin. Es kann sein das du heute DVBDIR setzen musst, aber nächste Woche nicht mehr (wenn linux-libc-dev zwischenzeitlich in ner neuen Version reinkam).

Was wäre denn die Empfehlung:

• Primär die Header-Files der Linux-Distribution verwenden (Ubuntu hat sie scheinbar auch drin), d.h. DVBDIR nicht setzen?
• Oder besser explizit die Header-Files von media_build_experimental referenzieren, also DVBDIR immer setzen? Hat DVBDIR in diesem Fall auch Priorität, d.h. werden dann wirklich dessen Header-Files und nicht die der Distribution genutzt?

Dass ich offensichtlich die Header-Files der Distribution und nicht die der Treiber verwende, könnte gegebenenfalls ein paar seltsame Effekte erklären, die ich in letzter Zeit beobachtet habe.

Danke jedenfalls für den Hinweis
Stefan

Moin!

Wenn die Versionen nicht all zu sehr voneinander abweichen, sollte es egal sein, da UFO wahrscheinlich keine API-Erweiterung in sein Repository einbaut, sondern "nur" neue Treiber.

Ansonsten ist die Empfehlung, gegen die Treiber zu bauen, die man benutzt.

Lars.

Hab mich schon gewundert, wohin DVBDIR verschwunden war. Ich hab media_build_expirimental Treiber drauf, aber kompiliert hats trotzdem, funktionieren tuts auch. Aber gut zu wissen, dann werd ich das nächste mal darauf achten, DVBDIR wieder zu setzen.

Die Empfehlung lautet:
Es sollten die Header des eingesetzten Treibers verwendet werden.
Alles andere erfolgt auf eigene Gefahr.

CU
Oliver

Moin!

Zitat von mini73

Ich werde mich noch zusätzlich um restfulapi kümmern und da demnächst ein neues Makefile einchecken.

Ist jetzt in diesem Repository:
https://github.com/yavdr/vdr-plugin-restfulapi
https://github.com/yavdr/vdr-p…ob/master/Makefile-1.7.36

Lars.

Naja Play kommt schon noch. Ich denke das es mein play Plugin ist.

Johns

Na dann bleiben ja nur noch 81 übrig

Und das dbus-Plugin ist obsolet (wurde durch das gut gepflegte dbus2vdr ersetzt), bleiben also nur noch 80 Plugins...

..benutzt denn noch jmd. das surfer plugin? wuerde es sonst geschwind anpassen - hab's immerhin vor langer Zeit mal zusammengekloeppelt