Flashtargets in Makefile umgeschrieben

[JtG-Riker]

Habe mir auch mal die neuen rules angeschaut, Respekt für die Arbeit.

Mir ist auch folgendes aufgefallen:

- bei Squashfs wird auch ein cramfs Ordner erstellt.

- komischerweise wird der Kernel da nochmal gebaut ziemlich am Ende vom Build - wieso dies ?


Wie kann man denn z.B. wenn man eine Bad Magic hat das flash rebuilden wie früher?

Ich finde auch das die mk??fs - Tolls ins cvs sollten, könnte man doch einfach inst Hostapps mit reinwerfen.

Riker

[Barf]

- bei Squashfs wird auch ein cramfs Ordner erstellt.

http://forum.tuxbox.org/forum/viewtopic ... c&start=97

Wie kann man denn z.B. wenn man eine Bad Magic hat das flash rebuilden wie früher?

Ehrlich: ich weiss nicht was mann systematisch gegen bad magic tuhen soll.

Ich finde auch das die mk??fs - Tolls ins cvs sollten, könnte man doch einfach inst Hostapps mit reinwerfen.

Riker

http://forum.tuxbox.org/forum/viewtopic.php?t=40392

[Barf]

Eine der Intentionen ist ein "one-for-all" sprich Images und Yadds, darauf beziehen sich meine Tests.
Meiner Meinung nach sollte "cdkroot" und das dazugehörige "tftpboot" nicht gestrippt werden.
Falls man doch einmal den Debugger braucht muss man alles wieder neu bauen.
Stattdessen sollten bei aktivierten Flashtargets die Yadds ebenfalls in ein eigenes Verzeichnis
kopiert werden und dan gestrippt.

Hier ist sicherlich nicht das letzte Wort gesagt. Ich habe niemals behauptet, dass mann es nicht weiter verbessern kann. EIn problem ist dass "flashoptimiertes kompilieren" passiert mit -Os, es ist nicht das Selbe als "yaddoptimiert kompilieren" mit -O2 -g -girgedwas .... und danach strippen. Irre ich mich lasse ich mich gerne berichtigen.

Warum baust du zuerst u-boot und anschließend im Target kernel-cdk nocheinmal?

Machen ich nicht??

Die Logos bei Yadd werden nicht kopiert.

Ist bewusst. Gibt wenig bedarf, wer weiss was ein yadd-developer will?

Zum Thema "Single Source". So schön wie es aus Programmsicht ist - ein diff *config.yadd *.config.flash sagt mir
schneller etwas und ist leichter zu pfegen als ein *.m4. Bisher hat jeder die Files geändert die er auch testen kann.

Die Frage, den Unterschied darzustellen ist eine Andere als die Datei(en) zu unterhalten, und hat nicht notwendigerweise die gleiche Antwort. Mann kann z.B

busybox.config.diff: busybox.config-yadd busybox.config-flash
diff -u $^

in Makefile schreiben.

Es ist duchaus möglich für ein Entwickler z.B. zwei Files konsistent zu halten. IN tuxbox-CVS geht es nicht, hat die Vergangenheit gezeigt. Alle die Entwickler, die sich nur für ein Fall intressieren, denke mal an den Dreamboxlern!!

Wenn es dabei zu Inkonsitenzen kommt liegt es wohl eher daran, dass Yadd/Image- Ersteller es nur in eigene Scripts
einfügen und nicht ins CVS. ;-)

Und wie willst du es verhindern?

Unwichtiges: Eigentlich interessiert nur die Build-Time nicht die Maintenance-Time. Wann etwas zusammenkopiert wird
ist doch egal. ( cp -a vs. cp -rp ) .

Das "Builden einer Image" ist ein Build, nicht eine Archivierung. Deswegen ist cp ohne -p das Richtige (auch wenn man manchmal in CDK anderes findet.)

Ein weiterer Vorschlag (allgemein), es sollten Tools wie mk*fs im CVS sein. So hat jeder immer die richtige Version.
mkcramfs ist z.B. schon im Kernelsource enthalten.

http://forum.tuxbox.org/forum/viewtopic.php?t=40392

Abschiessend: Ich schätze dein Beitrag. Letzte Ziet war es zu viel "wie mache ich", "bugs/kein bugs", und viel zu wenig Grundsatzdiskussion.

[yjogol]

