Plugins mit altem Makefile - Sammlung

Warum werden (gerade im Linux Umfeld) bestehende Dinge immer so extrem verteidigt? 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.

Aber da habe ich mich schon dran gewöhnt, einerseits haben grosse Projekte (z.B. ffmepg) keine Hemmungen ständig an der API rumzufummeln so das man für alle Programme die sie nutzen ständig Patches benötigt (und der ganze Kram damit relativ unbrauchbar wird). Aber andererseits reicht schon die Erwähnung einer Idee die evtl. von bestehenden Standarts abweicht um Kämpfe anzuzetteln

Wenn ich das nächste mal Spaß haben will bringe ich mal das zur Diskusion: http://www.vdr-wiki.de/wiki/index.php/Vdr-opticaldrive *)
Mal sehen wie lange es dauert bis ich für den Vorschlag gesteinigt werde Denn vermutlich ist schon die blosse Idee sowas von böse, weil hier müssen sich mehere Autohren ja auf was gemeinsames einigen was den Usern und den Distributionen das Leben vereinfachen würde. Und sowas geht nun wirklich nicht.

Manchmal wundere ich mich nur...

Zitat von wastl

dieses distributionszentrierte denken geht mir ja schon lange auf den keks. im vdr-umfeld ganz besonders.

Es geht hier ja noch nicht mal um Distributionen. Es geht darum das Plugins ALLE Teil des VDR sind. Und es geht draum die alle sauber unter einem Hut zu bringen.

Klassisches Beispiel sind die Senderlogos, jedes Plugin für sich macht das korrekt. Aber was da in der Gesamtheit bei rauskommt ist einfach nur albern.
Gut, nachdem das Problem mittlerweile einige Jahre besteht gibt es mittlerweile erste Ansätze das sich da evtl. mal die nächsten jahre was ändert. Juhuuu
Bleiben nur noch die 20 anderen (ähnlich gelagerten) Baustellen.

Und das geht jetzt auch nicht gegen Einzelpersonen, sondern irgendwie scheint es sich so ganz natürlich zu ergeben das z.B. jedes neues Plugin garantiert nen Logoschema verwendet das bissher noch kein anderes Plugin verwendet hat
Nu könnte man z.B. das Namensschema per Makefilevariable vorgeben. Aber wer wagt denn heutzutage noch sowas vorzuschlagen?

cu

*) BTW: Ich behaupte nicht das das die beste Idee ist, aber es ist bissher die einzige.

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 wastl

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.

Nur erstmal noch mal schnell dazu.

Mit distro freundlich meine ich nicht Debian, Ubuntu, yaVDR, easyVDR oder FHS oder ähnliches.

Es geht schlicht und einfach um den User der den VDR installiert (wenn er es mit make install macht ist er selber die Distribution). Also...
Es ist nicht Vorschrift das sich alle Plugins die Logos verwenden auf die Makefilevariable LOGOFORMAT regaieren, aber es wäre höflich. Weil dann könnte der User im globalen Pluginconfigfile LOGOFORMAT=jpg setzen (wenn er ein jpg Logopack hat) und könnte dann per make install den Kram installieren ohne in jedem Plugin rumpatchen zu müssen.
Ferner könnten Distributionen in den Paketbauregeln LOGOFORMAT=jpg setzen (wenn sie ein Logopacket mit jpg mitliefern) ohne für jedes Plugin nen Patch zu pflegen.

Ist jetzt nur nen Beispiel (nicht auf die Implementation festnageln ) das zeigt was ich mit "höflickeit" meine. Und mir kann keiner erzählen das die Welt untergeht wenn Devs auf diese Art höflich sind.

cu

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

Moin!

Hui, was für eine Aufregung...

Es geht doch nur darum, dass ein Plugin-Autor ein paar Konfigurationsvariablen zur Verfügung stellt, damit Distributoren es etwas leichter haben.
Mal abgesehen davon, dass es sowieso vernünftig ist, hat das überhaupt nichts damit zu tun, dass man als Autor irgendwelchen "Forderungen" von Distributoren ausgesetzt ist.
Das ist einfach nur die angesprochene Höflichkeit, die alle in einer Community gegenseitig aufbringen sollten. Denn ohne den gegenseitigen Respekt ist eine Community einfach nur kacke und es bringt keinen Spaß, sich dort aufzuhalten.
Außerdem sind fest verdrahtete, distributionsspezifische Konstanten schlechter Stil (ich nehme mich nicht davon aus, auch sowas zu tun, nehme aber gerne Patches entgegen und integriere sie vernünftig).

