Beiträge von wastl

das hat aber nix mit hoeflichkeit oder was weiss ich was zu tun, sondern damit, ob das programm so entwickelt ist, dass es allgemein einsetzbar ist.
das logobeispiel ist da ein denkbar schlechtes (und nicht nur deswegen, dass es einem beim gedanken, JPEG fuer logos zu verwenden, das grausen kommen sollte).

Zitat von Keine_Ahnung

Da erwähnt man mal beiläufig das man es toll fände wenn Devs auch etwas die Bedürfnisse von Distributionen berücksichtigen und schon gehts extrem auf Abwehr.

wieviele distros gibt es? gerade im linux-umfeld?

ich plaediere dafuer, sauber zu entwickeln, aber auch dafuer, dass sich distros an vorgaben halten. was hat das bitte mit abwehr zu tun.

wenn sowohl entwickler als auch distros/paketierer sauber arbeiten, bedarf es so einer aussage (pluginentwickler sollen den paketierern entgegen kommen) nicht.

wie gesagt. ich finde deinen denkansatz falsch.
entwickler sollen so entwickeln, dass das produkt moeglichst allgemein einsetzbar ist. aber sie sollen dabei keinen gedanken an eine spez. distro verschwenden, da genau diese allgemeine einsetzbarkeit dadurch gefaehrdet ist.

/wastl

PS: auf die aenderungen des postings konnte ich noch nicht eingehen, da ich da auf einem soft-keyboard tippe (und das dauert ...)
ad logos: kann man anders, eleganter, ... machen, durchaus.
ist aber in keiner weise eine distro- bzw. paketierer-diskussion. aus oben genannten gruenden.
das es da verbesserungen bedarf, steht ausser diskussion. sicher aber nicht deswegen, um einen paketersteller gleucklich zu machen ...

Zitat von Keine_Ahnung

Ich finde Pluginauthoren sollten etwas Rücksicht auf die Paketbauer nehmen.

aber sowas von ganz sicher nicht!

dieses distributionszentrierte denken geht mir ja schon lange auf den keks. im vdr-umfeld ganz besonders.
wenn so gedacht wird, laeuft sowieso etwas falsch.

wieviele distros gibts mit vdr-paketen? und da meine ich jetzt nicht nur die vdr-spezifischen. und da soll vielleicht fuer einen paketbauer etwas eingebaut werden, nur weil er es so will? GANZ SICHER NICHT!

adaptierungen, die mehreren zugute kommen und dem unix-gedanken (bzw. im konkreten fall den vdr-vorgaben) entsprechen: bitte gerne. aber ruecksichtnahme auf bestimmte extrawuerste von distros: soweit kommts noch. da laeuft der denkprozess falsch. programme sollen so gestaltet sein, dass sie sauber ausgeliefert werden koennen (statische pfade im source-code gehoeren da nicht dazu). und die distros bzw. die paketbauer haben sich gefaelligst genauso daran zu halten. wenn das nicht geht: distro-spez. beduerfnisse ueber patchsets oder dgl...
/wastl

protokol ausfindig machen und dazuprogrammieren

news (vdr-plugin-graphlcd):

• Makefile: should now be compliant with 'new style make' and old vdr versions (incl. 1.4.x)

so. habe das Makefile ausgehend von einem via newplugin generiertem makefile neu erzeugt und angereichert, sodass es jetzt fuer div. vdr-versionen (neu, alt, sogar 1.4.x) brauchbar sein sollte, egal ob pkg-config das vdr.pc vom tree holt oder vom system, es werden auch auf keine dateien v. vdr mehr direkt zugegriffen und ich habe es in allen moeglichen und unmoeglichen anwendungsfaellen ausprobiert (ausg. jene, die ich uebersehen habe) ...
achtung luxusedition: ich habe sogar ein paar kommentare hineingeschrieben ...

bitte testen ...

danke Keine_Ahnung, jetzt kommt licht ins dunkel.

werde das als zusatzbedingung einbauen beim setzen v. einem leeren VDRDIR

EDIT: bad spelling, not even once ...

jetzt mal zur abwechslung mit etwas logischem denken:

wie soll es funktionieren, wenn zb. das plugin in /tmp/ entpackt wird, du dann nach /tmp/vdr-graphlcd-plugin wechselst und dort dann make eingibst, ohne dass VDRDIR bekannt ist (dh. nicht als env.variable direkt gesetzt oder beim aufruf mit VDRDIR=.... mitgegeben)?

holt sich das make dann die information von einem wahrsager ab?

Zitat

Gut, das war nur geraten. Tatsache ist das der oben zitierte Block die Ursache ist. Auskommentieren und schon funktionierts.

denke ich mir bei der unqualifizierten aussage.

Zitat

Irgendwie beeinflusst das bei mir dass keine CXXFLAGS beim Compiler
ankommen. Ich denke das daher auch die APIVERSION verschwindet.

tja. was soll man dazu sagen. das leben ist ein kommen und gehen ...

wenn du das plugin ausserhalb v. vdr kompilierst, solltest du das VDRDIR=/path/to/vdr vor dem make-aufruf nicht vergessen ...
(wenn als shell bash oder sh verwendet wird).

Zitat

Dein Makefile-Wirrwarr blicke ich jetzt auf die Schnelle nicht.

aufgrund deiner bisherigen aussagen verstehe ich jetzt, weshalb das fuer dich ein wirrwar ist ...

Zitat

Mach zwei Makefiles oder nur ein Makefile für die neuen VDR-Versionen.

GANZ

SICHER

NICHT!

Zitat

