Makefile.am

[michad2507]

Moin,

wenn ich mich recht erinnere ist tuxmaild doch ein plugin, oder? Gehört das dann in die Flashrules rein?
Ebenso sind rcsim und saa nicht zwingend nötig für ein Image, bzw. für den Standard User recht uninteressant

mfg

[Nico 77]

Weiß zwar nicht was rcsim ist, aber saa ist auf alle Fälle wichtig um bei bestimmten Fernsehern die richtigen TV-Modi wählen und vor allem darstellen zu können.

Habe mir nämlich vor nicht allzu langer Zeit nen Wolf gesucht warum ich nicht diverse TV Modi wählen konnte.

Ps: Saa im Makefile wäre sehr sinnvoll oder ist es mittlerweile drin?

[dcdead]

rcsim = Remote Control Simulator

Sehr nützlich aber wie oben geschrieben wurde, nicht standardmäßig nötig

[HEAD]

Anstatt saa-funktin in ein plugin zu schreiben , packt man saa und plugin der saa braucht in Image.
Und wieso in Image stremps,stremsec,stremts und udpstreampes nicht gestript sein dürfen ist mir auch ein rätsel.

[Sat_Man]

Und wieso in Image stremps,stremsec,stremts und udpstreampes nicht gestript sein dürfen ist mir auch ein rätsel.

Weil das überflüssig ist, bei make flash-neutrino-all bzw. make flash-enigma-all wird am Ende immer make flash-lib aufgerufen und somit wird alles in /bin und /sbin gestript.

Wozu also vorher stripen?

[JtG-Riker]

Und Tuxmail ist mittlerweile verschoben nach Plugins.

[HEAD]

Und wieso in Image stremps,stremsec,stremts und udpstreampes nicht gestript sein dürfen ist mir auch ein rätsel.

Weil das überflüssig ist, bei make flash-neutrino-all bzw. make flash-enigma-all wird am Ende immer make flash-lib aufgerufen und somit wird alles in /bin und /sbin gestript.

Wozu also vorher stripen?

Ist mir was ganz neues , dass /sbin gestript wird .
Dann zeigt deine grösse ... von Files in cdkflash/root/sbin

[Sat_Man]

Ja hast Recht, das fehlt wirklich bei make flash-lib, aber es wäre dann wohl sinnvoller alles was in /sbin ist bei make flash-lib auch noch stripen zu lassen oder nicht?

[HEAD]

es gab zeit , dass "in.ftpd" stripen ungesund war , habe bis Heute nicht noch mal versucht.
Sonst hast recht , aber wieso nix stripen , das war die Frege

[michad2507]

wieso wird top nicht in der busybox aktiviert sondern reinkopiert? Knapp 300k Platzverlust der nicht sein muss ?

[JtG-Riker]

Gestrippt ist es 70kb und wird noch geändert...

Kannst es doch lokal bei dir entfernen aus dem makefile.

[michad2507]

Gestrippt ist es 70kb und wird noch geändert...

Kannst es doch lokal bei dir entfernen aus dem makefile.

klar, hab ich ja auch gemacht, aber es ist halt unnütz das es extra drin is, die busybox kann das auch und es braucht da viel weniger Platz

[JtG-Riker]

jo, das liegt dadran das JtG mit dem busybox top nicht klarkommt und ich hab beim diff vergessen auszubauen... wird aber noch geändert, aber gibt sicher wichtigere sachen

[michad2507]

jo, das liegt dadran das JtG mit dem busybox top nicht klarkommt und ich hab beim diff vergessen auszubauen... wird aber noch geändert, aber gibt sicher wichtigere sachen

was denn? rcsim? saa? tuxmaild?

sorry, aber das sieht mir schon so aus als wärs speziell auf ein Image zugeschnitten

[JtG-Riker]

les mal weiter oben da steht das

tuxmaild ist der Daemon für das Plugin, das wurde vergessen.

[michad2507]

ich weiss dchon was tuxmaild ist Dann streich das von mir aus aus meiner Frage oben, bleiben aber immer noch ein paar Sachen (incl. top)

[JtG-Riker]

Les doch mal weiter oben da steht was SAA und RCSIM ist, grr Brille putzen

[michad2507]

Ich hab keine Brille
Ich weiss auch was SAA und rcsim ist, rcsim zumindest für den Standard User uninteressant, und nur weil JTG mit dem TOP der busybox nicht klar kommt wird das makefile geändert, also wenn das nicht ein zuschneiden auf das Image ist dann weiss ich es auch nicht, vllt. sollte JTG mal sein Image fixen, n8

[Npq]

Jo stimmt.

Das Makefile.am sollte schon Image-unabhängig bleiben. Also alles was nicht wirklich benötigt wird baut sich jeder lokal ein.

Momentan ist ja wieder alles draußen was nicht direkt reingehörte.