Wenn ich merke, dass ein Plugin irgendwas fest verdrahtet hat, was nicht in meine Distribution passt, dann kann ich das zwar irgendwie patchen, aber sinnvoller ist es doch, einen Patch zu entwickeln, der Upstream aufgenommen werden kann, so dass der Autor nichts an seiner Konfiguration ändern muss (sein Wert als Default), aber ein Distributor einfach eine Variable an make übergeben kann und alle sind glücklich.

Das ist doch nicht weiter schlimm...

Ich schlage vor, wir kommen wieder zurück zum Thema, wir können uns aber auch gerne in einem anderen Thread weiter darüber austauschen, am besten mit einem konkreten Beispiel eines "doofen" Plugins.

Lars.

so eine bescheuerte diskussion. keine_ahnung ich kann dich gut verstehen, du willst es eigentlich "allen" recht machen, und man reagiert mit
kleingeisterei. entwickler sind anstrengender als kleine pubertierende mädchen ...

Um davon mal ab zu lenken hätte ich auch noch eine blöde Frage
Da ich noch keinen neuen VDR gebaut habe, konnte ich dies auch noch nicht ausprobieren. Sind die neuen Makefiles der Plugins abwärtskompatibel?

Zitat von SOliver

Sind die neuen Makefiles der Plugins abwärtskompatibel?

Nein. Deshalb liefern einige Plugin-Entwickler zwei Makefiles mit. Die alten Makefiles laufen mit gewissen Einschränkungen noch im neuen VDR. Umgekehrt geht es aber nicht.

Die Frages ist in welchem Kontext. Es dürfte helfen, wenn man vdr-dev mit einer entsprechenden /usr/lib/pkgconfig/vdr.pc ausstattet bzw. diese lokal entsprechend ablegt: [0.5-stable] und die neuen Makefiles

Dann bleibt nur noch das Problem mit /usr/include/vdr/libsi (statt dem vorgesehenen /usr/include/libsi) ([ANNOUNCE] VDR developer version 1.7.36)

Super, danke.

hotzenplotz5

bitte das naechste mal mit sinnerfassendem lesen probieren!

ich trete ja dafuer ein, programme sauber zu erstellen (inkl.allgemeiner konfig., install., ...)
der antrieb dahinter kann aber nicht irgendeine distro/paketersteller sein, sondern eine weiter gefasste, ueber einzelne distros hinausgehende einstellung beim entwickler.

ich vertrete hier in keiner weise irgendwelche festverdrahtungen - im gegenteil. wer mich kennt (du offenbar nicht) weiss auch, dass ich anregungen / aenderungen, wenn sie schoen dazupassen, gerne uebernehme und fuer anregungen auch dankbar bin. gerade Keine_Ahnung sticht immer wieder durch sehr gute ideen hervor.

Zitat

Keine_Ahnung sticht immer wieder durch sehr gute ideen hervor.

ganz deiner meinung !

Zitat

wer mich kennt (du offenbar nicht) weiss auch, dass ich anregungen / aenderungen, wenn sie schoen dazupassen, gerne uebernehme und fuer anregungen auch dankbar bin

ist doch gut. daher hab ich ja auch "bescheuerte diskussion" geschrieben.

Zitat

der antrieb dahinter kann aber nicht irgendeine distro/paketersteller sein, sondern eine weiter gefasste, ueber einzelne distros hinausgehende einstellung beim entwickler.

ganz genau das widerspricht sich ja nicht. wenn dann aber ein paketbauer kommt (egal welche distri) und das gerne "weiter gefasst" hätte. dann wird das von diversen leuten im portal immer aufs neue als sonderwunsch der distri reduziert. das muss nichtmal der plugin/software entwickler sein.
das ist anstrengend und dumm.

ich bezog mich in meiner kritik ja auch auf leute, die nur ihre distro im auge haben und darueber hinaus nichts sehen (wollen). und die gibt es leider. gerade im vdr-bereich. und _das_ ist fuer mich kleingeisterei.

dass keine_ahnung im prinzip diesselbe auffassung vertritt wie ich und mit seinem posting eigentlich nicht distrospezifika, sondern eine allgemein gehaltene entwicklung gemeint hat, hat er oben ja korrigiert.