Hi,
durch die neuen Make-Rules wird das Image-bauen transparenter und die Zeit zum Erlernen des Image-bauens kann auch für Neulinge erträglich werden.
Ich habe eine kleine Text-GUI (Shellskripts) geschrieben, um den Einstieg zu vereinfachen.
Vielleicht habt ihr ja Lust, die Skripts zu erweitern.
http://www.yjogol.de/yDownloads.htm unter "Build & Compiling Helper"
Sieht zur Zeit so aus:

Code: Alles auswählen

==============================================================
Tuxbox - Build & Compiling Helper (V0.1.2 / 04.02.2006)
--------------------------------------------------------------
0 - Basis Configuration
1 - First Checkout & autoconfig
2 - Autoconfig (configure) only
3 - Checkout update
4 - Build Flash : ALL
5 - Build Flash : Will ask you
6 - Build Flash (selected)
a - Toolchecker
l - View Build Logfile

d - Debug on=1/off=0 : 0
x - Quit
==============================================================

Code: Alles auswählen

==============================================================
Menu: Basis Configuration
--------------------------------------------------------------
0 - Working Directory.........: /home/y/tuxbox
1 - Private: Logos Directory..: Private/Logos
2 - Private: Ucodes Directory.: Private/Ucodes
3 - Private: MyFiles Directory: Private/files
4 - DBOX Directory............: dbox2
5 - CVS Directory.............: tuxbox-cvs
6 - CVS Username..............: anoncvs

b - Back
==============================================================

Gruß
yjogol

[Barf]

Ich habe die Regeln für $(targetprefix)/.version und $(flashprefix)/root/.version geändert, und zwar so dass falls der Benutzer customization files angelegt hat (version-local.sh bzw flash-version-local.sh) werden sie ausgeführt STATT die default regeln. In diesem Sinn hat die Custiomization andere Semanik hier als bei den anderen Regeln. Die Motivation ist dass der Benutzer der Custonmizen will kaum die Defaultregeln.

Hier ist ein Beispielconfiguration; kann sowohl als version-local.sh als auch flash-version-local.sh dienen:

Code: Alles auswählen

#/bin/sh

if [ $0 = flash-version-local.sh ] ; then
    outfile=$1/root/.version
    type="image"
else
    outfile=$1/.version
    type="yadd"
fi

echo Creating $outfile ...

echo "version=`./mkversion -snapshot -version 200`"	 > $outfile
echo "creator=Barf"					>> $outfile
echo "imagename=Barf-$type"				>> $outfile 
echo "homepage=http://www.bengt-martensson.de"		>> $outfile

Dabei wird ein Hilfsskript mkversion aufgerufen, mit folgenden Inhalt:

Code: Alles auswählen

#!/bin/sh

releasetype=3
versionnumber=000
year=`date +%Y`
month=`date +%m`
day=`date +%d`
hour=`date +%H`
minute=`date +%M`

while expr $# > 0 ; do
	case "$1" in
	-release) 
		releasetype=0
        ;;	
	-snapshot) 
		releasetype=1
        ;;	
	-internal) 
		releasetype=2
        ;;
	-version)
		versionnumber=$2
		shift
	;;	
	esac
	shift
done

echo $releasetype$versionnumber$year$month$day$hour$minute

(Ja, wirklich nicht ein Meisterwerk in shell-Programmierung, dient haubptsächlich um den etwas kryptischen versionsstring zu entschlüsseln

[Übrigens, mit "update" in .version kann man eine ganz "schöne" Endlosschleife in update.cpp erzeugen )

[Barf]

Ich habe einige Änderungen eingecheckt. Erstmals machen Target wie flash-automount ein touch auf $(flashprefix)/root; dabei weiss make dass Targets, die davon anhängen nicht mehr up-to-date sind. Zweitens habe ich die $(flashprefix)/root-[cramfs,squashfs,jffs2] targets geändert, so dass sie nicht mehr den Inhalt von $(flashprefix)/root enthält, und dadurch nicht davon abhängt. Dadurch entfällt unnötiges kernel-bauen. Ferner können diese Targets paralell gemake-d werden.

Beispiel:

make flash-neutrino-jffs2-all
<Sachen werden gebaut>
make flash-neutrino-jffs2-all
<nix passiert, weil up-to-date>
make flash-automount
<Automount wird in $(flashprefix)/root installiert, was jetzt neuer als *.imgXx is)
make flash-neutrino-jffs2-all
<root-neutrino-jffs2[-p] wird neu gebaut, sowie *.jffs2 und *.imgXx; aber nicht kernel, busybox, u-boot>