[Nico 77]

Na toll, dann nehmen wir am besten den Movieplayer, Bildbetrachter, MP3player und die Spiele raus.
Diese braucht man ja auch nicht zum Fernsehen. *lol*

Also wenn 'touch .deps/RykerImage' wieder rausgenommen wird kann ich ja noch verstehen, aber der Rest war meiner Meinung nach wirklich sinnvoll.

[HEAD]

cvs ist für alle da nicht nur für ryker image.
Ich hab zB immer dvbsnoop in image muss das jetzt auch in flash ?

[Npq]

Hat nicht mal einer eine vernünftige Idee wie man das auf einfache Weise im Makefile handlen kann?

Ich kann ja verstehen, wenn jemand nicht unnötig in den Tiefen des Makefile.am rumwurschteln will, aber so Unsinn wie "$(depdir)/xy_image" bringt da auch nichts.

Man müßte eine überschaubare Datei haben wo drinsteht, was zusätzlich ins Image übernommen werden soll oder so. Etwas was schnell angepaßt werden kann.

Dann könnte man da auch "eigene" Programme reinschreiben ohne gleich Angst zu haben, daß das nächste "up" evtl. einen conflict beim Merge gibt.

Wäre jedenfalls besser als daß jetzt ständig die Entwickler sich gegenseitig zucommitten, nur weil sie ihre Zusammenstellung für die "einzig Wahre[TM]" halten.

[rasc]

cvs ist für alle da nicht nur für ryker image.
Ich hab zB immer dvbsnoop in image muss das jetzt auch in flash ?

bei mir logischerweise schon... (dvbsnoop)


Zu den Images und dem Makefile:
Solange es nicht EIN offizielles Image fuer das dbox2-Projekt geben wird, hat IMO ein Image-Make fuer ein bestimmtes Image nichts im cdk verloren. Schongar nicht, wenn das dann noch ein separaten Boards oder Sites supportet wird (das soll keinerlei Wertung darstellen).

Als Lösung bieten sich eigene Makefiles an, die die benoetigten Sachen aus dem cdkroot rauskopieren, etc.. Dann koennte man auch einen eigenen Pfad im cvs haben (z.B. ./images/jtg, /images/yadi, ...)

Aber das duerfte sich schwierig gestalten, da "yadi" ja schon einen anderen Weg gewählt hat (eigenes cvs)...

[essu]

Jemandem, der Images erstellt, sollte man zutrauen, eigene Patches einzubringen, die massgeschneidert für das Image sind. Wenn sie sinvoll sind, werden sie ihren Weg ins tuxbox-cvs finden (siehe U-Boot, squashfs etc.)

Kurz: Warum sollte man den Bock zum Gärtner machen?

@rasc:

Aber das duerfte sich schwierig gestalten, da "yadi" ja schon einen anderen Weg gewählt hat (eigenes cvs)...

Eigentlich ist das genau der Ansatz: Für unser Image brauchen wir Patches etc., aber wir machen diese öffentlich und nachvollziehbar, wir hätten auch nichts dagegen unsere diffs usw. ins tuxbox-cvs einzustellen, aber ich persönlich halte ein eigenes kleines CVS für überschaubarer und leichter zu pflegen (ist schon schwer genug...), da wir aber unser CVS auch als tarball veröffentlichen, könnte ich mir vorstellen, diesen tarball, vllt wöchentlich aktualisiert, ins tux-cvs zu integrieren, ähnlich könnten ja andere Image-Macher auch verfahren.

Obsolet finde ich aber, dass jemand seine eigenen sources nicht offenlegt und zugleich Änderungen im tuxbox-cvs vornimmt, da ist dann nichts mehr nachvollziehbar und Nachvollziehbarkeit ist IMO das Hauptanliegen des CVS

--- noch eine Ergänzung: ---

Das makefile zu einem Ort der Auseinandersetzung zu machen finde ich falsch, wozu gibts denn das Forum? Ich erwarte von jedem, der dort etwas ändert genügend Augenmass um das grosse Ganze im Blick zu haben und nicht Interessen der einen oder anderen Art voranzutreiben. Und das sollte für ALLE gelten...

[HEAD]

Hat nicht mal einer eine vernünftige Idee wie man das auf einfache Weise im Makefile handlen kann?

Wie wäre es zB mit :
in Makefile.am
$(flashprefix)/.part_neutrino: $(flashprefix)/.flash neutrino root
bla ...
include $(top_srcdir)/Makefile.am.extra.neutrino.flash
@touch $@

und in Makefile.am.extra.neutrino.flash zB

$(INSTALL) $(targetprefix)/bin/camd2 $(flashprefix)/root/bin

Das Makefile.am.extra.bla muss nicht mal ge'touch' werden , wenn extra da ist wird mitgenommen.