[ANNOUNCE] VDR developer version 1.7.34

Quote from Keine_Ahnung

BTW: Ich habe da auch gerade noch was gefunden. Beim "make plugins" wird das Install Target der Makefiles aufgerufen. Das ist ungünstig weil dann die Plugins evtl. was ins Dateisystem instalieren. Ein das sollte nur passieren wenn man "make install" aufruft.
Wobei ich jetzt auch nicht verstehe warum beim make plugins das Install Taget überhaupt aufgerufen wird. Es ist doch überflüssig die Plugins nach ./PLUGINS/lib zu kopieren.

Wenn man seine Plugins nach ./PLUGINS/src kopiert und dann im VDR-Source-Directory "make plugins" macht, dann müssen die *.so-Dateien nach ./PLUGINS/lib kopiert werden. Der einzige Weg, der mir dazu eingefallen ist war, das "install"-Target der Plugin-Makefiles aufzurufen, wenn $(LIBDIR) und $(LOCDIR) auf den Defaultwerten stehen.

Klaus

Moin moin,

Quote

und dann im VDR-Source-Directory "make plugins" macht, dann müssen die *.so-Dateien nach ./PLUGINS/lib kopiert werden.

ist es nicht so, dass die *.so nur zur Laufzeit verwendet werden?
Wenn dem so ist, müsste die Kopier-Aktion bei "make install" statt finden, aber nicht bei einem build-Aufruf wie "make plugins" - oder übersehe ich da was?

Gruß Gero

Quote from kls

Sorry...

"outsourced"? Was bedeutet das?

Das kannst du gerne machen. Ich verwende allerdings immer nur dreistellige Versionsnummern und dvbsddevice wird dann in der nächsten VDR-Version 0.0.7 haben.

Klaus

Display More

@ 'hd.brummy',

um Gentoo konform zu bleiben, könntest Du ja für diese Version "dvbsddevice-0.0.6-r1" verwenden.

Quote from geronimo

Moin moin,

ist es nicht so, dass die *.so nur zur Laufzeit verwendet werden?
Wenn dem so ist, müsste die Kopier-Aktion bei "make install" statt finden, aber nicht bei einem build-Aufruf wie "make plugins" - oder übersehe ich da was?

Du übersiehst, daß ich es so haben möchte, daß ein "make plugins" im VDR-Verzeichnis für den Fall, daß alles auf Default steht, eine lauffähige Umgebung schafft (ohne erst "make install" machen zu müssen).
Im einfachsten Fall soll es so ablaufen:

- VDR-Source downloaden und auspacken
- Ins VDR-Source-Verzeichnis wechseln
- ggf. Plugin-Sourcen downloaden und nach ./PLUGINS/src/<name> entpacken
- "make" (-> macht "all", was wiederum "vdr", "i18n" und "plugins" macht)
- runvdr-Script anpassen
- "./runvdr"

Wenn jemand die Plugin-Library-Files woanders haben will, dann verhält sich "make plugins" so, daß nichts "installiert" wird.

Bisher war das kein Problem, weil die Plugins ihre Lib-Files zunächst nach ../../lib kopiert haben und das "make install" des VDR diese dann ans endgültige Ziel verfrachtet hat. Da mit den neuen Makefile-Mechanismen aber das Ziel war, ein Plugin völlig unabhängig von VDR erzeugen und installieren zu können, ging das nicht mehr so. Der einzige Weg, der mir eingefallen ist, um diese bequeme Methode zu erhalten war, in diesem Fall "make install" der Plugins aufzurufen.

Klaus

Quote from Keine_Ahnung

Sieht so aus als ob da bash Syntax verwendet wird

Ein
---
SHELL := /bin/bash
---
an den Anfang des Makefiles sollte helfen.

Display More

Der '['-Operator wurde aber auch bisher schon verwendet:

if [ -n "$$noapiv" ] ; then echo; echo "*** plugins without APIVERSION:$$noapiv"; echo; fi;\
        if [ -n "$$failed" ] ; then echo; echo "*** failed plugins:$$failed"; echo; exit 1; fi

Klaus

Quote from kls

Der '['-Operator wurde aber auch bisher schon verwendet:

Code

if [ -n "$$noapiv" ] ; then echo; echo "*** plugins without APIVERSION:$$noapiv"; echo; fi;\
        if [ -n "$$failed" ] ; then echo; echo "*** failed plugins:$$failed"; echo; exit 1; fi

Ich glaube es ist eher wegen

if [ "$(LIBDIR)" == "$(CWD)/PLUGINS/lib" ] && [ "$(LOCDIR)" == "$(CWD)/locale" ]; then\

Also das man da zwei verknüpft (da müssten vermutlich Klammern (Subshell) drum). Jedenfalls ist die Fehlermeldung mit bash als shell weg.

Edit: Habs mal durch checkbashisms gejagt

possible bashism in Makefile line 12 (should be 'b = a'):
            if [ "$(LIBDIR)" == "$(CWD)/PLUGINS/lib" ] && [ "$(LOCDIR)" == "$(CWD)/locale" ]; then

Also aus "==" mach "=" dann ist es posix Shell.

Wegen "make install" der Plugins beim "make plugins" des VDR... Also dürfen die Pluingauthoren den Install Part des Pluginmakefiles nicht anfassen!? IMHO sollte das irgendwo im Makefile als Kommentar erwähnt werden. Weil ich bin (ohne weiter drüber nachzudenken) davon ausgegengen das ich hier die anderen Installsachen (Hilfsscript nach /usr/bin kopieren usw.) auch mit eintragen kann/soll/muss. Also ich hätteso ein Kommentar hilfreich gefunden.

cu

Quote from Keine_Ahnung

Ist nen Bug im Makefile "-I$(DVBDIR)/include" müsste eigentlich in vdr.pc landen. Tuts aber nicht.
Du kannst es aber auch erstmal unter "INCLUDES +=" im Plugin Makefile eintragen. Dann sollte es bauen.

Hiermit sollte das funktionieren:

--- Makefile    2012/12/26 10:55:01     2.37
+++ Makefile    2012/12/27 11:28:21
@@ -49,6 +49,10 @@
 
 -include Make.config
 
+ifdef DVBDIR
+CFLAGS += -I$(DVBDIR)/include
+endif
+
 SILIB    = $(LSIDIR)/libsi.a
 
 OBJS = audio.o channels.o ci.o config.o cutter.o device.o diseqc.o dvbdevice.o dvbci.o\

Der Teil

### You don't need to touch the following:


ifdef DVBDIR
INCLUDES += -I$(DVBDIR)/include
endif

in Make.config[.template] kann dann entfallen.

Quote

BTW, wenn wir gerade dabei sind: "mandir" sollte auch noch in vdr.pc für das install Target der Plugin Makefiles. Manche Plugins bringen ja auch Manpages mit.

Gibt's da keine Möglichkeit, das direkt vom System zu erfragen, wo die Manpages liegen? Das würde ich dann in VDR selber auch verwenden...

Klaus

Quote from kls

Gibt's da keine Möglichkeit, das direkt vom System zu erfragen, wo die Manpages liegen? Das würde ich dann in VDR selber auch verwenden...

Hat sich ja eh erledigt. Wenn die Plugin im Install target eh nix installieren sollen dann brauchen sie die mandir Info auch nicht in vdr.pc.

BTW: Ich habe das obrige Posting nochmal editiert (Bash <-> Posix)

cu

Quote from Keine_Ahnung

Also aus "==" mach "=" dann ist es posix Shell.

Danke, hab's geändert.

Klaus

P.S.: Hier mal wieder der gelegentliche Hinweis: für Nennungen in HISTORY/CONTRIBUTORS ist der volle Name und die Email-Adresse erforderlich. Ich sach's nur...

Quote from Keine_Ahnung

Hat sich ja eh erledigt. Wenn die Plugin im Install target eh nix installieren sollen dann brauchen sie die mandir Info auch nicht in vdr.pc.

Nein, die Plugins sollen bei "make install" schon alles installieren, was sie brauchen.
Ich hatte das wohl übersehen, daß manche Plugins auch noch alles mögliche andere Zeug installieren wollen, nicht nur die standardmäßige *.so-Datei und ggf. ein *.mo.

Nachdem es in den Plugin-Makefiles ja auch ein reines "install-lib"-Target gibt (zumindest, wenn sie durch "newplugin" erzeugt wurden), könnte ich natürlich auch dieses benutzen.
Bei "install-i18n" ist es allerdings etwas schwieriger, da ein Plugin dieses nicht unbedingt haben muß...