Idealerweise, bei "make target" soll make genau das neu bauen was erforderlich ist, nicht mehr nicht weniger. Ich glaube diese Änderungen geht ein Schritt in diese Richtung.

[yjogol]

@barf
Jetzt hab ich doch noch eine Frage.
Ist es nicht sinnvoll, root-neutrino-jffs2-p-local.sh vor dem Stripping aufzurufen?
Dann kann man eigene Programme und Libraries nach bin und lib kopieren, welche beim stripping mit berücksichtigt werden.

Ich hatte die PREPARE Ordner genau so verstanden. Oder haben die nur eine besondere Bedeutung für Filesystem != JFFS2? zum Zusammenbauen von Root und Var?

Gruß
yjogol

[Barf]

Ich habe gerade was Ähnliches für Neutrino und Enigma gemacht, wie früher für die Kernels. Neutrino wird jetzt in $(flashprefix)/root-neutrino installiert, danach, beim builden von $(flashprefix)/root-neutrino-$filesystem-p rüberkopiert. Ähnliges für Enigma. Sollte die Effizienz etwas verbessern.

Ist es nicht sinnvoll, root-neutrino-jffs2-p-local.sh vor dem Stripping aufzurufen?
Dann kann man eigene Programme und Libraries nach bin und lib kopieren, welche beim stripping mit berücksichtigt werden.

Es ist richtig, dass Reinkopieren von Programme nach Stripping und library reduction eine schlechte Sache ist -- nicht nur wegen evtl fehlende Stripping sondern auch weil library reduction erforderlige Symbole in Libraries entfernen kann Die oben beschriebene Änderung (wobei mann root-neutrino-local.sh aufrufen kann, um mit dem neuen Neutrinoinstallation zu fummeln) deckt, glaube ich (zusammen mit root-local.sh und root-$filesystem-local.sh) den Bedarf? Bitte kucke die neue Version an. In allgemein glaube ich dass man soll versuchen Syntax und Semantik bei den Custiomizations gleich zu halten -- auch wenn die .[flash-]version-local.sh dagegen verstoßen.

Ich habe eine kleine Text-GUI (Shellskripts) geschrieben, um den Einstieg zu vereinfachen.

Intressant. Leider zeigt die Erfahrung, dass sowohl Experten als auch Warmduscher interaktive Shellskripts ablehen Kucke dir die Linux.Kernelkonfiguration an -- vielleicht ist die TK/TCL-konfiguration eine Inspirationquelle (es war ein Paar Jahre seit dem ich es letzte mal benutzte)

Was ich gerne sehen möchte ist eine "Pizzabestellingsform" wo mann komponente wie z.B. automounter, ssh, an- oder abwählen konnte, vgl grafisch Linuxkernelkonfiguration.

[racker]

Quote:

Warum baust du zuerst u-boot und anschließend im Target kernel-cdk nocheinmal?

Machen ich nicht??

Vlt. bekommen wir den Knoten gelöst.
Beim Aufruf von: make bare-os

Code: Alles auswählen

bare-os: $(bootprefix)/u-boot $(bootprefix)/kernel-cdk driver $(targetprefix)/etc/init.d/rcS $(targetprefix)/bin/busybox modutils $(targetprefix)/bin/tuxinfo

wird u-boot 2x gebaut. Einmal als $(bootprefix)/u-boot und unter kernel-cdk als $(hostprefix)/bin/mkimage (gleiche targets, nicht dieselben )
Vlt. kann man $(bootprefix)/u-boot aus bare-os: entfernen?

Quote:
Zum Thema "Single Source". So schön wie es aus Programmsicht ist - ein diff *config.yadd *.config.flash sagt mir
schneller etwas und ist leichter zu pfegen als ein *.m4. Bisher hat jeder die Files geändert die er auch testen kann.
Die Frage, den Unterschied darzustellen ist eine Andere als die Datei(en) zu unterhalten, und hat nicht notwendigerweise die gleiche Antwort. Mann kann z.B

busybox.config.diff: busybox.config-yadd busybox.config-flash
diff -u $^

in Makefile schreiben.

Es ist duchaus möglich für ein Entwickler z.B. zwei Files konsistent zu halten. IN tuxbox-CVS geht es nicht, hat die Vergangenheit gezeigt. Alle die Entwickler, die sich nur für ein Fall intressieren, denke mal an den Dreamboxlern!!

