[Announce] VDR developer version 2.1.9

Vielen Dank für die neue Version!

Damit läuft der Countdown für vdr 2.2.0 stable...

Christian

Hi,

kann es sein, dass sich Buildsystem etwas geändert hat?

Wenn ich die Plugins "cleane", hagelt es folgende Fehlermeldungen:

vdr01_64 VDR # make clean
vdr01_64 VDR # make clean-plugins
Failed to open '/usr/local/src/vdr-2.1.9/vdr.pc': No such file or directory
No package '/usr/local/src/vdr-2.1.9/vdr.pc' found
Failed to open '/usr/local/src/vdr-2.1.9/vdr.pc': No such file or directory
No package '/usr/local/src/vdr-2.1.9/vdr.pc' found
Failed to open '/usr/local/src/vdr-2.1.9/vdr.pc': No such file or directory
No package '/usr/local/src/vdr-2.1.9/vdr.pc' found
Failed to open '/usr/local/src/vdr-2.1.9/vdr.pc': No such file or directory
No package '/usr/local/src/vdr-2.1.9/vdr.pc' found
Failed to open '/usr/local/src/vdr-2.1.9/vdr.pc': No such file or directory
No package '/usr/local/src/vdr-2.1.9/vdr.pc' found
Failed to open '/usr/local/src/vdr-2.1.9/vdr.pc': No such file or directory
......

Das war bei der "2.1.8" noch nicht so.

Das war manchmal auch schon vorher so.
Ich hab mir angewöhnt, erst clean-plugins und dann clean zu machen

Lars.

Zitat von mini73

Das war manchmal auch schon vorher so. ...

Nö!

vdr01_64 vdr-2.1.8 # make clean
vdr01_64 vdr-2.1.8 # make clean-plugins
(cd lib && make clean)
rm -f *.o *~ core tst demo libhorchi.a
make -C ./graphtft-fe clean
rm -f *.o graphtft-fe *~
(cd lib && make clean)
rm -f *.o *~ core tst demo libhorchi.a
make -C ./tools clean
make -C ./libdvbmpeg clean
make -C ./remux clean
make -C ./client clean
make -C ./server clean
vdr01_64 vdr-2.1.8 #

Zitat

[...] Ich hab mir angewöhnt, erst clean-plugins und dann clean zu machen

Auch dann dann kommen die o.g. Fehler...

Zitat

- Added a missing VDRDIR="$(CWD)" to the clean-plugins target of the Makefile, to
avoid error messages regarding the missing vdr.pc file.

Die Variable VDRDIR wird nun an die plugins weitergereicht. Damit suchen die Plugins nicht mehr systemweit nach der vdr.pc sondern im lokalen build-Verzeichnis, wie es eigentlich sein soll.
Die Reihenfolge müsste sein, dass man erst eine vdr.pc erstellt, dann die Plugins bereinigt und erst anschließend den Rest.
Alternativ "make distclean" ausführen, da wird es richtig rum gemacht.

Clemens

Zitat von acb321

[...] Alternativ "make distclean" ausführen, da wird es richtig rum gemacht.

Clemens

Auch mit "distclean" kommen o.g. Fehler....

So gehts:

vdr01_64 VDR # make vdr.pc distclean
(cd lib && make clean)
rm -f *.o *~ core tst demo libhorchi.a
make -C ./graphtft-fe clean
rm -f *.o graphtft-fe *~
(cd lib && make clean)
rm -f *.o *~ core tst demo libhorchi.a
make -C ./tools clean
make -C ./libdvbmpeg clean
make -C ./remux clean
make -C ./client clean
make -C ./server clean
vdr01_64 VDR #

Aber ist das Sinn und Zweck der Übung??

Daher auch der Patch, welcher besagt dass clean-plugins eine vdr.pc benötigt. Aber irgendwie ist das schon sinnlos, zuerst eine vdr.pc zu erstellen, um diese nach Bereinigung der plugins wieder zu entfernen.

