BTW: was ist eigentlich aus deinem xmame-Plugin geworden?
Plugins mit altem Makefile - Sammlung
-
-
BTW: was ist eigentlich aus deinem xmame-Plugin geworden?
Das scheint keiner mehr zu verwenden, bzw. hat anscheinend
noch nie jemand verwendet. Aber da das Plugin recht simpel
ist, werd ich mich mal an der Anpassung versuchen. -
Hi, habe ein Patch fuer die Makefiles des UPnP-Plugins dem Autor zukommen lassen, ich hoffe mal, er uebernimmt ihn bald.
Ciao, Lucian
-
Ich weiß jetzt nicht, ob das unbedingt hierher gehört. ...
Wie ist das eigentlich mit den Plugins, die zusätzliche Binarys, wie z.B. graphtft --> graphtft-fe enthalten?
Sehen es die "neuen" Makfiles vor, dass diese auch gleich an die entsprechenden Stellen installiert werden, bzw. ist so eine Funktion überhaupt machbar oder sinnvoll?
-
Sehen es die "neuen" Makfiles vor, dass diese auch gleich an die entsprechenden Stellen installiert werden, bzw. ist so eine Funktion überhaupt machbar oder sinnvoll?
Das ist vorgesehen und wird auch schon umgesetzt.Einfach ein zusätzliches install-Target hinzufügen. z.B. install-themes oder install-conf.
-
Moin!
Das ist vorgesehen und wird auch schon umgesetzt.Einfach ein zusätzliches install-Target hinzufügen. z.B. install-themes oder install-conf.
Dazu habe ich eine Frage.restfulapi z.B. braucht noch eine statische config-Datei (API.html) im Plugin-Configdir (ja, eigentlich sollte sie wohl im Resource-Dir liegen, gab's damals aber noch nicht, ist für die Frage auch nicht wichtig, da es um das Makefile geht :)).
Deswegen hab ich ein neues Target eingebaut:CodeCONFDIR = $(call PKGCFG,configdir) PLGCONFDIR = $(CONFDIR)/plugins/$(PLUGIN) CFGS = API.html install-cfg: $(CFGS) install -D $^ $(DESTDIR)$(PLGCONFDIR)/$^
install-cfg hab ich dann als Abhängigkeit bei install eingetragen, damit es automatisch mit ausgeführt wird.
Ist das so wie gedacht oder sollte install unabhängig davon sein, so dass der Paketschnürer entscheiden kann, ob es installiert wird oder nicht?Lars.
-
Ist das so wie gedacht oder sollte install unabhängig davon sein, so dass der Paketschnürer entscheiden kann, ob es installiert wird oder nicht?
Ich denke das alle davon ausgehen das "make install" alles korrekt installiert.
Ich habe hier aber auch sowas gemacht http://projects.vdr-developer.…/Make.config.template#L13
(PLUGIN_UACTIVITY_NOINSTALL_BIN), dann könnte man das (z.B. beim Paketbau) an der Kommandozeile angeben wenn diese zusätzlichen Sachen nicht im Paket gewünscht sind.cu
-
Ist so genau richtig. Aber wie du schon gesagt hast sollte dafür das ResourceDirectory genommen werden.
-
Ich habe hier aber auch sowas gemacht http://projects.vdr-developer.…/Make.config.template#L13
(PLUGIN_UACTIVITY_NOINSTALL_BIN), dann könnte man das (z.B. beim Paketbau) an der Kommandozeile angeben wenn diese zusätzlichen Sachen nicht im Paket gewünscht sind.Kann man machen.... muss man aber nicht.
Beim Paketieren ist es kein Thema ins Buildscript noch ein "rm -r $pkgdir/usr/bin" mit reinzubauen um ggf. alle bei "make install" installierten Binaries wieder loszuwerden. -
Kann man machen.... muss man aber nicht.
Beim Paketieren ist es kein Thema ins Buildscript noch ein "rm -r $pkgdir/usr/bin" mit reinzubauen um ggf. alle bei "make install" installierten Binaries wieder loszuwerden.Stimmt natürlich. Aber dann muss der Paketbauer ja extra...
Ferner, wenn sich was ändert (z.B. das Script wandert nach /usr/share/<paketname>/<script> *) ) muss der Paketbauer wieder extra...Ich finde Pluginauthoren sollten etwas Rücksicht auf die Paketbauer nehmen.
cu
*) Ich bin mir eh noch nicht sicher wo Plugininterne Scripte denn nun wirklich am besten hinsollten. Aber das lässt sich z.B. bei uactivity ja auch rein per Kommandozeile an die Wünsche der jeweiligen Distribuion anpassen (finde ich um einiges besser als die üblichen Patches die das im Quellcodes ändern).
-
Zitat
Ich finde Pluginauthoren sollten etwas Rücksicht auf die Paketbauer nehmen.
Warum?
-
Warum?
Höflichkeit.
Ein wenig Präprozessormagie kostet doch nix. Ich weiß garnicht warum sich hier alle immer so dagegen streuben. Ist das zu uncool?
cu
-
Höflichkeit ist genau anders herum.
Der Autor eines Plugins codet, weil er selbst eine Funktionalität benötigt. Wenn er die Nutzung dieses Plugins anderen (ohne Gegenleistung) ermöglicht, dann ist das eine Sache, bei denen Nachnutzer keinen Anspruch auf irgendetwas haben.
-
Der Autor eines Plugins codet, weil er selbst eine Funktionalität benötigt. Wenn er die Nutzung dieses Plugins anderen (ohne Gegenleistung) ermöglicht, dann ist das eine Sache, bei denen Nachnutzer keinen Anspruch auf irgendetwas haben.
Dann kann man es sich aber auch gleich sparen es zu veröffentlichen Abgesehen davon bedeutet Höflichkeit des Entwicklers nicht das irgend jemand einen Anspruch daraus ableiten will.
Das Extrembeispiel ist yacoto: Ein tolles Plugin (was eigentlich jeder nutzen wollen würde) aber niemand nutzt es weil die Installation ein graus ist (überall feste Pfade im Code).
cu
-
Warum? Nicht alle nutzen Pakete.
-
Warum? Nicht alle nutzen Pakete.
Deswegen spreche ich ja von "Höflichkeit" und nicht von "Verpflichtung" oder "Notwendigkeit".
Ich sage ja auch nicht das alle Pluginauthoren jetzt zwingend bis zum Sonntag ihren Code auf Höflichkeit prüfen müssen und bis Montag einen Patch bereitstellen müssen. Ich sage nur das ich es toll fände wenn Pluginauthoren aus Höflichkeit solche Dinge berücksichtigen.
Niemand ist gezwungen irgendwas zu machen. Und niemand bringt mich von meiner Meinung ab das ich es toll fände wenn alle so höflich wären
BTW: Es geht auch nicht darum das ich möchte das für jeden Mist irgendwelche Parameter vorhanden sein sollen, es geht nur um Dinge wo es Sinn macht.
Beispiel das restfulapi Plugin: Dort ist der Pfad zum Videoverzeichnis als String im Quellcode. Es wäre höflich gewesen ihn in der Make.config konfigurierbar zu machen. Nun ist das aber auch kein Vorwurf an den Author, ich denke er hat das Problem einfach übersehen. Ist ja auch nicht schlimm.Nur wenn du da jetzt sagst das man das (d.h. so was in der Art) nicht konfigurierbar machen SOLL weil ja die Nutzer froh sein können wenn die Entwickler überhaupt was veröffentlichen finde ich es etwas unhöflich.
cu
-
Beispiel das restfulapi Plugin: Dort ist der Pfad zum Videoverzeichnis als String im Quellcode. Es wäre höflich gewesen ihn in der Make.config konfigurierbar zu machen.
Wieso steht der Pfad zum Videoverzeichnis denn überhaupt im Quellcode drin? Der ist doch eh bei jedem anders. Warum wird da nicht die globale Variable VideoDirectory benutzt?
Nur mal so interessehalber...Klaus
-
Wieso steht der Pfad zum Videoverzeichnis denn überhaupt im Quellcode drin? Der ist doch eh bei jedem anders. Warum wird da nicht die globale Variable VideoDirectory benutzt?
Nur mal so interessehalber...Evtl. wusste der Author nicht das diese globale Variable existiert?
Mich überrascht es jetzt auch das man an diese Information kommt. Aber danke für den Hinweis. Ich werde dann nochmal in den Quellcode schauen und die Info dann in den restfulapi Bugtracker posten.
Es ist übrigens nicht so ungewöhnlich das Plugins solche Sachen machen (z.B. anstelle von ConfigDirectory() den Pfad den die eigene Distribution nutzt als String reinschreiben), es dauert halt immer einwenig rauszufinden ob es da besssere vdr native Möglichkeiten gibt (gut ConfigDirectory() ist gut dokumentiert, aber bei anderen Sachen muss man halt die VDR Header durchstöbern). Da kommt es doch schonmal vor das Dinge im Eifer des Gefechts erstmal schnell gelöst werden (Pfad direkt reinschreiben) und es dann später vergessen wird.
cu
-
Moin!
Vom restfulapi-Autor hab ich zwar schon länger nichts gehört, aber ich werde Patches sonst in das yavdr-git einpflegen. Von da aus kann er sich das dann auch holen.
Zur Not also einfach PN an mich mit den Links zu den neuen Bugreports schicken.Lars.
-
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
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!