Local-Files-Customization

[dbt]

Edit: Ok das Urthema hat sich erledigt, aber barf hats schon mal angedeutet, so etwas wie eine "Local-Files-Customization" einzubauen, also quasi ein vorgefertigtes Verzeichnis in dem alle zusätlich benötigten Files abgelegt sind und automatisch geholt und dorthin kopiert werden wo sie im Image sein sollen.

[Barf]

Die aller eleganteste Lösung des "Beispiels" wäre das library-reduction Schitt so zu erweitern, dass noch eine Verzeichniss, entweder durch configure-Option konfigurierbar, oder sogar festgelötet als z.B. $(flashprefix)/library-reduction-aux, bei library reduction durchgesucht wird.

Sonst fällt es mich ein, dass (in reduce-libs.mk) es keine customization-aufruf gibt.
Wäre sicherlich naheliegend, dies einzuführen.

Gegen den eigentlichen Vorschlag bin ich eigenlich (ausnahmsweise!! ) leidenschaftslos; sollte kaum was kaputtmachen, aber wahrscheinlich nur in ganz besondere Situationen nützlig.

[dbt]

Und nochmal

[rhabarber1848]

root-neutrino.squashfs-local.sh kommt aber zu spät.

Was ist mit root-neutrino-squashfs-local.sh?
Wenn ich das richtig sehe, wird es nach mklibs, aber vor mksquashfs aufgerufen.

Der Aufruf dieser Datei findet sich in cdk/make/flashable-dirs.mk, Zeile 84

[dbt]

Was ist mit root-neutrino-squashfs-local.sh?

Man oh Mann. Das wars, also manchmal, danke, vergessen wir das Ganze.

[Tommy]

Barf's Idee für ein "special folder" wo man die Sachen einfach reinpackt fand ich aber auch nicht doof. (alles was in diesem folder liegt wird berücksichtigt). Das macht natürlich der dunklen Seite das Leben auch wieder leichter - aber wie war das mit dem Messer mit dem man Brot schneiden und töten kann.

[dbt]

Die Idee kling gut, deswegen habe ich das Thema mal abgeändert.

[rhabarber1848]

Ich verstehe nicht ganz, worum es hier gehen soll.
Könntet ihr bitte einen konkreten Anwendungsfall beschreiben?

[Barf]

Erstmals finde ich es ein absolutes Unding, frühere Postings so zu editieren, dass die urspüngliche Meinung verlohrengeht. Ein zugekommener Leser hat keine Möglichkeit, nachfolgende Beiträge in dem urspüngliche Zusammenhang zu verstehen, und versteht nur Bahnhof. Insbesonderes gilt dies natürlich für den Anfangspost eines Threads.

Einzige Ausnahme sollte Beleidungen etc sein, sowie versehliches Verplappern von geheimer Informationen usw.

... barf hats schon mal angedeutet, so etwas wie eine "Local-Files-Customization" einzubauen, also quasi ein vorgefertigtes Verzeichnis in dem alle zusätlich benötigten Files abgelegt sind und automatisch geholt und dorthin kopiert werden wo sie im Image sein sollen.

Que? Ich habe keine Ahnung, was dies bedeuten soll. Weil am mindestens Tommy mein Posting verstanden hat, habe ich mich nicht völlig unverständlich ausgedrückt (ein mögliche Modifikation zum library-reduction).

PS. "PLONK" bedeutet "Please Leave Our Newgroup Kid".

[dbt]

Erstmals finde ich es ein absolutes Unding, frühere Postings so zu editieren

Ja, ist wahr, allerdings war das auch relativ unnütz was ich angebracht hatte und sollte dann auch keine Rolle mehr spielen. Die Erklärung wäre schon noch gekommen. Vermutlich haben wir auch irgendwie aneinander vorbeigeredet oder ich habe dich falsch verstanden.
Was das plonk angeht, war das nur so gemeint wie's geschrieben steht genauer gesagt wie sich das anhört, mehr comicmäßig, im Sinne von an die Wand rennen, deshalb auch der ., über die "versteckte" Bedeutung hatte ich nicht im geringsten dabei gedacht ... und ich hasse diese schäußlichen Abkürzungen, am schlimmsten finde sowas wie ACK, zweideutiger gehts nicht, zumindest im Deutschen ist das etwas was die Meißten nicht mal in die Hand nehmen wollen... soviel dazu. Damit sich keiner drüber aufregt, hab ich das PL weggemacht.

[Tommy]

Habt Euch bitte lieb Allerdings war ich vom "jetzigen" Eingangspost auch überascht da ich Ihn anders in erinnerung hatte - habs aber auf den Pegel nach dem gestrigen Stammtisch geschoben

Ich bin kein Profibauer aber ich habe Barf so verstanden, das er vorschlägt ein "specialFolder" zu etablieren in welches vor/ wärend des bauens binaries verfrachtet werden die beim strippen berücksichtigt werden sollen _aber_ nicht im Flash landen sollen. Als da wären (ich weis nicht ob das folgende Quatsch ist) Samba, link (Browser), div Plugins, scumm, etc.

[rhabarber1848]

die beim strippen berücksichtigt werden sollen _aber_ nicht im Flash landen sollen.

