You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

  • "Copperhead" started this thread

Posts: 5,326

Location: Main-Spessart

  • Send private message

1

Tuesday, November 20th 2012, 6:39pm

Redundanz in der Make.config und Make.global

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

Source code

1
2
3
4
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.

Source code

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


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

Source code

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

Source code

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



Folgende Lösungen wären möglich:

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


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


  3. 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 has attached the following files:
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

This post has been edited 2 times, last edit by "Copperhead" (Nov 20th 2012, 6:48pm)


rudirabbit

Professional

Posts: 1,352

Occupation: Kfz Elektroniker

  • Send private message

2

Tuesday, November 20th 2012, 7:22pm

@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

3

Wednesday, November 21st 2012, 7:18am

RE: Redundanz in der Make.config und Make.global


[*]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

Source code

1
2
CFLAGS   += -fPIC
CXXFLAGS += -fPIC


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

Quoted


[*]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.

  • "Copperhead" started this thread

Posts: 5,326

Location: Main-Spessart

  • Send private message

4

Wednesday, November 21st 2012, 9:19am

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.
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

5

Wednesday, November 21st 2012, 9:32am

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:

Quoted


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.

This post has been edited 2 times, last edit by "Mreimer" (Nov 21st 2012, 9:41am)


  • "Copperhead" started this thread

Posts: 5,326

Location: Main-Spessart

  • Send private message

6

Wednesday, November 21st 2012, 10:19am

Jetzt hast du mich komplett raus gebracht. Wenn man die Make.config nicht will, könnte man doch auch eine Art Mini-Make.config bauen, die mehr oder weniger den Inhalt von Make.global hat.


?????
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

7

Wednesday, November 21st 2012, 10:24am

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.

This post has been edited 2 times, last edit by "Mreimer" (Nov 21st 2012, 10:41am)


  • "Copperhead" started this thread

Posts: 5,326

Location: Main-Spessart

  • Send private message

8

Wednesday, November 21st 2012, 10:49am

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.
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

9

Wednesday, November 21st 2012, 11:02am

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.

This post has been edited 1 times, last edit by "Mreimer" (Nov 21st 2012, 11:08am)


10

Wednesday, November 21st 2012, 11:08am

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
gen2vdr v3(migriert auf gentoo amd64), Asus Sabertooth FX990, AMD FX8150, 16GB 1833, CineS2(media_build_experimental), L4M USB RC(inputevxd), Asus gts450silent
vdr-2.1.6(jumpplay,binaryskip,menuselection,menuorg,mainmenuhook), vertex4 ssd (system), mdraid5 9TB, zfs raidz1 4TB (video)

11

Wednesday, November 21st 2012, 11:09am

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.

This post has been edited 2 times, last edit by "Mreimer" (Nov 21st 2012, 11:19am)


12

Wednesday, November 21st 2012, 11:22am

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

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

13

Wednesday, November 21st 2012, 11:27am

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

14

Wednesday, November 21st 2012, 11:33am

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

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

15

Wednesday, November 21st 2012, 11:36am

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.

  • "Copperhead" started this thread

Posts: 5,326

Location: Main-Spessart

  • Send private message

16

Wednesday, November 21st 2012, 11:38am

Schön, dass jetzt auch noch mehr in die Diskussion einsteigen. Ich habe jetzt auch mal was in der Mailingliste gepostet. (An der Stelle: Ich hasse es Englisch zu schreiben/sprechen/lesen.)
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

17

Wednesday, November 21st 2012, 11:39am

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

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

  • "Copperhead" started this thread

Posts: 5,326

Location: Main-Spessart

  • Send private message

18

Wednesday, November 21st 2012, 11:42am

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.
VDR4Arch --> Lian-Li PC-C37B | ASRock Q1900M | 4GB RAM | SanDisk SDSSDP064G | Samsung HD155UI | DD Cine S2 V6.2 | ZOTAC GT630 (Rev. 2) Zone Edition

This post has been edited 1 times, last edit by "Copperhead" (Nov 21st 2012, 11:50am)


19

Wednesday, November 21st 2012, 12:02pm

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

20

Wednesday, November 21st 2012, 12:23pm

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

Mein VDR

Mein VDR
Digitainer2xBouget DVB-SDebian Squeeze (Kernel 2.6.35.3 von kernel.org)Softdevice Ausgabepluginvdr 1.6.0-3 (Extensions Patch 72) und viele Plugins von SourceMedion X10 FernbedienungSDC-Megtron Display (240x128x1) mit GraphLCD-PluginFreevo 1.9.0
Vodcatcher Helper in ein freundliches DEB verpackt, Tester Willkommen: http://dl.dropbox.com/s/705bh6ydgisfrqu/index.htmlFingerprint: 8A104A00D5031773A9F72A19BAEE135EA7860149

This post has been edited 5 times, last edit by "Keine_Ahnung" (Nov 21st 2012, 12:40pm)


Similar threads