Setzt das nicht vorraus, dass das komplette config-File mit allen Optionen vorliegen muss?
Egal, man kann nicht erwarten, dass man in einem Freizeitprojekt alle Fälle durchtestet,
man ist da auf das Feedback der Community angewiesen - liegt auch in ihrem Interesse.
Spätestens beim kernel-config hört dann der Spass auf...
"Die Dreamboxler" sind ein schlechtes Beispiel- gehört aber nicht hierher.

Quote:
Wenn es dabei zu Inkonsitenzen kommt liegt es wohl eher daran, dass Yadd/Image- Ersteller es nur in eigene Scripts
einfügen und nicht ins CVS.


Und wie willst du es verhindern?

Gar nicht - s.o.

Das "Builden einer Image" ist ein Build, nicht eine Archivierung. Deswegen ist cp ohne -p das Richtige (auch wenn man manchmal in CDK anderes findet.)

Richtig, das Imageerstellen ist ein Build, der Inhalt hat sich aber nicht geändert.
Egal, es ist nichts was an touch nicht wieder hinkriegen könnte.

So und jetzt noch etwas Neues, ist mir schon im HEAD Makfile aufgefallen.
Die Headerdateien für glibc und gcc werden von $(bootprefix)/linux/ "geholt".
Wäre da nicht "$(bootprefix)/linux-KERNELVERSION " richtig?
Ich habe mal gelernt (ist schon lange her), dass Apps immer gegen die Header
der glibc (mit der sie gebaut wurde) kompiliert werden. Nur Treiber benötigen
die Header des aktuellen Kernels. Oder bringe ich da etwas durcheinaner?

[Barf]

Einige Sachen noch: Ich habe versucht Internetupdate zu integrieren. Setzt mann z.B. --with-updatehttpprefix=http://... beim configure wird passende /etc/cramfs.urls (der Name ist jetzt irreführend, ist trozdem standard) und *.list erzeugt (das Letzte von z.B. make cramfs.list) und sind update lists in die Neutrino (evt auch Enigma?) verstehen. Sofar so good. Leider ist update.cpp in Neutrino qualifiziert braindamaged; möglicherweise kann es mit z.B. root-neutrino.cramfs umgehen, aber damit schuß. Solange update.cpp nicht gefixt ist, nützt es also uns nicht allerzu viel. Weil das Erzeugen von cramfs.urls und *.list gut läuft habe ich es trotzdem eingecheckt. Falls jemand Lust hat update.cpp zu fixen, habe ich etwas Info.

Zweitens habe ich Support für ein Initialisierungsskript implementiert. Falls die Datei /var/etc/.initialize vorhanden ist, wird /etc/init.d/initialize ausgeführt. Was diese Datei enthalten soll, kann mann diskutieren. In meine Version setze ich IP mit Hilfe von carjays lcdip (etwas erweitert).Ist nicht per Default eingeschaltet, der Imagebuilder muss, z.B. in root-local.sh touch $(flashprefix)/var/etc/.initialize machen.

Und.... damit habe ich das Programm (siehe .../cdk/doc/BUILD.changes) in alles Wesentliches durchgeführt. Einzig Wichtiges was fehlt ist die Kernel-2.6-Support, und natürlich, Dokumentation.

Es wäre natürlich toll, falls ein Kernelguru sich es anschauen könnte.

@racker: Danke für dein letzte Beitrag; Antwort kommt.

Schlußwort: Bitte bedenken, dass Branch newmake noch experimentell ist!

[Barf]

wird u-boot 2x gebaut. Einmal als $(bootprefix)/u-boot ...

ja. und dabei wird auch mkimage erzeugt.

... und unter kernel-cdk als $(hostprefix)/bin/mkimage

nein. $(bootprefix)/kernel-cdk hat zwar $(hostprefix)/bin/mkimage als prerequisite, aber wenn es schon da ist (und up-to-date) macht make es nicht nochmals.

Vlt. kann man $(bootprefix)/u-boot aus bare-os: entfernen?

wurde fehlerhaftiges Ergebniss produzieren.

