Beiträge von shofmann

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

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

Zitat von kls

Hast du es schon mal mit 'make LCLBLD=1' versucht? Damit wird über HDRDIR das VDR-Include-Verzeichnis in die cxxflags der vdr.pc geschrieben.

Klaus,

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

# 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.

Grüße
Stefan

Zitat von Keine_Ahnung

Jetzt bin ich aber auch verwirrt, das include Directory war doch mal in den cflags/cxxflags drin?

Die Datei vdr.pc schaut bei mir so aus:

bindir=/usr/local/vdr-1.7.36/bin
mandir=/usr/local/vdr-1.7.36/man
configdir=/usr/local/etc/vdr
videodir=/srv/vdr/video
cachedir=/srv/vdr/video/.cache
resdir=/usr/local/vdr-1.7.36/share
libdir=/usr/local/vdr-1.7.36/lib
locdir=/usr/local/vdr-1.7.36/locale
plgcfg=
apiversion=1.7.36
cflags=-g -O3 -Wall -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  
cxxflags=-g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  


Name: VDR
Description: Video Disk Recorder
URL: http://www.tvdr.de/
Version: 1.7.36
Cflags: ${cflags}

Wenn ich also keine Tomaten auf den Augen habe, findet sich dort kein einziges Include.

Stefan

Zitat von CyberChris

Ich baue gegen media_build_experimental und habe das in Make.config folgendermaßen eingetragen.

Code

DVBDIR = /usr/src/media_build_experimental/linux/include/uapi

Das scheint auch irgendwie noch ein generelles Problem zu sein. Beim anderen Plugins (z.B. femon) habe ich die Meldung mit der DVB API Version auch, aber da bricht er nicht ab.

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):

find . -name ".dependencies" | xargs rm

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

Toi, toi, toi
Stefan

Zitat von Copperhead

Ich verstehe nicht was du meinst? /usr/include ist standardmäßig included.

Ich bin mir nicht sicher, ob ich das alles wirklich schon bis ins letzte Detail verstanden habe. Aber nehmen wir doch einmal mein MList-Makefile als Beispiel, das seinerseits auf dem Makefile des Demo-Plugins Hello basiert. Ganz oben holt sich das Makefile ein paar Verzeichnisse aus vdr.pc:

PKGCFG = $(if $(VDRDIR),$(shell pkg-config --variable=$(1) $(VDRDIR)/vdr.pc),$(shell pkg-config --variable=$(1) vdr || pkg-config --variable=$(1) ../../../vdr.pc))
LIBDIR = $(call PKGCFG,libdir)
LOCDIR = $(call PKGCFG,locdir)

Weiter unter können dann gegebenenfalls zusätzliche Include-Verzeichnisse ergänzt werden:

### Includes and Defines (add further entries here):


INCLUDES +=

Wo aber bekommt das Makefile die Referenz auf die VDR-Include-Dateien her, wenn man es von außerhalb des VDR-Baums (also nicht über make im VDR-Verzeichnis) kompilieren und installieren möchte? Dieser Use Case ist ja genau das, was die Package Builder explizit wollen und was die ganze Makefile-Umstellung ja erst in Gang gesetzt hat...

Normalerweise speist das VDR-Makefile das VDR-Include-Verzeichnis als Environment-Variable in das untergeordnete Makefile ein, sodass es dort schon von Anfang an in INCLUDES enthalten ist. Das Makefile selbst kümmert sich deshalb bislang nicht darum. Ich frage mich also, wie das Makefile diese Informationen erhält, wenn es separat aufgerufen wird und nicht durch das VDR-Makefile. Derzeit muss man den Verweis auf das VDR-Include-Verzeichnis vorab per Environment-Variable übergeben, denn als Parameter des Make-Aufrufs müsste man sonst über die Direktive override die Modifikation der so übergebenen INCLUDES zulassen, was die Makefiles aber generell nicht tun.

Deshalb meine Frage, ob das VDR-Inlcude-Verzeichnis nicht ebenfalls in vdr.,pc hinterlegt und von den Makefiles von dort ausgelesen werden müsste. Dies wäre umso wichtiger, wenn es sich eben nicht – wie ich geschrieben hatte – unter /usr/include bzw. /usr/local/include liegt. Was bei mir der Fall ist, denn damit ich schnell zwischen VDR-Verisonen hin- und herschalten kann, liegt alles, was eine VDR-Instanz betrifft, vollständig innerhalb eines Verzeichnisbaums unter /usr/local – auch deren Include-Files.

Ist meine Frage damit verständlich geworden?
Und haben wir diesbezüglich noch Handlungsbedarf?

Danke & Grüße
Stefan

Zitat von goldbär

Hallo,
hier mein Makefile-patch für streamdev für vdr 1.7.36
streamdev ist aktuell aus dem git.
Ich kann damit Pakete außerhalb des vdr bauen. Was anderes habe ich nicht getestet.
Bitte melden, wenn was nicht stimmt. Wie gesagt, kenne ich mich mit Makefiles nicht so gut aus.

Ist doch schön, dass manche Arbeit mehrfach erledigt wird...

Dummerweise hatte ich damals das StreamDev-Plugin mit seinen insgesamt sechs Makefiles beim Hochladen meiner Sammlung übersehen. Ich habe das gerade nachgeholt. Ihr findet das Makefile hier bei den anderen. Sorry für die verspätete Lieferung...

Wegen der Frage der produktiven Nutzung: Ich nutze den VDR seit 1.7.35 mit den von mir adaptierten Makefiles schon seit Jahresanfang als Produktivsystem völlig ohne Probleme. Mit Erscheinen von 1.7.36 habe ich die Makefiles bezüglich des Handlings von DESTDIR nochmals angepasst, und somit sollten sie mit den Konventionen für die aktuelle Version eigentlich übereinstimmen.

Inzwischen habe ich das Mlist-Plugin auch mal außerhalb des VDR-Baums gebaut. Bis auf das Problem, dass INCLUDES bzgl. der VDR-Include-Files nicht automatisch gesetzt wird und beim make auf der Kommandozeile mit angegeben werden muss (die VDR-Include-Files stehen bei mir nicht unter /usr/include bzw. /usr/local/include), hat Bauen und Installieren "von außen" auch wunderbar geklappt. Das ist ausgesprochen praktisch, wenn man beim "Basteln" wirklich nur mal ein einzelnes Plugin neu übersetzen möchte...

Copperhead und kls: Müsste das VDR-Include-Verzeichnis eventuell noch in vdr.pc mit aufgenommen und INCLUDES in den Makefiles von dort gefüllt werden?

Ciao,
Stefan

Zitat von shofmann

Oops, das habe ich wohl übersehen... Anbei die Archive mit den modifizierte Makefiles.

Ich habe gerade bemerkt, dass beim WeatherNG-Makefile die Grafik-Bibliotheken (ImageMagick bzw. ImLib2) nicht mit mitgelinkt werden.

Anbei das korrigierte Makefile.

Stefan

Zitat von Copperhead

Mir fällt aber gerade auf, dass in den von shofmann geposteten Makefiles die Install-Routine für die Zusatzdateien fehlt. Im Fall von live müsste das "live"-Verzeichnis ins Resourcedirectory kopiert werden. Ein gut umgesetztes Beispiel dafür ist skinnopacity und tvguide.

Oops, das habe ich wohl übersehen... und gen_version_suffix.h ist mir auch entfleucht... Da muss ich meine Makefiles wohl nochmals durchsehen. Fällt auch gar nicht auf, wenn alles schon am richtigen Platz ist...

Mir fällt gerade auf, dass es bei live im README heißt:

Zitat

In order to work correctly you must copy the subdirectory 'live' from
the source distribution to the directory where the vdr plugins look
for their configuration files. The pure VDR default for this config
directory is: /video/plugins, but this depends also from the
parameters -c or -v (see 'vdr --help' for details).