Klaus

Quote from kls

Bei "install-i18n" ist es allerdings etwas schwieriger, da ein Plugin dieses nicht unbedingt haben muß...

Ein leeres install-i18n Target als Pflicht ginge doch auch!? Dann sollte Make nicht meckern wenn mans aufruft.
Wobei ich der Meinung bin i18n sollte Pflicht sein. Zumindest DESCRIPTION ist immer da und wird im OSD angezeigt.

BTW: Manpath ermitteln... Tippe mal "manpath" an der Shell ein und schaue in "/etc/manpath.config", ich denke die Idee das automatisch zu ermitteln kann man vergessen Gehört halt zu den distributionsspezifischen Dateisystemvereinbarungen.

cu

Moin moin,

Quote

Du übersiehst, daß ich es so haben möchte, daß ein "make plugins" im VDR-Verzeichnis für den Fall, daß alles auf Default steht, eine lauffähige Umgebung schafft (ohne erst "make install" machen zu müssen).

Hm, das entspricht aber nicht mehr den Linux-Standards, bzw. Gewohnheiten.
Ich würde mal behaupten, ein "standard"-Build aus Saucen wäre:

cd vdr-xx
./configure
make
sudo make install

Das würde - zumindest nach meinem Verständnis - ein vdr-Binary erzeugen, welches verwendet werden kann, um per Befehlszeile den Index einer Aufnahme neu zu erzeugen oder auch eine Aufnahme zu schneiden.

Einen lauffähigen VDR, der per runvdr startet, sehe ich nicht als Ergebnis obiger Befehlssequenz.
Meiner Ansicht nach gehört da wesentlich mehr dazu und ohne ein "make install" würde ich gleich 3mal nicht erwarten, dass der vdr per runvdr gestartet werden kann.

Bei den Makefiles ist es doch völlig schnurz, wie viele Targets vorhanden sind. Warum dann die Geschichte nicht sauber machen?
Wenn die Plugins in einem Rutsch gebaut werden sollen, würde ich diese Sequenz als sinnig erachten/erwarten:

cd vdr-xx
./configure
make 
make plugins
make install
make plugins-install

Das würde bedeuten, dass bei "make plugins" die *.a Dateien kopiert werden, nicht aber die *.so
Ein mögliches Target, welches die komplette Sequenz beinhaltet wäre z.B. "dist". Somit würde ein "make dist" den Vdr mit allen Plugins bauen und installieren.
Bei make dist ist es auch so, dass die Dokumentation (man-pages etc.) erstellt bzw. aufbereitet wird.
Das Installationsziel wird üblicherweise relativ zu PREFIX festgelegt.
Bekanntermaßen ist /usr/local der default für PREFIX und kann mit --prefix=<path> gesetzt werden.
... wenn der vdr so gebaut werden soll, dass alles aus dem source-Verzeichnis gestartet werden kann, dann könnte das configure-Script den PREFIX-Parameter mit der Ausgabe von pwd füllen. Das würde dann zwar auch gegen die Linux-Gewohnheiten verstoßen, aber im vdr-Umfeld ist ja so manches eher eigen

Gruß Gero

Quote from Keine_Ahnung

Ein leeres install-i18n Target als Pflicht ginge doch auch!? Dann sollte Make nicht meckern wenn mans aufruft.

Also gut, ich habe das jetzt so geändert, daß im VDR-Makefile

target="install-lib install-i18n"

gemacht wird und habe in den Plugin-Makefiles die entsprechenden Änderungen gemacht (bestehende Plugin-Makefiles die "install-lib" und "install-i18n" haben sind nicht betroffen).

Quote

...
BTW: Manpath ermitteln... Tippe mal "manpath" an der Shell ein und schaue in "/etc/manpath.config", ich denke die Idee das automatisch zu ermitteln kann man vergessen Gehört halt zu den distributionsspezifischen Dateisystemvereinbarungen.

Es ist wirklich zum Kotzen, daß jede Distribution meint, diese Sachen woanders hinpfriemeln zu müssen...

Ich füge dann halt MANDIR zum vdr.pc hinzu...

Klaus

Quote from geronimo

Moin moin,

Hm, das entspricht aber nicht mehr den Linux-Standards, bzw. Gewohnheiten.