Setzt das nicht vorraus, dass das komplette config-File mit allen Optionen vorliegen muss?
Egal, man kann nicht erwarten, dass man in einem Freizeitprojekt alle Fälle durchtestet,
man ist da auf das Feedback der Community angewiesen - liegt auch in ihrem Interesse.
Spätestens beim kernel-config hört dann der Spass auf...
"Die Dreamboxler" sind ein schlechtes Beispiel- gehört aber nicht hierher.

Ich weiss nicht richtig was du sagen willst: ich versuche divergierende Fileversionen vernünfig zu maintainen, und du findest es einfach sch*? Die Dreamboxler ist kein "Beispiel", für die Diskussion erfunden, sondern es ist ein FAKT dass Leute mit ganz unterschiedliche Motivation in CVS rumwerkeln, die Meiste (?) intressieren sich nur für "ein Fall". Ich werde die abstrakte Argumente in einem anderen Zusammenhang entwickeln, hier sollen wir vielleicht weniger abstrakt werden: Es gib in newmake drei m4-"single-source" files: busybox.config.m4, dbox2-flash.c.m4 und rcS.m4. Kandidaten wäre die Konfigurationsfiles für u-boot und der Kernel. Vielleicht leichter zu diese Beisplele zu relatieren?

So und jetzt noch etwas Neues, ist mir schon im HEAD Makfile aufgefallen.
Die Headerdateien für glibc und gcc werden von $(bootprefix)/linux/ "geholt".
Wäre da nicht "$(bootprefix)/linux-KERNELVERSION " richtig?
Ich habe mal gelernt (ist schon lange her), dass Apps immer gegen die Header
der glibc (mit der sie gebaut wurde) kompiliert werden. Nur Treiber benötigen
die Header des aktuellen Kernels. Oder bringe ich da etwas durcheinaner?