Wie machst du bei dir ein Update? Neues vdr-Verzeichnis entpacken und vorkompiliertes PLUGINS/src aus der Vorversion übernehmen?
Ich übernehme gewöhnlich das komplette Verzeichnis und spiele da den Patch auf den neueren VDR ein - da stellt sich die Frage nicht da eine vdr.pc bereits vorhanden ist.

Auch ein make clean direkt im Plugin-Verzeichnis sollte nicht zu einem Fehler führen:

for PLG in PLUGINS/src/*; do make -C $PLG clean; done

OK, mit dem Patch funktioniert es.

Ich hatte bei "make distclean" ständig Fehlermeldungen wegen des fehlenden vdr.pc bekommen. Als ich mir das genauer angeschaut hatte fiel mir auf, daß überall VDRDIR="$(CWD)" übergeben wurde, nur eben an dieser einen Stelle nicht. Nachdem ich das hinzugefügt hatte, waren die Meldungen weg.
Wenn keiner was dagegen hat baue ich für die finale 2.2.0 den Patch von acb321 noch mit ein.

Klaus

Ich hab nichts dagegen.

Lars

Oh man,

Weihnachten ist fuer mich glaube ich der 19. Februar,
ich bin völlig aufgelöst, kann kaum noch schlafen, mein blutdruck ist jenseits von gut und böse, die Tage bis dahin erscheinen unsagbar lang und zäh,...

trotz alledem möchte ich, nein muss ich, an dieser Stelle mein Veto einlegen.

Und zwar geht es um die neusten Änderungen im Makefile bzw, Make.config.template

Dort wird jetzt NO_KBD defieniert.
Hinter diesem NO_ handling steckt immer ein sehr verdrehte Logic.

Sprich, ich setze etwas auf 1 und bekomme dann nix?

Für mich klingt das logischer, so wie es jetzt auch ist, -DREMOTE_KBD install default enabled
Wenn der user das nicht haben will, dann soll er den wert KBD = 0 setzen
Kling fuer mich logischer
Sprich, ich setze was auf 0 dann bekomme ich auch nix

<snipp Make.config.template>
### Set to 0 if you don't want keyboard remote control:
KBD = 1
</snapp>

<snipp Makefile>
ifdef KBD
....
endif
</snapp>

Cheers
/bin/joerg

Auf die Art könnte es nicht gehen, da dann eine Make.config zwingend erforderlich ist. Aktuell kompiliert VDR auch gut ohne eine solche.

Verwirrender finde ich, jetzt wo du es ansprichst, dass wirklich mit ifdef bzw. ifndef geprüft wird. Es ist egal ob NO_KDB auf 0 oder 1 gesetzt wird, die Wirkung ist die gleiche. Selbiges gilt auch für BIDI und SDNOTIFY.
Anbei ein Vorschlag diesbezüglich. Einerseits ändert dieser NO_KBD auf USE_KBD, andererseits werden bei den anderen beiden genannten Variablen auch 0 als nicht benutzen erkannt.

Die bisherige Vorgehensweise mit NO_xx ist durchaus üblich, komisch ist hier nur, dass die Bedeutung im eigentlichen Makefile wieder umgedreht wird.

Clemens

sag ich doch, komische verdrehte logic

ist mir auch schon aufgefallen, die wirkung ist gleich null, das liegt aber daran das nur das Make.config includiert wird und nicht das .template

ich glaub da muss n default wert mit übergeben werden damit das dann leztendlich greift
also:

ifeq ($(VARIABLE),1)

bla foo
endif

oder ebend

ifneq ($(VARIABLE),1)

foo bla
endif

###
im prinzip ist es mir letzendlich egal, ich kann das hier fuer gentoo umbiegen, bzw hab ich das schon getan

Zitat von hd.brummy

Und zwar geht es um die neusten Änderungen im Makefile bzw, Make.config.template

Dort wird jetzt NO_KBD defieniert.

Nein, das wird dort nicht definiert! Es wurde lediglich die Möglichkeit geboten, es zu definieren. Die Zeile ist ja standardmäßig auskommentiert.
Es hat sich dadurch also am Verhalten gegenüber der vorherigen Version nichts geändert.

Zitat

Hinter diesem NO_ handling steckt immer ein sehr verdrehte Logic.

Sprich, ich setze etwas auf 1 und bekomme dann nix?

Durch das Setzen von NO_KBD wird die standardmäßig aktivierte Keyboard-Unterstützung abgeschaltet. Das entspricht der Kommandozeilen-Option --no-kbd.

Zitat

Für mich klingt das logischer, so wie es jetzt auch ist, -DREMOTE_KBD install default enabled
Wenn der user das nicht haben will, dann soll er den wert KBD = 0 setzen
Kling fuer mich logischer
Sprich, ich setze was auf 0 dann bekomme ich auch nix

<snipp Make.config.template>
### Set to 0 if you don't want keyboard remote control:
KBD = 1
</snapp>

<snipp Makefile>
ifdef KBD
....
endif
</snapp>

Alles anzeigen

Das Handling dieser Parameter können wir gerne ändern, wenn ein allgemeiner Konsens besteht.
Allerdings ist jetzt mit Sicherheit nicht der richtige Zeitpunkt dafür ;-).
Nach der Version 2.2.0 sehen wir weiter...

Klaus

Zitat von acb321

Auf die Art könnte es nicht gehen, da dann eine Make.config zwingend erforderlich ist. Aktuell kompiliert VDR auch gut ohne eine solche.

Und das soll auch so bleiben!

Zitat

Verwirrender finde ich, jetzt wo du es ansprichst, dass wirklich mit ifdef bzw. ifndef geprüft wird. Es ist egal ob NO_KDB auf 0 oder 1 gesetzt wird, die Wirkung ist die gleiche. Selbiges gilt auch für BIDI und SDNOTIFY.

Das ist richtig. Die Macros müssen lediglich definiert werden, um zu wirken. Welchen Wert sie haben ist egal.

Zitat

Anbei ein Vorschlag diesbezüglich. Einerseits ändert dieser NO_KBD auf USE_KBD, andererseits werden bei den anderen beiden genannten Variablen auch 0 als nicht benutzen erkannt.

Bitte nach der Version 2.2.0 nochmal ansprechen. Jetzt ist nicht der richtige Zeitpunkt für eine solche Änderung.

Zitat

Die bisherige Vorgehensweise mit NO_xx ist durchaus üblich, komisch ist hier nur, dass die Bedeutung im eigentlichen Makefile wieder umgedreht wird.

Wo wird denn da was "umgedreht"?

Klaus

Zitat von hd.brummy

sag ich doch, komische verdrehte logic

ist mir auch schon aufgefallen, die wirkung ist gleich null, das liegt aber daran das nur das Make.config includiert wird und nicht das .template

Natürlich! Make.config.template ist ja auch nur eine *Vorlage* für ein eigenes Make.config.
Steht auch in der Datei drin:

# User defined Makefile options for the Video Disk Recorder
#
# Copy this file to 'Make.config' and change the parameters as necessary.

Klaus

Zitat von kls

Wenn keiner was dagegen hat baue ich für die finale 2.2.0 den Patch von acb321 noch mit ein.

Geht leider doch nicht, weil dann sowas nicht mehr möglich ist:

make distclean all

weil dann zwischendurch die vdr.pc wieder (in "clean:") gelöscht wird.

Ich lasse es also vorerst mal so, wie es ist. Falls jemand nach der Version 2.2.0 noch eine Idee hat, bitte melden.

Klaus

Fehler im skin LCARS?

kann das jemand nachvollziehen?

Skin LCARS
Menu --> Einstellungen --> Wiedergabe

Die beschreibung der neuen (binary skip sprungweiten halbieren usw.) parameter ist jetzt so breit, das die letzten enden der beschreibung unter den veränderbaren Einstellungen verschwinden.

Cheers

/bin/joerg