Copperhead:

das handling der logos in graphlcd gefaellt mir selber auch nicht und ich habe da auch schon ideen, das ganze um einiges flexibler und benutzerfreundlicher zu machen. jetzt muss ich nur noch die zeit fuer die verwirklichung finden ...

Ich hätte da gerne mal ein Problem mit dem neuen Makefile des live-Plugins und Ubuntu/Launchpad:
https://github.com/CReimer/vdr…master/pages/Makefile#L19

Es geht um die Ermittlung der GIT_REV, die mit Arch Linux beim lokalen Bauen interessanterweise ohne Probleme definiert wird (-DGIT_REV="311b2ee" PKGBUILD: https://github.com/seahawk1986…plugins/vdr-live/PKGBUILD), unter Ubuntu bzw. mit Launchpad beim dpkg-buildpackage aber kläglich scheitert, wenn man sich das Quellpaket https://github.com/CReimer/vdr…ive/archive/master.taz.gz heruntergeladen hat und daraus dann das Paket bauen will, weil git dann einfach kein Git Repo vorfindet.

Das dürfte in der jetzigen Form vermutlich öfters Probleme machen, wenn jemand keinen lokalen Clone des Repos nutzt, sondern einfach so das Quellpaket herunterlädt.

Mein Problem ist folgendes - wenn GIT_REV nicht gesetzt wurde, baut er libpages.a nicht und damit schlägt der Paketbau fehl: https://launchpadlibrarian.net…cise_FAILEDTOBUILD.txt.gz

g++ -g -Wall -Werror=overloaded-virtual -Wno-parentheses -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/build/buildd/vdr-1.7.37/include -Wno-overloaded-virtual -Wno-unused-variable  -Wno-unused-but-set-variable -c -DPLUGIN_NAME_I18N='"live"' -DTNTVERSION=20100  -DHAVE_LIBPCRECPP -I.. -o pageelems.o pageelems.cpp
pageelems.ecpp: In member function 'virtual unsigned int {anonymous}::_component_::about_tt_box_type::operator()(tnt::HttpRequest&, tnt::HttpReply&, tnt::QueryParams&)':
pageelems.ecpp:391:21: error: 'GIT_REV' was not declared in this scope
make[2]: *** [pageelems.o] Error 1
make[2]: Leaving directory `/build/buildd/vdr-plugin-live-0.2.0.99+git20121226/pages'
make[2]: Entering directory `/build/buildd/vdr-plugin-live-0.2.0.99+git20121226/css'
[...]
g++ -g -Wall -Werror=overloaded-virtual -Wno-parentheses -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE  -I/build/buildd/vdr-1.7.37/include -I/usr/include  -Wl,-Bsymbolic-functions -Wl,-z,relro -shared live.o thread.o tntconfig.o setup.o i18n.o timers.o tools.o recman.o tasks.o status.o epg_events.o epgsearch.o grab.o md5.o filecache.o livefeatures.o preload.o timerconflict.o users.o -Wl,--whole-archive pages/libpages.a css/libcss.a javascript/libjavascript.a -Wl,--no-whole-archive -L/usr/lib/i386-linux-gnu -lpcrecpp -lpcre -L/usr/lib -ltntnet -lcxxtools -o libvdr-live.so
g++: error: pages/libpages.a: No such file or directory
make[1]: *** [libvdr-live.so] Error 1
make[1]: Leaving directory `/build/buildd/vdr-plugin-live-0.2.0.99+git20121226'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Also müsste man entweder GIT_REV vorher schon mal definieren oder einen Fallback einbauen:

DEFINES ?= -DPLUGIN_NAME_I18N='"$(PLUGIN)"' -DTNTVERSION=$(TNTVERSION) $(if $(GIT_REV), -DGIT_REV='"$(GIT_REV)"', -DGIT_REV='"dummy"')

Zitat von Copperhead

Warte. Du vergleichst da zwei verschiedene Dinge. Das PKGBUILD kompiliert noch das alte Plugin mit dem alten Makefile.

Dann bin ich jetzt ganz durcheinander... Ich dachte du hättest das hier extra mit den neuen Makefiles aufgesetzt: https://github.com/CReimer/vdr-plugin-live
Die weichen ja auch von dem Git-Stand auf vdr-developer.org ab und laut Commits sind die Makefiles für VDR 1.7.36