(...cdk/linux ist ein symlink zu ...cdk/linux-$(KERNELVERSION). Was ich gerne wissen möchte, in Bezug auf Kernel 2.6 ist die Abhängigkeiten zwischen Kernel, Compiler und glibc. Die HEAD-Makefile-Fragmente (die ich, ohne Gedanken, rüberkopiert habe) scheint unterschiedliche Kompiler zu bauen, abhängig von Kernel. Ist sowas wirklich notwendig?

[racker]

Wären die Antworten nich so spartanisch, könnte man mit den Themen schon durch sein.

wurde fehlerhaftiges Ergebniss produzieren.

Ich behaupte nicht, dass u-boot 2x kompiliert wird - es wird nur 2x der Auftrag dazu gegeben.
Warum das zu fehlerhaften Ergebnissen führen soll, werde ich wohl selbst herausfinden müssen.
Dass es beim 2. Aufruf von bare-os nochmal gebaut wurde, scheint ja jetzt behoben zu sein.

Ich weiss nicht richtig was du sagen willst: ich versuche divergierende Fileversionen vernünfig zu maintainen, und du findest es einfach sch*?
....... Es gib in newmake drei m4-"single-source" files: busybox.config.m4, dbox2-flash.c.m4 und rcS.m4. Kandidaten wäre die Konfigurationsfiles für u-boot und der Kernel. Vielleicht leichter zu diese Beisplele zu relatieren?

Es ist erstrebenswert, trotzdem sollte man das Verhältnis von Aufwand und Nutzen beachten.
Zugegeben, ich habe mich mit der m4 Erstellung noch nicht eingehend befasst.
Beispiel: kernel-config.
Man erstellt eine neue kernel-config, aktiviert dabei Optionen und Unteroption z.B mit oldconfig.
Head:
Danach wird ein Diff erstellt und man kann es zum Testen verteilen. In der Regel appliziert so ein
Diff gegen beider Versionen (kernel-config-cdk und kernel-config-flash).
Soll es in das CVS, committet man die entsprechende Version -Fertig.
Newmake:
Nach dem "Diffen" muss zusätzlich das m4-File überprüft werden, ob es nicht eine der neuen
Optionen abschaltet und ggf. muss auch hier ein Diff erstellt werden oder:
man erstellt gleich ein neues m4-File unter Berücksichtigung der alten Einstellung bzw. des Falls
den man nicht verändern will.
Ohne zusätzliche Programmunterstützung ist das schon mühsam und fehlerträchtig.
D.h. es wird noch ein Programm benötigt, dass diesen Aufwand minimiert.
Wenn es dazu schon Lösungen gibt, wären Infos darüber hilfreich.

(...cdk/linux ist ein symlink zu ...cdk/linux-$(KERNELVERSION).

Für diese Antwort würden dich impulsive Gemüter vierteilen Das hört sich fast so an als ob ich nicht wüsste, dass es diesen Link gibt.
Meines Wissens interessiert der Link "linux" nur die Treiber, analog zu /user/src/linux auf einem Hostsystem.
Die glibc braucht die Header mit der sie kompeliert wurde - /user/include auf Hostsystemen (?)
Nach einem Kernelupdate sind sie dann weg.

Ich habe mal alle Regeln usw. für 2.6 in newmake bei mir eingebaut.
Grundsätzlich ist es bei mir so, dass der Kernel 2.6.15 kein CDK(Head/newmke) baut.
Da hat sich einiges an den Headern geändert(2.6.13 auch schon).
Man muss also schon gcc/glibc haben um den Kernel zu bauen.
Genau hier gibt es ein Problem mit newmake: Wenn der Kernel upgedatet wird, wird alles neu gebaut (glibc etc.)
So bekomme zumindest ich das CDK mit Kernel 2.6x nicht gebaut.
Ein Gegentest mit Kernel 2.4.31 und anschließendem update auf 2.4.32 hatte dasselbe Ergebnis.Glibc etc. wird neu gebaut.
Vorgehensweise:
bei newmake: CDK mit "make yadd-all" gebaut, danach rules-make und rules-archive geändert, .deps/linuxkernel entfernt,
./autogen, ./configure --bla..., make yadd-all -> Ergebnis s.o.
Edit:
bei Head: CDK mit "make all" gebaut, rules-* geändert, linux* und driver in ./deps entfernt, ./autogen.sh, ./configure --bla... ,make all ->nur das nötige wurde gebaut.


Hoffentlich äußern sich noch andere (Devs?) zu den Änderungen unter der Haube.
Ich weiß, newmake ist experimentell, aber z.Z. ist es für den produktiven Einsatz zu früh. (leider).

[Barf]

@racker:
ich werde auf die Themen ausführlich antworten, später. Ich wurde mich freuen, falls du deine 2.6-Änderungen einchecken wurdest. Es wäre theoretisch möglich den Branch zu branchen; ich halte es aber nicht für notwendig oder wünschenswert.

[racker]

Ich wurde mich freuen, falls du deine 2.6-Änderungen einchecken wurdest.

Ist nichts großartiges, eben nur die Regeln um einen Kernel zu bauen.
Eine fertige yadd kommt dabei noch nicht raus. Ungetestete Sachen committe
ich ungern auch wenn sie in der Theorie funktionieren sollten.
Ich habe mal ein Diff auf meiner HP unter kernel_26_stuff abgelegt.
Wenn es ok ist committe ich es morgen Nachmittag.

[Barf]

Ich habe eine Verbesserung eingecheckt, dass die *-p Verzeichnisse abschafft. Die Verzeichnisse wie root-$gui-$fs wird jetzt direkt aus root, root-$fs und root-$gui gebaut. Das var-Verzeichniss baut deshalb nicht mehr das cramfs-Zeug, was einige Leute gestört hat.

Ich kucke mich demnächst das Problem mit make 3.81beta an: $< wird leer falls alle Prerequisites order-only sind. Falls man "Bug" mit Abweichung zwischen Spezifikation (= Dokumentation) und Implementierung definiert, IST es ein bona-fide Bug in make 3.81beta nach meinem Verständniss.

[gmo18t]

... und wann werden die libs "dünner" gemacht:
wenn "root-$gui-$fs" kopiert wird oder
Wenn die Images zusammengebaut werden ?

- GMo -

[Barf]

... und wann werden die libs "dünner" gemacht:

Bei der Regel für root-$gui-$fs (in File make/flashable-dirs.mk) wird make .../ld.so.1 aufgerufen, was die library reduction durchführt

[racker]

Wenn es ok ist committe ich es morgen Nachmittag.

Done. Allerdings nur für kernel-cdk, da es (noch) keinen Sinn macht die Flashtargets zu berücksichtigen.
Im Moment sehe ich 2 Arbeitspunkte:
-Im CDK sollten die Abhängigkeiten von Buildsystem und Target getrennt werden.
Ideen dazu hätte ich - sind aber noch unausgereift.
-Eine funktionierende yadd erstellen
Letzteres werde ich mir Ende nächster Woche anschauen, wenn ich (hoffentlich) mehr Zeit habe.

[Barf]

Ok, ich bin einige ANtworten noch schuldig.

wurde fehlerhaftiges Ergebniss produzieren.

Ich behaupte nicht, dass u-boot 2x kompiliert wird - es wird nur 2x der Auftrag dazu gegeben.
Warum das zu fehlerhaften Ergebnissen führen soll, werde ich wohl selbst herausfinden müssen.
Dass es beim 2. Aufruf von bare-os nochmal gebaut wurde, scheint ja jetzt behoben zu sein.

Ok, ich sehe dass meine Behauptung nicht richtig ist -- ist aber mehr oder wenig Zufall, und ändert nicht in meiner Kernaussage. "Zufälligerweise" ist es so, dass der Kernel von mkimage abhängt, und die Regel für mkimage, als Nebeneffekt u-boot gebaut. Wäre es deswegen eine gute Idee, das explizite Abhängen des bare-os von u-boot zu entfernen (sofern ich verstehe, rackers Vorschlag)? Nein, es wäre aus folgende Grunden keine gute Idee: Erstmals wäre die Makefile schwieriger zu verstehen: Der Leser fragt sich, falls nicht u-boot benötigt wird. Zweitens ist es gefährlich und fehlerträchtig Programmierung auf solche Nebeneffekte sich zu verlassen. Dass mkimage und u-boot als gleiche Regel implementiert ist -- ist nirgendswo in "Regel-API-Dokumentation" festgelegt, und kann sich ändern. (Erinnerung: der Kernel IST eine aktuelle Baustelle!) In einer richtigen Target ist alle tatsächlich notwendige Prerequistie aufgelistet, auch wenn eine Anruffolge wie "make all" oder "make everything" dies nicht fordert. Das "make everything" durchläuft ist nicht ausreichend für die Korrektheit! Letztendlich werden die Leistungseinbuße für "unnötige" Prerequisites in millisekundenbereich liegen.

Ich weiss nicht richtig was du sagen willst: ich versuche divergierende Fileversionen vernünfig zu maintainen, und du findest es einfach sch*?
....... Es gib in newmake drei m4-"single-source" files: busybox.config.m4, dbox2-flash.c.m4 und rcS.m4. Kandidaten wäre die Konfigurationsfiles für u-boot und der Kernel. Vielleicht leichter zu diese Beisplele zu relatieren?

Es ist erstrebenswert, trotzdem sollte man das Verhältnis von Aufwand und Nutzen beachten.
Zugegeben, ich habe mich mit der m4 Erstellung noch nicht eingehend befasst.
Beispiel: kernel-config.

Zum Kernelkonfiguration: Mann notiere, dass eine m4-verwaltung des Kernelkonfiguarionsfile am mindestens z.Z. nicht in newmake stattfindet. Zweitens: Entwicker sind hochqualifizierte Leute, nicht "Mausschubser", wobei das Anlernen von neuen Tools, falls motiviert, durchaus zumutbar ist. Ohne in Detail zu gehen: ich bin nicht beeindrückt von deine Argumente.

Ich habe früher (hier) über die Probleme von der Verwaltung der Files.../neutrino/src/system/[locals.h,locals_intern.h] hingewiesen. Die doppelte Verwaltung ist hier offensichtlich nicht nur ein akademisches Problem, sondern es hat, am mindestens einmal passiert, dass ein(e) Entwickler(in) das CDK in einem unkompilierbaren Zustand versetzt hat, durch Nichtenhalten von den paralellen Datenhaltung (ein Paar Monaten her). (Nur in CVS nachforschen...) Ich habe das problem einfach leise behoben, ohne auf die Trommel zu schalgen, oder der/die Schuldige "zu Rede zu stellen". Soviel zum Thema praktische Bedeutung vom "single-sourcing" Prinzip.

rcS wurde hier diskutiert.

(...cdk/linux ist ein symlink zu ...cdk/linux-$(KERNELVERSION).

Für diese Antwort würden dich impulsive Gemüter vierteilen Das hört sich fast so an als ob ich nicht wüsste, dass es diesen Link gibt.
Meines Wissens interessiert der Link "linux" nur die Treiber, analog zu /user/src/linux auf einem Hostsystem.
Die glibc braucht die Header mit der sie kompeliert wurde - /user/include auf Hostsystemen (?)
Nach einem Kernelupdate sind sie dann weg.
....

Es ist hier sicherlich nicht zielführend, dieses Thema als Vor-/Nachteile von newmake/HEAD zu diskutieren. newmake unterschiedet sich hier minimal von HEAD. Ich habe mich relativ kurz das Thema angeschaut, glaubte es wurde relativ einfach sein, "Unsauberkeiten zu entfernen". Ich habe mich geirrt, und (am mindestens vorübergehend) aufgegeben.

[Barf]

Done. Allerdings nur für kernel-cdk, da es (noch) keinen Sinn macht die Flashtargets zu berücksichtigen.
Im Moment sehe ich 2 Arbeitspunkte:
-Im CDK sollten die Abhängigkeiten von Buildsystem und Target getrennt werden.
Ideen dazu hätte ich - sind aber noch unausgereift.
-Eine funktionierende yadd erstellen
Letzteres werde ich mir Ende nächster Woche anschauen, wenn ich (hoffentlich) mehr Zeit habe.

Ich freue mich riesig, nicht mehr der einzige newmake-Entwickler zu sein

Ich bin auch deiner Meinung, Images in der Kernel-2.6-Arbeit draussen zu lassen, bis 2.6-yadd läuft.

Reorganisation von CDK: Existierende CDK finde ich recht unsauber. Die Abhängigkeiten zwischen $(buildprefix) (= .../cdk) und $(targetprefix) sind unübersichtlich, und es ist leicht, in $(targetprefix) zu viel "aufzuräumen", und dabei den Compiler kaputtmachen.

Am wichtigstens scheint es mir die Buildumgebung (gcc, binutils, glibc, eventuell auch Kernelsources) von $(targetprefix) zu trennen. Diese sollen dann NUR bei Update von diese Komponenten neugebaut werde. newmake geht leider nur einen kleinen Schritt in diese Richtung.

Bei Weiterdiskussion machen wir lieber ein neues Thread auf.

[racker]

Kandidaten wäre die Konfigurationsfiles für u-boot und der Kernel. Vielleicht leichter zu diese Beisplele zu relatieren?

Zum Kernelkonfiguration: Mann notiere, dass eine m4-verwaltung des Kernelkonfiguarionsfile am mindestens z.Z. nicht in newmake stattfindet.

Du hast das vorgeschlagen, ich habe nur eine von beiden ausgesucht....

Zweitens: Entwicker sind hochqualifizierte Leute, nicht "Mausschubser", wobei das Anlernen von neuen Tools, falls motiviert, durchaus zumutbar ist. Ohne in Detail zu gehen: ich bin nicht beeindrückt von deine Argumente.

Naja wenigstens haben diese Argumente mehr Substanz als eine Antwort mit Binsenweisheiten, die nicht auf die Fragen eingehen.

single source: Eingangs schon erwähnt- schön und gut aber den Aufwand
auf eine abstraktere Ebene zu verlagern bringt auch nichts.

Es ist hier sicherlich nicht zielführend, dieses Thema als Vor-/Nachteile von newmake/HEAD zu diskutieren.

Bei den vielen Änderungen "unter der Haube" geht es wohl schon allgemein
um die Verbesserung des CDK
Aber du hast recht, ein eigener Thread ist dafür besser.

[racker]

Ich freue mich riesig, nicht mehr der einzige newmake-Entwickler zu sein

Die paar Zeilen ....
Ich habe es schon oft genug durchblicken lassen, mir gefällt "newmake" ganz gut
und bin auch bereit daran mitzuarbeiten aber einige Details finde ich nicht so toll.

-Im CDK sollten die Abhängigkeiten von Buildsystem und Target getrennt werden.
Ideen dazu hätte ich - sind aber noch unausgereift.

Reorganisation von CDK: Existierende CDK finde ich recht unsauber. Die Abhängigkeiten zwischen $(buildprefix) (= .../cdk) und $(targetprefix) sind unübersichtlich, und es ist leicht, in $(targetprefix) zu viel "aufzuräumen", und dabei den Compiler kaputtmachen.

Ich denke wir meinen beide dasselbe

[Barf]

Endlich:

Building Flash Images and YADDs with newmake, auch als PDF erhältlig.

Deutsche Version geplant.

[Barf]

Neue configure-option: --with-rootpartitionsize=SIZE, siehe hier.

racker wird meine m4 Files hassen

[JtG-Riker]

Neue configure-option: --with-rootpartitionsize=SIZE, siehe hier.

racker wird meine m4 Files hassen

Ich auch