[Announce] VDR developer version 1.7.35

    Zitat von Copperhead

    Anbei ein Patch, der hoffentlich auch deine Sonderlocke repariert.

    Danke, aber ganz hilft er noch nicht:


    Nach knapp zwei Stunden erfolglosem Debuggen melde ich mich deshalb wieder. Offenbar wird für die alten Plugin-Makefiles install aufgerufen, was nicht existiert und bei den neuen wird DESTDIR nicht an install-plugins weitergegeben - ich blicks aber nicht, warum ....

    Hi,


    ich als makefile nixtschegger (bzw. keinen Bock drauf habender ;) ) hätte eine Bitte...könnte jemand bitte mal den aktuellen Status irgendwie zusammenfassen? Wie funktioniert das Plugin bauen denn jetzt? Bzw. was muss in den alten Plugin Makefiles angepasst werden? Sind die Änderungen von 1.7.34 in den Plugin makefiles noch korrekt?


    Mucas Gracias...Louis

    Hallo Copperhead,


    anbei mein Vorschlag als diffs gegen Deine 13er Version. Einmal Make.config.template und einmal ein Beispiel für meine Idee in Bezug auf die _neuen_ Plugin-Makefiles (am Beispiel dvbhddevice, weil es ein Unterverzeichnis hat) - die alten bauen nach der Änderung in Make.config sauber incl. MAKEDEP gegen die Header aus DVBDIR (auch das ältere Böse mit seinen Unterverzeichnissen).


    Ob das ordentlich ist, weißt Du besser als ich - Du hast Dir schon mehr Kopf um das Konzept gemacht.


    Gruß, Ingo

    EDIT: Alles Unsinn!


    Nachtrag:


    Wenn wir es gaaaaanz sauber (also päpstlicher als Ratzinger) wollen, muss auch das clean-plugin mit VDRDIR aufgerufen werden, sonst greifen die pkg-config Makros nicht. Und wenn man dann 2x hinter einander make clean-plugins aufruft, wird beim zweiten clean auf ein cleanes Verzeichnis MAKEDEP ausgeführt... (ich glaube ich bekomme gerade eine Macke, wer testet son einen Scheiss??? Außer mir??? Und wem ist es wichtig, dass das MAKEDEP beim clean auf ein cleanes Verzechnis noch richtig tut?)


    Gruß, Ingo

    Zitat von louis

    Hi,


    ich als makefile nixtschegger (bzw. keinen Bock drauf habender ;) ) hätte eine Bitte...könnte jemand bitte mal den aktuellen Status irgendwie zusammenfassen? Wie funktioniert das Plugin bauen denn jetzt? Bzw. was muss in den alten Plugin Makefiles angepasst werden? Sind die Änderungen von 1.7.34 in den Plugin makefiles noch korrekt?


    Mucas Gracias...Louis


    Bis jetzt sind die Änderungen noch korrekt. Evtl. schließt sich Copperhead meinem Vorschlag an, dann gibt es eine winzige Änderung.


    Gruß, Ingo

    Zitat von nvertigo

    Ob das ordentlich ist, weißt Du besser als ich - Du hast Dir schon mehr Kopf um das Konzept gemacht.


    Ja, jetzt verstehe ich immerhin den Grundgedanken. Optisch gefällt es mir noch nicht so wirklich. Ich mache dann den Rest.

    Zitat von nvertigo

    Wenn wir es gaaaaanz sauber (also päpstlicher als Ratzinger) wollen, muss auch das plugin-clean mit VDRDIR aufgerufen werden


    Das verstehe ich im Moment gar nicht. Erkläre das mal genauer.



    louis; speed


    Noch hat sich nichts geändert, ihr könnt euch da immer am Patch orientieren. Und zwar solange sich nichts am Makefile vom z.B. hello-Plugin ändert müsst ihr auch nichts ändern.


    Stellt euch aber schon mal drauf ein, denn die Pluginmakefiles habe ich bisher gar nicht behandelt.

    Es handelt sich wirklich nur um einen Schönheitsfehler, der definitiv keinen Einfluss aufdas folgende Build hat:


    make clean benötigt .dependencies und löscht dieses am Ende des cleans. Wenn man jrtzt nochmal cleant, macht make erst ein neues .dependencies, um es am Ende wieder zu löschen.
    Die Makros PKGCFG und MY_PKGCFG prüfen als erstes ob VDRDIR gesetzt ist, sonst wird pkg-config garnicht erst bemüht, und somit fehlt -I$(DVBDIR).


    Nenn' mich Pedant oder gib mir andere Tiernamen... ;)


    Gruß, Ingo

    Ach, ich finde da hast du schon recht, ein clean sollte clean machen, egal wie oft man es aufruft.


    cu

    EDIT: Unsinn, was ich hier geschrieben habe. Nach dem || sollte das MAKRO ja im Tree gucken.


    Zitat von nvertigo

    Die Makros PKGCFG und MY_PKGCFG prüfen als erstes ob VDRDIR gesetzt ist, sonst wird pkg-config garnicht erst bemüht, und somit fehlt -I$(DVBDIR).


    Ist das eigentlich sinnvoll? Zwei Fälle:


    Ich baue im vdr-Tree und ziehe ein PLUGIN nach, weil es z.B. im git geupdated wurde. Wenn ich jetzt im Plugin-Verzeichnis make tippe wird es nicht richtig üebrrsetzt. Obwohl ich eine saubere VDR-Installation habe, vdr.pc in aktueller Version vorliegt und an allen drei Stellen, die das MAKRO absuchen würde (so es den etwas tun würde) vorhanden ist, wird Mein Plugin nur dann richtig gebaut, wenn ich dem make VDRDIR mitgebe.


    Ich habe gar keinen vdr. Ich übersetze trotzdem ein Plugin. Make läuft los...


    Wäre es nicht sinnvoller das Makro so umzustellen, das es auch ohne Angabe von VDRDIR auf der Befehlszeile seinen Job macht (also die drei Stellen für vdr.pc abklappert) und nur in dem Fall, wenn es partout keine vdr.pc findet, den Make-Prozess abbricht?


    Dann könnte man einzelne Plugins wieder ohne VDRDIR im Tree mit schlichtem make bauen, und die Benutzer die außerhalb bauen, und keine System-vdr.pc haben mit einer sinnvollen Benutzerbeschimpfung - äh, wollte sagen: Fehlermeldung - versehen. Nur ein Vorschlag - bevor die Plugin-Makefiles angefasst werden.


    Gruß, Ingo


    P.S.: mehrfaches make clean wäre dann auch immer mit geändertem DVBDIR möglich und würde immer einen Rückgabewert von 0 liefern.

    Entschuldigung. Aber die Postings
    [Announce] VDR developer version 1.7.35
    und
    [Announce] VDR developer version 1.7.35
    sind völliger Unsinn. Ich habe gerade gemerkt, dass ich gestern irgendwann gestern abend mit einer kaputten, falschen Version meiner Patches getestet habe... :( War wohl etwas drüber. :wand
    Und natürlich klappt auch make clean clean-plugins nicht, und make clean-plugins clean klappt auch nur 1x - aber das liegt in der Natur der Sache, wenn man vdr.pc nicht mit install-pc im System installiert hat... :wand


    Um es kurz zu machen, wenn mann die Patche, die ich hier gepostet habe nimmt, dann klappt alles: make ohne VDRDIR im Tree und auch 100x makeclean nacheinander.


    Gruß, Ingo

    Zitat von nvertigo


    Ja, mir gefiehl die Ide von ufo auch, weil sie minimalinvasiv ist, aber dann mußt Du trotzdem die PLUGIN-Makefiles anfassen... guck' Dir mal die beiden MAKEDEP-Zeilen an. Wenn Du die Makefiles der Plugins nicht anfassen willst, dann mußt Du es CXX reinpressen - hässlich, hässlich, hässlich.


    Ja, es gehört auch in die CXXFLAGS, da das zugehörige Include ein Bestandteil dieser sein sollte. Der VDR selber wurde gegen diese "externen" Header gebaut und genau so sollten die Plugins gebaut werden. Aus eben diesem Grund holt man sich ja die CXXFLAGS via pkg-config.

    Ich habe mir jetzt mal vdr-1.7.35-makefilefix14.diff angeschaut.


    - PLGCFG ist aus Make.config.template rausgeflogen, wird aber im Makefile immer noch ins vdr.pc geschrieben.
    Also entweder ganz oder gar nicht.


    - Was hat es mit
    #CINCLUDES = -I$(CWD)/include
    am Ende von Make.config.template auf sich? Braucht's das? Wenn ja, warum ist es auskommentiert?
    Ich würde das lieber nicht dort sehen.


    - Warum steht in Make.config.template wieder explizit
    CXXFLAGS = -g -O3 -Wall ...?
    Mit
    CXXFLAGS = $(CFLAGS) ...
    würden die Optionen nur *einmal* dastehen.


    - Im Makefile beim Target "plugins:" wird unter "# New Makefile" die Shell-Variable INCLUDES gesetzt und scheinbar nicht verwendet. Erst bei genauerem Hinsehen sieht man, daß wegen des weggelassenen Strichpunktes diese Variable an das nachfolgende $(MAKE) übergeben wird. Wäre es nicht deutlicher, das mit in den $(MAKE)-Aufruf reinzuschreiben? So wie das ja für VDRDIR auch schon geschieht.


    - Wenn jemand Make.config.template nach Make.config kopiert, dann schaltet er damit auch automatisch auf "local build" um.
    Sollte es nicht eher so sein, daß ein bloßes Kopieren von Make.config.template nach Make.config zunächst noch nichts ändert, und ein "local build" erst aktiviert werden muß?
    Also evtl. alles von LOCDIR= bis RESDIR= so klammern, wie es auch für M32 gemacht ist.
    Ich könnte mir sonst vorstellen, daß da so mancher überrascht wird...


    - Die Zeile
    for l in `ls $(PLUGINDIR)/src/$$i/po/*.mo`; do\
    hat wohl bei Plugins, die kein "po"-Directory haben (was durchaus zulässig ist), die Fehlermeldung
    ls: cannot access /home/kls/vdr/VDR/PLUGINS/src/svdrpdemo/po/*.mo: No such file or directory
    zur Folge. Hier sollte wohl vorher getestet werden ob $(PLUGINDIR)/src/$$i/po existiert.


    Ansonsten hat ein einfaches "make" im VDR-Source-Directory, nachdem ich das neue Make.config.template nach Make.config kopiert und angepasst hatte, bei mir alles an den richtigen Stellen erzeugt (auch mit einem alten Plugin-Makefile).
    Installieren habe ich allerdings nicht getestet, da ich das nie mache. Aber ich gehe davon aus, daß das genügend andere testen...


    Klaus

    Zitat von kls

    - PLGCFG ist aus Make.config.template rausgeflogen, wird aber im Makefile immer noch ins vdr.pc geschrieben.
    Also entweder ganz oder gar nicht.


    Das war versehentlich, ist wieder drin.

    Zitat von kls

    - Was hat es mit
    #CINCLUDES = -I$(CWD)/include
    am Ende von Make.config.template auf sich? Braucht's das? Wenn ja, warum ist es auskommentiert?
    Ich würde das lieber nicht dort sehen.


    Das brauchts, wenn man in Plugins/src/*/ direkt make aufrufen möchte. Sonst finden die Plugins die Includes nicht. Beim normalen Installieren darf das aber nich gesetzt sein, drum habe ich es da hingeschrieben. Da sollte noch ein passender Kommentar hin. Mir fällt aber nichts aussagekräftiges ein.

    Zitat von kls

    - Warum steht in Make.config.template wieder explizit
    CXXFLAGS = -g -O3 -Wall ...?
    Mit
    CXXFLAGS = $(CFLAGS) ...
    würden die Optionen nur *einmal* dastehen.


    Das Problem ist, dass das nicht der Reihenfolge nach abgehandelt wird. Man hat dann bei CXXFLAGS zweimal -fPIC drinstehen, weil es erst an die CFLAGS angehängt wird und dann nochmal an die CXXFLAGS. Ist mehr eine kosmetische Sache. Es geht aber auch nicht anders, weil man ja bedenken muss, dass CFLAGS und CXXFLAGS überschrieben werden könnten.

    Zitat von kls

    - Im Makefile beim Target "plugins:" wird unter "# New Makefile" die Shell-Variable INCLUDES gesetzt und scheinbar nicht verwendet. Erst bei genauerem Hinsehen sieht man, daß wegen des weggelassenen Strichpunktes diese Variable an das nachfolgende $(MAKE) übergeben wird. Wäre es nicht deutlicher, das mit in den $(MAKE)-Aufruf reinzuschreiben? So wie das ja für VDRDIR auch schon geschieht.


    Das hat den Grund, dass ich damit nichts überschreibe. Wenn es nach dem "make" steht wird alles was im Pluginmakefile included wird ignoriert. So füge ich nur am Anfang ein Stück ein.

    Zitat von kls

    - Wenn jemand Make.config.template nach Make.config kopiert, dann schaltet er damit auch automatisch auf "local build" um.
    Sollte es nicht eher so sein, daß ein bloßes Kopieren von Make.config.template nach Make.config zunächst noch nichts ändert, und ein "local build" erst aktiviert werden muß?
    Also evtl. alles von LOCDIR= bis RESDIR= so klammern, wie es auch für M32 gemacht ist.
    Ich könnte mir sonst vorstellen, daß da so mancher überrascht wird...


    Ja, das hänge ich auch noch mit rein.

    Zitat von kls

    - Die Zeile
    for l in `ls $(PLUGINDIR)/src/$$i/po/*.mo`; do\
    hat wohl bei Plugins, die kein "po"-Directory haben (was durchaus zulässig ist), die Fehlermeldung
    ls: cannot access /home/kls/vdr/VDR/PLUGINS/src/svdrpdemo/po/*.mo: No such file or directory
    zur Folge. Hier sollte wohl vorher getestet werden ob $(PLUGINDIR)/src/$$i/po existiert.


    Auch mit angehängt.

    Zitat von kls

    Ansonsten hat ein einfaches "make" im VDR-Source-Directory, nachdem ich das neue Make.config.template nach Make.config kopiert und angepasst hatte, bei mir alles an den richtigen Stellen erzeugt (auch mit einem alten Plugin-Makefile).
    Installieren habe ich allerdings nicht getestet, da ich das nie mache. Aber ich gehe davon aus, daß das genügend andere testen...



    Anbei V16. V15 habe ich Firefly privat geschickt, um zu erfahren, ob sein Problem weg ist. Ich habe aber keine Antwort erhalten. Um keine Verwirrung zu stiften, habe ich diese V15 übersprungen. Die Änderungen von V15 sind hier mit bei.


    An die Pluginetwickler, die Pluginmakefiles haben sich minimal geändert. Schaut euch am besten im Diff an, was mit dem hello-Plugin passiert ist.

    Zitat von Copperhead


    Das brauchts, wenn man in Plugins/src/*/ direkt make aufrufen möchte. Sonst finden die Plugins die Includes nicht. Beim normalen Installieren darf das aber nich gesetzt sein, drum habe ich es da hingeschrieben. Da sollte noch ein passender Kommentar hin. Mir fällt aber nichts aussagekräftiges ein.


    Gilt das dann auch nur für alte Plugin-Makefiles? Weil es steht ja unter "# Fallback for plugins with old makefiles".
    Aber wo genau würde das denn benutzt? Weder in den alten noch in den neuen Plugin-Makefiles gibt es ein $(CINCLUDES).


    Zitat


    Das hat den Grund, dass ich damit nichts überschreibe. Wenn es nach dem "make" steht wird alles was im Pluginmakefile included wird ignoriert. So füge ich nur am Anfang ein Stück ein.


    Ach so, für "make" macht es anscheinend einen Unterschied, ob eine Variable über das Environment übergeben wird oder über die Kommandozeile. Das war mir auch neu...


    Zitat


    Auch mit angehängt.


    Das ist etwas unschön, weil das komplette 'ls' zweimal aufgerufen wird (und die Fehlermeldung kommt deswegen immer noch).
    Es sollte doch reichen, auf die Existenz von "$(PLUGINDIR)/src/$$i/po" zu prüfen.


    Klaus

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden