Redundanz in der Make.config und Make.global

  • Mir ist heute aufgefallen, dass sowohl Make.config als auch Make.global diesen Block enthalten:


    Code
    ifdef PLUGIN
    CFLAGS   += -fPIC
    CXXFLAGS += -fPIC
    endif


    Ich habe dann versucht, diesen Block aus der Make.config zu entfernen, was aber dazu führt, dass die Plugins nicht kompilieren. fPIC fehlt.



    Wenn man sich das Konzept genauer anschaut, sieht man recht schnell, dass da etwas nicht passt.


    Das Haupt-Makefile startet mehr oder weniger nur das Plugin-Makefile (Das ist ja noch in Ordnung so)


    Im Plugin Makefile:


    Erst wird PLUGIN definiert (PLUGIN = dvbsddevice)
    Dann werden die plugineigenen Compileparameter gesetzt.

    Code
    -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses


    Danach wird die Make.global eingelesen, also wird fPIC hinzugefügt.

    Code
    -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC


    Danach liest das Makefile die Make.config ein, durch die dann die Make.global überschrieben wird. Wir stehen also wieder am Anfang ohne fPIC.

    Code
    -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses



    Folgende Lösungen wären möglich:


    • CXXFLAGS und CFLAGS in der Make.config bekommen ein "+=" anstatt "="
      Nachteil: Wenn Flags als Umgebungsvariable gesetzt sind, werden diese eingelesen und landen dann vor den Flags, die in der Make.config gesetzt wurden.
      Eigentliches Ziel, wenn man Flags als Umgebungsvariable setzt ist ja eigentlich, dass diese komplett überschrieben werden. Dazu wäre aber wiederum ein "?=" notwendig.



    • In allen Plugin-Makefiles wird die Reihenfolge von Make.global und Make.config getauscht.
      Nachteil: Alle Plugin-Makefiles müssen angefasst werden
      Vorteil: Problem ein für alle mal gelöst



    • Der Block bleibt stehen
      Nachteil: Die Make.global wird ad absurdum geführt.
      Vorteil: Minimalinvasiv



    Ich halte Möglichkeit 2 für die Beste, daher habe ich gleich mal einen Patch für den VDR erstellt. (dvbhddevice Compilefix von UFO ist enthalten)


    Mir ist klar, dass dadurch wieder alle Plugins angefasst werden müssen. Mich wundert es nur, dass das Problem nicht ehr aufgefallen ist.


    Edit: Um es bei den Plugins leichter zu machen habe ich noch zwei Patches angehängt, die in so ziemlich jedem Plugin sofort funktionieren sollten.

  • Copperhead: Erst mal danke für die Erklärung, ich hatte gestern schon versucht den VDR make Mechanismus zu verstehen.

    VDR 1 (SD) : ASRock A330 GC, 1 GB RAM, TT- FF Karte rev. 2.3, 7'' TFT, Lirc X10 - Selbstbau Gehäuse - Suse 11.3 (64) vdr-1.7.10 diverse Plugins
    VDR 2 (HD) : MSI G41M-P25, 2 GB RAM, E6700 2x3.20GHz, Gainward GT220, 2TB HD, Lirc X10, TT S2-3600 USB, TT S2-1600, - Suse 11.3 (64) NvidiaTreiber 260.19 vdr-1.7.18 - xineliboutplugin 1.0.90 cvs, xine-lib 1.1.90 , s2-liplianin DVB Treiber


  • [*]In allen Plugin-Makefiles wird die Reihenfolge von Make.global und Make.config getauscht.
    Nachteil: Alle Plugin-Makefiles müssen angefasst werden
    Vorteil: Problem ein für alle mal gelöst


    Sicher der eleganteste Weg. Ich zumindest verstehe die "Make.config" als alternativen Weg um die entsprechenden Variablen vorzudefinieren. Die "Make.global" war dagegen dafür gedacht, um für die Funktion wichtige Variablenänderungen durchzuziehen. Folglich muss "Make.global" auch nach "Make.config" eingelesen werden.


    Und um ehrlich zu sein: Ich hätte "Make.global" ganz sein lassen und stattdessen in den Plugin-Makefiles direkt die Zeilen


    Code
    CFLAGS   += -fPIC
    CXXFLAGS += -fPIC


    eingebaut. Ich kann mir nicht vorstellen, dass die Make.global in absehbarer Zeit mehr enthalten wird, als diese zwei Optionen.


    Zitat


    [*]Der Block bleibt stehen
    Nachteil: Die Make.global wird ad absurdum geführt.
    Vorteil: Minimalinvasiv


    Wenn ich mich an die damalige Diskussion korrekt erinnere, dann war das Ziel der "Make.global" das Bauen ohne "Make.config". Folglich wäre das "stehen lassen" des Blocks durchaus eine Option. Allerdings nur dann, wenn die "Make.global" generell mit "-include" statt "include" geladen wird. So könnten es sich Distributionen, die die "Make.config" in das Include-DIR packen direkt sparen auch die "Make.global" mitzukopieren. In der jetzigen Konstellation ist "Make.global" bei vorhandener "Make.config" redundant.


    Wahrscheinlich wäre es sinnvoll/nötig das mal in der Mailingliste anzusprechen. Dort hätte man dann auch noch andere "VDR-Makefile-Profis" mit in der Diskussionsrunde und man könnte so letztlich zu einer Lösung kommen, die dann auch im nächsten VDR enthalten sein könnte.

  • Das ergibt aber noch viel weniger Sinn. Ohne Make.config kannst du nicht mal eben ein Plugin in den Source schmeißen und 'make plugins' eintippen.


    Es fehlen einfach zu viele Informationen. Einziger Weg (so habe ich das auch die ganze Zeit gemacht) ist es alle Infos aus der nicht vorhandenen Make.config als Parameter an den make Aufruf dranzuhängen.



    Wenn man wirklich ohne Make.config bauen will, braucht man keine Make.global sondern Plugin-Makefiles die ihre Informationen optional über pkg-config abholen.

  • Doch. Das geht.


    Du gehst von anderen Rahmenbedingungen aus.


    Wenn man ohne "Make.config" baut, dann baut man mit den "kls-Standards". Nur wenn man "FHS" nutzen will, also wenn man vorhat für eine Distribution zu paketieren, braucht man eine irgendwie geartete Übergabe etlicher Parameter um dem VDR beizubringen, wo welche Daten hingehören.


    EDIT:
    Weiterer Lesestoff zum Thema: http://patchwork.linuxtv.org/patch/12779/


    Zitat aus dem Thread von Frank Schmirler:

    Zitat


    3) in Make.config.template, remove only the line
    DEFINES += -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
    The lines with "+= -fPIC" are still necessary, as Make.config resets CFLAGS/CXXFLAGS.


    Es war also damals schon bekannt, dass Make.config die CFLAGS und CXXFLAGS resettet.


    Bleibt also folgender Konflikt:


    Entweder die "Make.global" enthält zwingend für einen sauberen Build erforderliche Änderungen. In dem Fall sollte sie aber nach der Make.config includet werden.
    ODER die Make.global ist nur nötig, wenn keine Make.config genutzt wird. In diesem Fall darf aber kein "include" sondern nur "-include" verwendet werden, um es Distributoren, die Make.config ausliefern, zu ermöglichen, auf die "Make.global" ganz zu verzichten.


    Eines von beiden wäre eine Lösung. Die aktuelle Situation ist in der Form ziemlich unsinnig.


    Am einfachsten umzusetzen wäre die zweite Option. Schon heute haben die allermeisten Plugins ein "-include" für die "Make.global" um rückwärtskompatibel zu bleiben. Es wären lediglich die VDR-eigenen Plugins zu fixen.

  • Könnte man. Wäre das gleiche. Ab dann geht aber kein Bauen ohne "Make.config" mehr und soweit ich das sehe soll genau das möglich sein ;)


    An so grundlegenden Sachen würde ich auch nicht rütteln wollen. Ich hätte garnicht erst eine "Make.global" erfunden. Hatte ich aber in einem vorigen Posting schonmal erwähnt.


    Edit: Es läuft darauf hinaus die zwei Optionen in der Mailingliste mal anzusprechen:


    1. Make.global enthält wichtige immer anzuwendende Build-Optionen. In diesem Fall muss sie nach Make.config includet werden. In der "Make.config.template" kann dann der Block mit dem "-fPIC" raus


    2. Make.global wird zum Fallback für "Bauen ohne Make.config" degradiert. In dem Fall darf es aber nicht mehr zwinged erforderlich sein, diese zu haben (kein "include" sondern nur noch "-include").


    Wenn niemand schneller ist, dann sende ich später mal eine Mail in die Liste.

  • Was hast du eigentlich immer mit der Mailingliste... Klaus wollte nur, dass ich es zur Diskussion stelle. Wo ich das mache, hat er mir überlassen.


    Es kann doch nicht sein, dass jeder den VDR "anders" baut. Da muss ein einheitlicher Weg her. Dazu kommt dann doch, dass der VDR neuerdings auch pkgconfig *.pc Dateien ablegt, die dann wieder von niemandem benutzt werden.

  • Mein Gefühl ist/war, dass man in der Mainlingliste mehr Entwickler erreicht. Außerdem gibt es nicht nur deutsche Nutzer. Einen Fehler an einem Patch, der ursprünglich aus der Mailingliste kam an einer anderen Stelle zu diskutieren, ohne allen an der damaligen Diskussion betroffenen darauf hinzuweisen finde ich wenig zielführend. Immerhin wurde die Änderung nicht nur von Klaus sondern mittlerweile auch von etlichen Plugin-Entwicklern übernommen.

  • Vorschlag:


    am Anfang von Make.global "-include Make.config". Danach dann die für alle verbindlichen Einstellungen in Make.global. Den -fPIC-Block dann aus der Make.config entfernen.


    Gruß, Ingo

  • Auch möglich. Zusammen mit der Option "Make.global wieder komplett abschaffen und -fPIC in die Plugin-Makefiles" hätten wir dann schon 4 Optionen ;)


    Edit: Nachtrag. Was du vorhast wäre, von Plugin-Makefile-Seite, ein Abschaffen der Make.config. Fande ich schlechter als eine der anderen Optionen, da damit eine "Rückwärtskompatibilität" schwierig machbar ist.

  • Kann es ein das es jeder anderst versteht? ;)


    So wie ich das sehe stehen in der make.global Sachen die vom VDR vorgegeben und in jedem Plugin genutzt werden. So z.B. die grundlegenden Kompiler|Linker Optionen (sollten ja für alle Plugins gleich sein). Hier hat der Nutzer nix drin rumzueditieren.


    In der make.config stehen alle Benutzereinstellungen, sei es die für den VDR selber (z.B. "VDR LIRC_DEVICE") oder Pluginkonfigurationen (z.B. "EXTRECMENU_HAVE_USERCOMMAND_PATCH").


    Also, die make.global ist Pflicht und die make.config ist optional.


    Also "### The C compiler and options:" aus der make.config rauswerden weil es jetzt in die make.global gehört.


    cu

  • Gerne. Dann muss aber die Include-Reihenfolge in den Plugins angepasst werden. Zuerst Make.config und danach Make.global.


    Warum? Make.cofig setzt doch keine Variablen die von Make.global ausgewertet werden. Eigentlich haben die beiden doch nix miteinander zu tun.


    cu

  • Die Make.config und/oder Parameter an das Makefile setzen die CFLAGS und das ist auch durchaus so gewollt, da jede Distribution hier andere Standard-CFLAGS hat. Wenn die Make.config nun nach der Make.global geladen wird, dann überschreiben die dort gesetzten CFLAGS das über Make.global gesetzte -fPIC.

  • Die Make.config und/oder Parameter an das Makefile setzen die CFLAGS und das ist auch durchaus so gewollt


    Ja, aber das sollte aus der Make.config raus und in die Make.global. Und zwar in dieser Form
    ---
    ### The C compiler and options:


    CC ?= gcc
    CFLAGS ?= -g -O3 -Wall


    CXX ?= g++
    CXXFLAGS ?= -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses
    ---


    Ferner sollte das aus dem Plugin Makefile raus
    ----
    ### The C++ compiler and options:


    CXX ?= g++
    CXXFLAGS ?= -g -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses
    ----


    Dann nutzen alle Plugins die selben Optionen (aus der Make.global) aber Distributionen können sie trozdem überschreiben. CXXFLAGS und Co. werden unter debian z.B. automatisch passend zu den Distributionsdefaults gesetzt.


    cu

  • Also ich finde die Lösung von Keine_Ahnung bisher am besten. Da wäre ich nie drauf gekommen.


    Edit: Obwohl: Wenn man jetzt ein Plugin einfach so bauen will, also mit make VDRDIR=/usr/include/vdr, hätte man wieder nur die VDR-Standard Compileparameter. Außer die Distribution ändert die Make.global.


    Beispiel Archlinux, dort werden die CFLAGS nur als Umgebungsvariable gesetzt wenn man ein PKGBUILD über makepkg aufruft.


    Edit2: Man könnte die Make.global natürlich auch einfach beim Compilieren generieren.

  • ... Was der Idee von "Make.global wird nicht geändert" wiedersprechen würde.


    Ich halte Compile-Parameter durchaus für "individualisierbar". Es ist hier nicht nötig feste Werte zu erzwingen. Beim "-fPIC" ist das anders.


    Sie sind ja auch individualisierbar Debian setzt sie z.B. beim Paketbau automatisch. Und wenn man wirklich individuelle Wünsche hat kann man sie ja in der Make.config explizit überschreiben (die wird ja gleich danach eingebunden).


    Konsequent wäre IMHO noch


    In die make.global
    ----
    PLUGIN_CFLAGS ?= -fPIC
    PLUGIN_CXXFLAGS ?= -fPIC
    ----
    (die könnten dann in der make.config oder per make Kommandzeile überschrieben werden)


    Und in die Pluginmakefiles
    ---
    ifdef PLUGIN
    CFLAGS += $(PLUGIN_CFLAGS)
    CXXFLAGS += $(PLUGIN_CXXFLAGS)
    endif
    ---


    Edit: Obwohl: Wenn man jetzt ein Plugin einfach so bauen will, also mit make VDRDIR=/usr/include/vdr, hätte man wieder nur die VDR-Standard Compileparameter. Außer die Distribution ändert die Make.global.


    Jup, es spricht ja nix dagegen wenn die Distribution die Make.global zu den Distributionsdefaults ändert. Die (also die Distributionsvariante der Make.global) würde dnan ja eh vom vdr-dev Paket der Distribution in /usr/include/vdr gepeichert werden.


    Und dann würde jedes "make VDRDIR=/usr/include/vdr" eines Plugins die korrekten Defaults nutzen.


    cu

Jetzt mitmachen!

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