Aber es entspricht meinen Gewohnheiten!

Ich will VDR nicht "ins System installieren", sondern alles unterhalb des VDR-Source-Directories haben. So hatte ich das von Anfang an vorgesehen und das will ich auch immer so haben. Wer das nicht will, braucht bloß LIBDIR und LOCDIR in seinem Make.config entsprechend zu setzen, und alles ist gut.

Klaus

Quote from Klaus

Klaus,

"outsourced"? Was bedeutet das?

das jeweilig plugin den vdr sourcen zu entnehmen, zu taren und als eigenständiges paket zum download verfügbar zu stellen.
Es gab da imho schon mehrfach fragen auf der linuxtv/vdr ML an dich das generell in eigenständige Pakete zu packen.

Hintergrund unter gentoo ist:
die plugins sind/müssen als eigenständige Pakete angeboten /werden.
Es gab da, befor ich das "outsourced" hatte, massive Beschwerden von gentoo usern, das jedesmal wenn man die plugins installieren will,
der komplette vdr source runtergeladen werden muss, und das bloss wegen einer handvoll files die in den jeweiligen plugins sind
anyway, ist ein gentoo paketmanger problem, das ich so gelöst habe.

Quote from Klaus

Das kannst du gerne machen. Ich verwende allerdings immer nur dreistellige Versionsnummern und dvbsddevice wird dann in der nächsten VDR-Version 0.0.7 haben.

Klaus

Ist nur ein tempärer workaround damit der paketmanager mit den unterschiedlichen Versionen (checksums) dvbsddevive-0.0.6(vdr-1.7.33) dvbsddevice-0.0.6(vdr-1.7.34) klarkommt.
Die interne versionsnummer des jeweiligen plugins bleibt dabei ja gleich, ich will doch nicht an den sourcen vom Meister rumfrickeln

Quote from hd.brummy

das jeweilig plugin den vdr sourcen zu entnehmen, zu taren und als eigenständiges paket zum download verfügbar zu stellen.
Es gab da imho schon mehrfach fragen auf der linuxtv/vdr ML an dich das generell in eigenständige Pakete zu packen.

Das steht dir natürlich frei, das in getrennte Pakete zu packen.
Das VDR-Paket, das ich zur Verfügung stelle, wird halt immer auch die standardmäßig mitgelieferten Plugins enthalten.

Klaus

Quote from kls

Aber es entspricht meinen Gewohnheiten!

Ich hoffe damit ist alles geklärt. Wir würden gerne anfangen die 1.7.34 zu Paketieren, aber solange die Makefiles ein running target zu sein scheinen macht das keinen Sinn.
Ich finde es völlig in Ordnung wenn Klaus es so haben will. Es hindert ja keinen daran es anders zu machen, dazu ist das doch flexibel genug.

Gerald

Quote from gda

Wir würden gerne anfangen die 1.7.34 zu Paketieren, aber solange die Makefiles ein running target zu sein scheinen macht das keinen Sinn.

Ich bin gerade dabei, die jüngsten Erkenntnisse einzuarbeiten und werde dann einen entsprechenden Patch hier posten.

Klaus

Quote from gda

Ich hoffe damit ist alles geklärt.

Yepp!

Selbst Kienzle hat keine Fragen mehr

Quote from EIB-Freak

Hi Oliver,

danke für deine Antwort. Logmeldungen sind z.b. [ANNOUNCE] VDR developer version 1.7.34

Da sehe ich nichts vom Laden des _Treibers_.

Quote

Firmware ist (für mich selbstverständlich) aktuell, es kommt ja auch ein Bild (was ja denke ich erstmal nichts über die Firmware sagt).

Ich verwende jeweils den aktuellen media_build_experimental von linuxtv nach der Anleitung hier im Forum, welchen ich zum Schluss dann auch immer mit
make install "lauffähig" kopiere (liegt hier vielleicht der Hund begraben ? ).

Wie ich schon weiter oben schrieb, hat sich die Directory-Struktur geändert. Du solltest also vor einem "make install" den alten media-Zweig unter /lib/modules/... wegräumen, damit sicher die aktuelle Version (und nur diese) geladen wird.

Eine andere Möglichkeit wären evtl. noch falsche Plugin-Einstellungen. Was steht in setup.conf bzgl. dvbhhddevice?

CU
Oliver