cp -a <live-src-dir>/live <plugin-config-dir>/plugins

Aber ich stimme zu, das sollte heutzutage automatisch gehen. Anbei die Archive mit den modifizierte Makefiles.

Stefan

Zitat von Maniac

Das Makefile für skinpearlhd kommt die nächsten Tage.

Schau mal hier, ich habe schon ein wenig Vorarbeit geleistet...

Viel spannender wäre die Frage, wann eine verbesserte, insbesondere fehlerbereinigte Version des Plugins käme. Denn seit VDR 1.7.34 (oder 35?) wird z.B. anstelle eines Einstelldialogs nur eine übergroße schwarze Fläche ohne Eingabefelder angezeigt. Woran das liegt, habe ich bislang nicht herausgefunden (war aber auch mehr mit den Makefiles beschäftigt). Schade, denn das Skin gefiele mir gut und läuft im Gegensatz zu nOpacity auch mit der Einstellung High-Level OSD der S2-6400 – und damit recht flott...

Stefan

Fortsetzung: Neue Makefiles, Teil 5 (Letzter Teil)

Achtung: Zweites Update des WeatherNG-Makefiles (installiert die Resource-Dateien und bindet die auch die Grafik-Bibliotheken mit ein).

Nachtrag: Ich hatte das Makefile für StreamDev vergessen und nachträglich noch beigefügt.

Alle Makefiles "as is", also unter Ausschluss jeglicher Gewährleistung, wie man so schön sagt...

Viele Erfolg damit
Stefan

Fortsetzung: Neue Makefiles, Teil 4

Achtung: Update des SkinPearlHD-Makefiles (installiert jetzt auch die Themen).

Fortsetzung: Neue Makefiles, Teil 3

Achtung: Update des SkinEnigmaNG-Makefiles (installiert jetzt auch die Themen).

Fortsetzung: Neue Makefiles, Teil 2

Achtung: Update der Live-Makefiles (installieren jetzt auch die Resource-Dateien).

Nachfolgend (in diesem und den folgenden Postings) ein Satz angepasster Makefiles für die Plugins in meiner Signatur, die nicht in der VDR-Distribution drin sind. Bei einigen hat, wenn ich mich recht erinnere, Copperhead schon Vorarbeiten geleistet (Danke dafür!), sodass ich nur ein bisschen Feintuning betrieben habe...

Für die Plugin-Entwickler könnten die angepassten Makefiles ein guter Startpunkt sein. Und wenn sie nicht ganz spezielle Dinge brauchen, sollten die Makefiles eigentlich 1-zu-1 übernommen werden können. Ich habe mit diesen Makefiles meine Plugins jedenfalls in den letzten Wochen mehrfach erfolgreich kompiliert, zuletzt (heute) für VDR 1.7.36. Allerdings habe ich immer innerhalb des VDR-Verzeichnisbaums kompiliert, nicht außerhalb. Da ich mich aber an das Makefile des Plugins hello als Vorlage gehalten habe, würde ich erwarten, das auch dies funktioniert. Toi, Toi, Toi...

Die Anpassung der Makefiles für softhddevice und xineliboutput habe ich nach einiger Zeit aufgegeben, weil diese doch extrem stark vom Standard abweichen. Solange beide Plugins mit ihren alten Makefiles noch kompilieren, warte ich erst einmal, ob die Entwickler nicht doch eine bessere Lösung anbieten, als ich es könnte.

Viele Grüße
Stefan

Zitat von Copperhead

Aber Achtung die Makefiles für die Plugins haben sich nochmal minimal geändert (Stichwort DESTDIR).

Das habe ich berücksichtigt. Ich lade dann mal meine Sammlung hoch, damit die Plugin-Entwickler und Selbstkompilierer nicht von vorne beginnen müssen...

Stefan

PS: Hier stehen die Files zum Download bereit.

Läuft bei mir ebenfalls. Wieder mal vielen Dank an die rührigen Entwickler und Maintainer!