Makefiles werden nicht der Reihenfolge nach abgearbeitet. Alles passiert gleichzeitig.

nur weil man einen ausgemachten bloedsinn permanent wiederholt wird er nicht wahrer ...

alle aktuellen aenderungen von mir erfolgten aber unterhalb v. APIVERSION = $(call PKGCFG,apiversion).

auch das ifeq ($(strip $(APIVERSION)),) wird da kaum so hineinpfuschen, dass am ende ein leerer string heraus kommt ...
(und in dieses ifeq kommt es nur hinein, wenn im vdr.pc kein apiversion gesetzt ist oder vdr.pc nicht geladen werden kann)

ich sehe da jetzt nicht wirklich irgendetwas, was da diesbez. an meinen aenderungen problematisch waere ...

aber du kannst ja ein

$(info APIVERSION $(APIVERSION))

zum debuggen an geeigneten stellen einbauen, um zu sehen, wo das apiversion verloren geht ...

news (vdr-plugin-graphlcd)

• consider that both VDRDIR and PLGCFG can be empty

wie auf seite 44 bereits vorgeschlagen, werden VDRDIR und PLGCFG jetzt separat behandelt.
eine extra behandlung, dass Make.config in neueren versionen _ueberhaupt_ nicht mehr inkludiert werden kann, wird noch folgen.
getestet innerhalb v. vdr sowohl v. vdr-root aus als auch v. plugin-verzeichnis aus und von plugin-verzeichnis ausserhalb v. vdr-tree (mittels VDRDIR=<path to vdr-tree> make)

ergaenzung (behandlung v. Make.config)-inkludierung:

news (vdr-plugin-graphlcd):

• disallow inclusion of Make.config when VDR >= 1.7.33

das 'ueblich' bezweifle ich.

eines sollte klar sein:

1.7.x ist eine entwicklerversion.

das plugin sollte daher auf jeden fall auch mit der aktuell gueltigen prod-version klar kommen (1.6.x), wenn es auch noch mit aelteren versionen zurecht kommt (und dagegen spricht imho nix): noch besser.

und das alles mit einem Makefile. 2 ist 1 zuviel

und? das tut dann auch keinem weh. dann wird halt eine leere Make.config inkludiert. weltuntergang.
aber fuer aeltere vdr-versionen wird's sehr wohl benoetigt ..
und da braucht man wirklich keine alte und neue Makefile-version (wer macht denn bitte sowas??) angst vor ein paar ifdefs?

ERGAENZUNG:
bzw: wenn ab einer version Make.config nicht mehr inkludiert werden darf: += ifdef

kannst du das auch begruenden?

das VDRDIR wird wie von zoolook vorgesehen (wenn gefixt), nach dem ganzen PKGCFG-zauber gesetzt (nicht mehr _davor_ wie in meiner weiter oben vorgeschlagenen loesung).

koennte man machen, aber wie gesagt: es soll auch 1.6.x - 1.4.x unterstuetzt werden ...

es ist aber viel einfacher (und trotzdem allgemein) zu fixen (gerade getestet):

statt

ifeq ($(PLGCFG),)


	VDRDIR ?= ../../..


	PLGCFG = $(VDRDIR)/Make.config


endif

->

ifeq ($(VDRDIR),)


	VDRDIR ?= ../../..


endif


ifeq ($(PLGCFG),)


	PLGCFG = $(VDRDIR)/Make.config


endif

siehe KORREKTUR in posting[-2]:

ad VDR uebergibt VDRDIR: bei mir anscheinend nicht - rufe aber aus dem vdr-root dir das make plugins auf ...

zu 1) ich will, dass nicht nur die letzte vdr-version unterstuetzt wird, sondern auch aeltere - so dies moeglich ist. und das ist es hier.

zu 2) ohne VDRDIR ist es innerhalb des vdr-trees nicht mehr moeglich. und es wird ja nur dann gesetzt, wenn es noch _nicht_ gesetzt ist. wieso das die PKGCFG-geschichte unbrauchbar machen soll, musst du mir erst einmal erklaeren ...

KORREKTUR: sehe gerade, dass der fall v. zoolook vorgesehen waere, nur da anscheinend ein bug enthalten ist. darum hats bei mir nicht funktioniert ...

wenn in der derzeitigen version v. Makefile VDRDIR nicht gesetzt ist, wird PKGCFG trotzdem richtig gesetzt, aber auch PLGCFG scheint dann gesetzt zu werden.
weiter unten wird dann aber auf ifeq ($(PLGCFG),) getestet und darin dann VDRDIR auf ../../.. gesetzt, wenn nicht vorhanden.
da PLGCFG aber gesetzt ist (zumindest bei mir), bleibt VDRDIR ungesetzt und dann kracht es - so wie eben bei mir ...

das viel wichtigere habe ich glatt vergessen:

vor PKGCFG= muss unbedingt noch ein

ifeq ($(VDRDIR),)
 VDRDIR = ../../..
endif

eingefuegt werden!

(fuer den wohl ueblichen fall, dass VDRDIR nicht gesetzt ist (ie: all jene systeme, auf denen VDR vanilla kompiliert wird)

/wastl

ich verwende dzt. noch 1.7.28

(1.4.x ist auf einem alten rechner, ab und zu teste ich aber damit).

muss, damit es jetzt mit dem aktuellen makefile funktioniert, folgendes aendern:

export CXXFLAGS = $(call PKGCFG,cxxflags)

auf

export CXXFLAGS = $(call PKGCFG,cxxflags) $(call PKGCFG,plugincflags)

da sonst -fPIC fehlt und es dann beim linken kracht.