So hatte ich das auch verstanden, nur löst root-neutrino-squashfs-local.sh das Problem.
Anders sähe es aus, wenn diese Binaries nicht vom CDK kompiliert werden, was ich
allerdings für wenig sinnvoll halte, da mit dem CDK alles kompiliert werden kann.

[Tommy]

Du meinst betreffende Binaries in root-neutrino-squashfs-local.sh aus dem cdkflash zu entfernen?

BTW: herzlichen Glückwunsch zum CVS Account lass die Drähte glühen

[rhabarber1848]

Du meinst betreffende Binaries in root-neutrino-squashfs-local.sh aus dem cdkflash zu entfernen

Ja, das Skript wird nach mklibs.py aufgerufen, d.h. die libs haben alle benötigen
Symbole. Das Skript wird aber vor mksquashfs aufgerufen, sodass diese Binaries
nicht im Image landen sondern extern verteilt werden können.

[Tommy]

Ein weiterer vorteil wäre akllerdings Einsparung von Bauzeit, da man Sachen wie Samba (o.ä. was in der Entwicklung eher stagniert) nicht jedesmal neu kompilieren müßte. Ob das natürlich ein "Killerkriterium" wäre kann ich nicht einschätzen. Da habt Ihr mehr Ahnung.

[dbt]

Enschuldigt bitte dass ich das Thema etwas durchgeschüttelt habe, kommt nicht mehr vor!

Ich bin kein Profibauer aber ich habe Barf so verstanden, das er vorschlägt ein "specialFolder" zu etablieren in welches vor/ wärend des bauens binaries verfrachtet werden die beim strippen berücksichtigt werden sollen _aber_ nicht im Flash landen sollen. Als da wären (ich weis nicht ob das folgende Quatsch ist) Samba, link (Browser), div Plugins, scumm, etc.

So in etwa war das gemeint, und ja es ging in dem Fall um einige Binaries wie etwa Samba3, fürs jtg. Weil der eben so groß ist und nur zum nachinstallieren gedacht war, sollte das ganze halt noch von mklibs erwischt werden und dann wieder enfernt werden können. rhabarber1848 hat mich dann zurecht geruckt, weil das von root-neutrino-squashfs-local.sh erledigt werden kann. Das hatte ich übersehen und das Thema für unnötig befunden. Deshalb wohl das Durcheinander, nochmal sorry.

Ein weiterer vorteil wäre akllerdings Einsparung von Bauzeit, da man Sachen wie Samba (o.ä. was in der Entwicklung eher stagniert) nicht jedesmal neu kompilieren müßte. Ob das natürlich ein "Killerkriterium" wäre kann ich nicht einschätzen. Da habt Ihr mehr Ahnung.

In momentanen Zustand wird sicher nichts eingespart, da eigentlich immer alles gebaut wird bevor Customization zuschlägt. Da würde der erste Thematitel besser passen: "Pre-Customization".
Worauf ich jetzt hinaus will, ist dass man einen extra Ordner hat, zB. .../local_files in dem einige Files drin sind, die dann im Image liegen sollen. Die Ordnerstruktur müsste der üblichen Rootstruktur entsprechen, so dass man einfach nur kopieren muß. Die werden momentan mit Customization-Scripts kopiert. Das würde dann entfallen. An passender Stelle, zwischen mklibs und mksquashfs würde sich das anbieten. Geschwindigkeitsvorteile hat das in dem Moment nicht. Da müsste man schon was machen, dass in den Targets eine Prüfung gemacht wird, ob solch ein fertiges local-file vorliegt oder nicht und dann entweder baut oder nicht. Dasird wohl auch nicht überall funktioneren. Wie das gehen soll, habe ich mir aber bisher nicht überlegt, und ob das so sinnvoll ist, sei auch erst mal dahingestellt. Ist halt nur eine Idee.

[seife]

Ein weiterer vorteil wäre akllerdings Einsparung von Bauzeit, da man Sachen wie Samba (o.ä. was in der Entwicklung eher stagniert) nicht jedesmal neu kompilieren müßte. Ob das natürlich ein "Killerkriterium" wäre kann ich nicht einschätzen. Da habt Ihr mehr Ahnung.

Man baut ja sowieso praktisch nie alles neu, insofern ist das egal. (Also ich baue nur komplett neu, wenn ich den Verdacht habe, dass eine meiner Änderungen das Buildsystem kaputt machen könnte, oder wenn ich's irgendwie so vergeigt habe, dass es schneller ist, die paar Minuten zu warten, bis es komplett, dann inklusive Toolchain, durchgebaut hat).

[rhabarber1848]

Man baut ja sowieso praktisch nie alles neu

So allgemein möchte ich das nicht stehen lassen, ich baue immer alles neu,
das dauert zwar länger, dafür muss ich mich aber nicht mit Überresten
früherer Kompilierdurchläufe herumschlagen. Dazu lösche ich das bisherige
Kompilierverzeichnis, kopiere meine lokale CVS-Kopie dorthin, patche das
Ganze und dann geht configure/make los.

Worauf ich jetzt hinaus will, ist dass man einen extra Ordner hat, zB. .../local_files in dem einige Files drin sind, die dann im Image liegen sollen.

Ein cp-Einzeiler in root-neutrino-squashfs-local.sh sollte dafür genügen, oder?

[dbt]

Ein cp-Einzeiler in root-neutrino-squashfs-local.sh sollte dafür genügen, oder?

Im einfachsten Fall ja.