Anlässlich der neuen Version wollte ich mal die angepassten Makefiles für die von mir genutzten Plugins (siehe Signatur und Thread zur 1.7.35) hochladen. Wäre dies hier ein guter Ort, oder sollte ich sie lieber in einem eigenen Thread posten? Eure Meinung hierzu?

Copperhead: Soweit ich mich erinnere, wolltest du auch anfangen, die Makefiles anzupassen. Hast du eventuell schon einen Thread hierfür, bei dem ich meine Sachen mit dazupacken könnte?

Danke und viele Grüße
Stefan

Zitat von UFO

Imho muß es irgendwann einmal gut sein. Wenn ein Plugin irgendwelche merkwürdigen Abfragen macht, kann das nicht das Problem von VDR sein.

Schon klar. Dennoch fände ich es gut, wenn wir den Aufruf alter Makefiles so gut als möglich wie bisher handhaben, damit es gerade bei Plugins mit so komplexen Makefiles wie xineliboutput möglichst wenig knirscht, bis sie endlich vollständig ins neue System eingepasst sind.

CU Stefan

Zitat von kasper-ls

WARNING: plugin xineliboutput is using an old Makefile!
Makefile:113: VDRDIR = /usr/src/vdr/vdr-git/vdr
Makefile:114: ********************************************************
Makefile:115: VDR source tree not detected !
Makefile:116: VDR plugins will not be installed.
Makefile:117: ********************************************************

Das originale Makefile des Plugins prüft, ob VDRDIR auf "../../.." gesetzt ist. Im Gegensatz zum alten System übergibt das VDR-Makefile jetzt immer VDRDIR mit dem absoluten Pfad.

Das alte VDR-Makefile hingegen hat VDRDIR überhaupt nicht gesetzt, weshalb die alten Plugin-Makefiles diese Variable selbst passend (meist auf "../../..") gesetzt haben. Damit dieser Default-Wert aber wie gewünscht verwendet wird, darf dem alten Plugin-Makefile die Variable aber nicht per make-Parameter mitgegeben werden. Ich würde deshalb vorschlagen, im VDR-Makefile den Aufruf wie folgt abzuändern:

# Old Makefile\
		if ! grep -q "PKGCFG" "$(PLUGINDIR)/src/$i/Makefile" ; then\
	   	echo "WARNING: plugin $i is using an old Makefile!";\
	   	oldmakefile="$oldmakefile $i";\
	   	$(MAKE) --no-print-directory -C "$(PLUGINDIR)/src/$i" CFLAGS="$(CFLAGS) $(CDEFINES) $(CINCLUDES)" CXXFLAGS="$(CXXFLAGS) $(CDEFINES) $(CINCLUDES)" LIBDIR="$(PLUGINDIR)/lib" all || failed="$failed $i";\
	   	continue;\
	   	fi;\

Damit kompiliert das Plugin und legt seine Dateien wie gewohnt in PLUGIN/lib ab, von wo aus sie dann ins Installationsverzeichnis kopiert werden. Bei mir hat das Plugin ohne diese Änderung "seine" Objektfiles bei sich behalten und erst per make install installiert.

Das Patchset für die Änderung habe ich beigefügt.
Was ist die Meinung des Teams hierzu?

Ciao, Stefan

Zitat von Mreimer

Die brauchst du dann, wenn du alte Plugins zwar im VDR-Verzeichnis platzierst, das "make" aber im Plugin-Verzeichnis ausführst. Nur über den "-include" der Make.config bekommst du dann das "-fPIC". Diese Zeilen, und etliche andere, können dann entfallen, wenn Klaus die Unterstützung der alten Makefiles entfernt.

Verstanden, die paar Zeilen stören ja auch nicht... War halt gerade bei Aufräumen...

Noch eine Frage ans Team: Sollten wir in jedem Makefile nicht auch das Makefile selbst sowie – wo referenziert – Make.config, Make.global und $(PLGCFG) als Abhängigkeit für all, install-lib und install-i18n führen?

Ciao, Stefan