VDR Portal

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

Quoted from "Copperhead"

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



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.

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.

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.

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.

Quoted from "Mreimer"

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.

Quoted from "Mreimer"

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

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

Quoted from "Mreimer"

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

Quoted from "Copperhead"

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