Ja genau, das is auch meine meinung dazu.
Am besten erstmal "Zweigleisig" fahren, und wenn das neue ausgereift ist, und gut erklärt wird, dann kann man den alten Erstellprozess killen.
Barf ist sicherlich einer, der hier frischen wind reingebracht hat, und seine code es sind immer sehr gut gelaufen. Wäre schade, wenn er jetzt geknickt ist (was ich verstehe). Da steckt immer ne menge arbeit drin, und wenn man die umsonst macht, ist das nicht schön.
Flashtargets in Makefile umgeschrieben
-
dietmarw
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
-
Metallica
- Einsteiger
- Beiträge: 191
- Registriert: Dienstag 30. Dezember 2003, 01:49
-
Barf
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Erstmals etwas Theorie:
Jede Softwareprojekt hat ein Buildsystem. "Make" ist seit 20 (?)
Jahren etabliert, hat sicherlich einige Schwächen. Modernere Nachfolger sind
z.B. Ant. Aufsätze auf Make sind z.B. Imake und das GNU
autoconfig/automake/libtool-System. Das Letzteres wird in dem Tuxbox
Projekt benutzt.
Make basiert sich auf dem Konzept von Regeln. Ein Regel hat ein
(eventuell mehre) Target(s), das von null, ein oder mehre
Prerequisites abhängt. Eine Regel hat auch (normlerweise) ein
Action; eine Anzahl Shellkommandos, die das tatsächlige Bauen des
Targets erledigen (sollen). Das grundlegende Prinzip hinter Make
sagt, dass ein Target (falls schon vorhanden) neu gemacht werden soll,
dann und nur dann wenn am mindestens ein Prerequistite neuerer ist als
das Target.
Dateien, die in einer Regel Prerequisites sind, können in andere
Regeln Targets sein. So können ganze Ketten von Regeln und Actions
gekoppelt werden.
Beispiel:
(Übrigens: Das beste (und auch billigste 
Make-Buch ist die GNU
Dokumentation http://www.gnu.org/software/make/manual/make.html
(wahrscheinlich auch auf die meisten Linux-Systeme schon installiert).)
So wird Make zu einem kraftvollen Tool bei (z.B.) Programmentwicklung:
Nur was unbedingt neu übersetzt werden muss, wird auch
tatsächlich übersetzt. Natürlich unter der Annahme, dass die
Makefile "perfekt" ist, etwas was sich in der Wahrheit oft als
problematisch zeigt (insbesonderes alle Abhängigkeiten korrekt
anzugeben (oder, besser, zu erzeugen)).
Oft wird Make aber "missbraucht", um diverse Kommandos
auszuführen. Das kanonische Beispiel ist sicherlich "make clean"
Dies sind also Regeln, die nicht Regeln in strengen Sinn oben Solche
sind. Sie erzeugen nicht ihre Target, und wird deswegen jedesmal
ausgeführt. (Es sei denn, jemand hat eine Datei namens z.B. "clean"
angelegt. Um zu verhindern, dass Make in diesem Fall das Target als
up-to-date betrachtet, kann mann in GNU Make (aber nicht
notwendigerweise in andere Makes) "clean" als Prerequisite für die
Regel .PHONY deklarieren.) Es ist durchaus möglich, in solche
"Kommando-Regeln" das eigentliche Programm zu bauen. Nachteil ist dass
diese jedesmal ausgeführt wird, auch wenn das Ziel (in informellen
Sinn) schon up-to-date ist. Um diese Nachteil umzugehen, kann mann
"Markers" benutzen: Beispiel:
Dadurch wird das Produkt nur gemacht falls der Marker .program_done
nicht vorhanden ist, d.h., normalerweise nur das erste Mal. Dagegen
hat diese Technik eine entscheindende Nachteil: Es wird nicht mehr
entdeckt, falls das Ziel tatsächlich neu gebaut werden müssen,
z.B. weil prog.c oder prog.h sich geändert hat. Anstatt
überlässt der Makefileauthor die Verantwortigung an den
Benutzer, der instruiert wird, die .program_done file bei Bedarf zu
löschen.
Makes wirkliche Stärke, Abhängigkeiten zu analysieren und
bei Bedarf (aber nur dann) Builds anzustossen, wird, durch den
Marker, ausserkraftgesetzt. Mann verkrüppelt Make. Ein Makefile
mit Markers ist nicht in eigentlichen Sinn von Make, und ist eine
schlechte Makefile.
Dann, vielleicht, scheint das Löschen von .program_done als zu "low-level". Es
ist denkbar, das Target rebuild-program zuzufügen:
Dadurch erreicht mann kaum eine eigentliche Verbesserung. Die
Verantwortigung zu entscheinden, wann ein Zeil neu gebaut sein soll
bleibt bei dem User, nicht bei dem Makeprogramm, wo es gehört.
Soviel zur Theorie. In praktische Fälle kann es sicherlich Fälle
geben, wo die Marker-Technik durchaus motiviert ist, z.B. Installation
eines Hilfstools, das sich selten ändert.
Die Toplevel Makefile(.am) des Tuxbox-projekts, stand Version 1.477,
ist in diesem Sinn ausserordentlich problematisch. Die Markertechnik
ist in die meisten Targets benutzt. Ein Blick in den Foren zeigt auch
die Probleme ...
Mein Motivation war (und ist) die Makefile.am diesbezüglich
aufzuräumen. Coolere Namen für die Targets finde ich wichtig,
ist aber trotzdem zweitrangig. Ausserdem möchte ich die Funktionalität
so zu erweitern, um das automatische, nichtinteraktive Builden vom
images mit unterschiedlichen Inhalt und Filesysteme zu ermöglichen.
Nehmen wir an, dass mann das Beispiel umschreiben wurde, von
Markerfiles nach Targetorientierte Regeln. Offensichtlich wird das
rebuid-program-Target einfach nicht mehr gebraucht, weil es sowieso
nur da war, um eine Macke der ursprunglichen Makefile zu
beheben. Entweder entfernt mann es ganz, oder (eventuell in einem
Übergangszeit) ersetzt mit einem "Glue-Regel" wie
Für zwei Jahren war das Imagebauen tatsächlich eine schwarze
Magie. (Jemand hat dann geschrieben "Die meiste Entwickler können
nicht Images bauen" (!!!)) Teils weil das Programm, das heute in
.../hostapps/mkflfs lebt, von ihren Schöpfer geheim gehalten war,
teils weil die Makefile nur teile der Imagebauprozess abgedeckt
hat. (Das erste Problem hat sich gelöst, das Zweite ist
lllaaannngsam besser geworden.) Deswegen hat sich ein Anzahl mit
unterschiedliche Skripts (und sogenanntes HOWTOs) entwickelt, in der
Regel von miserablestenst zubiegen-bis-es-passt-Qualität. (Damit
habe ich nicht behauptet, dass z.B. das YADI-Skript "schlecht"
wäre, nur dass es eigentlich überflüssing sein "sollte".)
Schlecht wäre, falls Kompatibilität mit diesen Skripte eine
zukünftige Entwicklung hindern wurde. Ein Teufelskreis: Weil die
Makefile schlecht ist, wird Skripts geschriben. Weil diese Skripst
nicht "kaputt gehen darf" kann die Makefile nicht aufgeräumt
werden...
Es ist behauptet worden, dass die neue Regeln kein "fix" oder Update
"auf die schnelle" zuläßt. Hier muss ein Missverständniss
vorliegen. Nach einem source Update, z.B. in Neutrino, wird das
einsprechende Paket neu Kompiliert (rm .deps/neutrino; make neutrino)
genau wie früher. Danach wird das gewünschte Ziel/die
gewünschte Ziele (z.B. root-neutrino.squashfs (entspricht das alte
root-squashfs.img) oder oder neutrino-jffs2fs.img2x) mit z.B. make
$flashprefix/root-neutrino.squashfs oder make
flash-neutrino-jffs2fs-2x erzeugt. Man kann sogar das make neutrino
weglassen, wird automatisch ausgeführt. In Unterschied zu der alten
Regeln: Hier muss der Benutzer selbst dafür verantwortung tragen,
dass die relevante Teilen neu übersetzt wird. Noch schlimmer, falls
er inzwischen, z.B. versehlich, ein Kommando wie "make flash-enigma"
eingegeben hat, bekommt er auch enigma in sein neutrino-image, die
dadurch zu gross wird (werden kann?) und nicht passt. Noch schlimmer,
falls die Update "auf die schnelle" involviert sowohl (z.B.) squashfs-
als auch cramfs-Images wird neuübersetzungen von sowohl u-boot und
flfs erforderlich. Falls auch jffs2fs-Images erzeugt werden soll,
tja... die alte Makefile unterstützt es einfach nicht.
Aus die hier erwähnte Grunden koexistieren die neue
(targetorientierte) und alte (markerorientierte-) Regeln nicht
wirklich gut. Unter Anderem ist es verwirrende zu versuchen, so
ein Makefile zu lesen und zu verstehen.
Als Koexistenzlösung scheint mir eher eine Konfigurationsoption
--targetset-flash-flavor=[new|old]
(default kann gerne old sein) eine Möglichkeit zu sein.
ok, endlich am Ende... Ich möchte nur etwas ausführlich
erklären, warum etwas "seit Jahren ... im CVS" ... woran
"sicherlich 1000sende User dranhängen" trotzdem
verbesserungswürdig sein kann.
Jede Softwareprojekt hat ein Buildsystem. "Make" ist seit 20 (?)
Jahren etabliert, hat sicherlich einige Schwächen. Modernere Nachfolger sind
z.B. Ant. Aufsätze auf Make sind z.B. Imake und das GNU
autoconfig/automake/libtool-System. Das Letzteres wird in dem Tuxbox
Projekt benutzt.
Make basiert sich auf dem Konzept von Regeln. Ein Regel hat ein
(eventuell mehre) Target(s), das von null, ein oder mehre
Prerequisites abhängt. Eine Regel hat auch (normlerweise) ein
Action; eine Anzahl Shellkommandos, die das tatsächlige Bauen des
Targets erledigen (sollen). Das grundlegende Prinzip hinter Make
sagt, dass ein Target (falls schon vorhanden) neu gemacht werden soll,
dann und nur dann wenn am mindestens ein Prerequistite neuerer ist als
das Target.
Dateien, die in einer Regel Prerequisites sind, können in andere
Regeln Targets sein. So können ganze Ketten von Regeln und Actions
gekoppelt werden.
Beispiel:
Code: Alles auswählen
prog.o: prog.c prog.h
gcc -c prog.c
prog: prog.o
gcc -o prog prog.o -lsomelibrary.a
Dokumentation http://www.gnu.org/software/make/manual/make.html
(wahrscheinlich auch auf die meisten Linux-Systeme schon installiert).)
So wird Make zu einem kraftvollen Tool bei (z.B.) Programmentwicklung:
Nur was unbedingt neu übersetzt werden muss, wird auch
tatsächlich übersetzt. Natürlich unter der Annahme, dass die
Makefile "perfekt" ist, etwas was sich in der Wahrheit oft als
problematisch zeigt (insbesonderes alle Abhängigkeiten korrekt
anzugeben (oder, besser, zu erzeugen)).
Oft wird Make aber "missbraucht", um diverse Kommandos
auszuführen. Das kanonische Beispiel ist sicherlich "make clean"
Code: Alles auswählen
clean:
rm -f *.o prog core a.out ...
sind. Sie erzeugen nicht ihre Target, und wird deswegen jedesmal
ausgeführt. (Es sei denn, jemand hat eine Datei namens z.B. "clean"
angelegt. Um zu verhindern, dass Make in diesem Fall das Target als
up-to-date betrachtet, kann mann in GNU Make (aber nicht
notwendigerweise in andere Makes) "clean" als Prerequisite für die
Regel .PHONY deklarieren.) Es ist durchaus möglich, in solche
"Kommando-Regeln" das eigentliche Programm zu bauen. Nachteil ist dass
diese jedesmal ausgeführt wird, auch wenn das Ziel (in informellen
Sinn) schon up-to-date ist. Um diese Nachteil umzugehen, kann mann
"Markers" benutzen: Beispiel:
Code: Alles auswählen
program: .program_done
.program_done:
gcc -o prog -c prog.c -lsomelibrary.a
@touch .program_done
nicht vorhanden ist, d.h., normalerweise nur das erste Mal. Dagegen
hat diese Technik eine entscheindende Nachteil: Es wird nicht mehr
entdeckt, falls das Ziel tatsächlich neu gebaut werden müssen,
z.B. weil prog.c oder prog.h sich geändert hat. Anstatt
überlässt der Makefileauthor die Verantwortigung an den
Benutzer, der instruiert wird, die .program_done file bei Bedarf zu
löschen.
Makes wirkliche Stärke, Abhängigkeiten zu analysieren und
bei Bedarf (aber nur dann) Builds anzustossen, wird, durch den
Marker, ausserkraftgesetzt. Mann verkrüppelt Make. Ein Makefile
mit Markers ist nicht in eigentlichen Sinn von Make, und ist eine
schlechte Makefile.
Dann, vielleicht, scheint das Löschen von .program_done als zu "low-level". Es
ist denkbar, das Target rebuild-program zuzufügen:
Code: Alles auswählen
rebuild-program:
rm -f .program_done
$(MAKE) program
Verantwortigung zu entscheinden, wann ein Zeil neu gebaut sein soll
bleibt bei dem User, nicht bei dem Makeprogramm, wo es gehört.
Soviel zur Theorie. In praktische Fälle kann es sicherlich Fälle
geben, wo die Marker-Technik durchaus motiviert ist, z.B. Installation
eines Hilfstools, das sich selten ändert.
Die Toplevel Makefile(.am) des Tuxbox-projekts, stand Version 1.477,
ist in diesem Sinn ausserordentlich problematisch. Die Markertechnik
ist in die meisten Targets benutzt. Ein Blick in den Foren zeigt auch
die Probleme ...
Mein Motivation war (und ist) die Makefile.am diesbezüglich
aufzuräumen. Coolere Namen für die Targets finde ich wichtig,
ist aber trotzdem zweitrangig. Ausserdem möchte ich die Funktionalität
so zu erweitern, um das automatische, nichtinteraktive Builden vom
images mit unterschiedlichen Inhalt und Filesysteme zu ermöglichen.
Nehmen wir an, dass mann das Beispiel umschreiben wurde, von
Markerfiles nach Targetorientierte Regeln. Offensichtlich wird das
rebuid-program-Target einfach nicht mehr gebraucht, weil es sowieso
nur da war, um eine Macke der ursprunglichen Makefile zu
beheben. Entweder entfernt mann es ganz, oder (eventuell in einem
Übergangszeit) ersetzt mit einem "Glue-Regel" wie
Code: Alles auswählen
rebuild-flash:
@echo "Target rebuild-flash is no longer sensible, or"
@echo "needed, and will be removed soon. Please use target prog instead"
$(MAKE) prog
Magie. (Jemand hat dann geschrieben "Die meiste Entwickler können
nicht Images bauen" (!!!)) Teils weil das Programm, das heute in
.../hostapps/mkflfs lebt, von ihren Schöpfer geheim gehalten war,
teils weil die Makefile nur teile der Imagebauprozess abgedeckt
hat. (Das erste Problem hat sich gelöst, das Zweite ist
lllaaannngsam besser geworden.) Deswegen hat sich ein Anzahl mit
unterschiedliche Skripts (und sogenanntes HOWTOs) entwickelt, in der
Regel von miserablestenst zubiegen-bis-es-passt-Qualität. (Damit
habe ich nicht behauptet, dass z.B. das YADI-Skript "schlecht"
wäre, nur dass es eigentlich überflüssing sein "sollte".)
Schlecht wäre, falls Kompatibilität mit diesen Skripte eine
zukünftige Entwicklung hindern wurde. Ein Teufelskreis: Weil die
Makefile schlecht ist, wird Skripts geschriben. Weil diese Skripst
nicht "kaputt gehen darf" kann die Makefile nicht aufgeräumt
werden...
Es ist behauptet worden, dass die neue Regeln kein "fix" oder Update
"auf die schnelle" zuläßt. Hier muss ein Missverständniss
vorliegen. Nach einem source Update, z.B. in Neutrino, wird das
einsprechende Paket neu Kompiliert (rm .deps/neutrino; make neutrino)
genau wie früher. Danach wird das gewünschte Ziel/die
gewünschte Ziele (z.B. root-neutrino.squashfs (entspricht das alte
root-squashfs.img) oder oder neutrino-jffs2fs.img2x) mit z.B. make
$flashprefix/root-neutrino.squashfs oder make
flash-neutrino-jffs2fs-2x erzeugt. Man kann sogar das make neutrino
weglassen, wird automatisch ausgeführt. In Unterschied zu der alten
Regeln: Hier muss der Benutzer selbst dafür verantwortung tragen,
dass die relevante Teilen neu übersetzt wird. Noch schlimmer, falls
er inzwischen, z.B. versehlich, ein Kommando wie "make flash-enigma"
eingegeben hat, bekommt er auch enigma in sein neutrino-image, die
dadurch zu gross wird (werden kann?) und nicht passt. Noch schlimmer,
falls die Update "auf die schnelle" involviert sowohl (z.B.) squashfs-
als auch cramfs-Images wird neuübersetzungen von sowohl u-boot und
flfs erforderlich. Falls auch jffs2fs-Images erzeugt werden soll,
tja... die alte Makefile unterstützt es einfach nicht.
Aus die hier erwähnte Grunden koexistieren die neue
(targetorientierte) und alte (markerorientierte-) Regeln nicht
wirklich gut. Unter Anderem ist es verwirrende zu versuchen, so
ein Makefile zu lesen und zu verstehen.
Als Koexistenzlösung scheint mir eher eine Konfigurationsoption
--targetset-flash-flavor=[new|old]
(default kann gerne old sein) eine Möglichkeit zu sein.
ok, endlich am Ende... Ich möchte nur etwas ausführlich
erklären, warum etwas "seit Jahren ... im CVS" ... woran
"sicherlich 1000sende User dranhängen" trotzdem
verbesserungswürdig sein kann.
-
mogway
- Semiprofi
- Beiträge: 1287
- Registriert: Montag 30. Dezember 2002, 08:02
Hallo Barf,
grundsätzlich finde ich Deinen Ansatz sehr gut und bin der Meinung das die Änderungen in die richtige Richtung gehen.
Nur die Umsetzung war vielleicht etwas (ich formuliere es mal vorsichtig) unglücklich. Man kann halt nicht erwarten, dass alles innerhalb von ein paar Tagen angepasst ist. Zumal, wie schon erwähnt, dies ein Hobby ist und nebenbei noch die Familie, Arbeit etc. existiert.
Wenn man sich die Arbeit machen möchte die Makefiles umzustricken, sollten bis zur funktionierenden und getesteten Fertigstellung die alten Target erhalten bleiben. Oder, wie auch schon vorgeschlagen die Neuerungen erst einmal in einen extra Branch untergebracht werden. Somit ist die aktuelle Funktionalität sichergestellt. Wer möchte kann dann die neuen Regeln testen und seine vorhandenen Scripte etc entsprechend anpassen. Wenn dann alles zufriedenstellend läuft können die alten Target raus bzw der neue Branch mit dem Head zusammengeführt werden.
Gruß
mogway
grundsätzlich finde ich Deinen Ansatz sehr gut und bin der Meinung das die Änderungen in die richtige Richtung gehen.
Nur die Umsetzung war vielleicht etwas (ich formuliere es mal vorsichtig) unglücklich. Man kann halt nicht erwarten, dass alles innerhalb von ein paar Tagen angepasst ist. Zumal, wie schon erwähnt, dies ein Hobby ist und nebenbei noch die Familie, Arbeit etc. existiert.
Wenn man sich die Arbeit machen möchte die Makefiles umzustricken, sollten bis zur funktionierenden und getesteten Fertigstellung die alten Target erhalten bleiben. Oder, wie auch schon vorgeschlagen die Neuerungen erst einmal in einen extra Branch untergebracht werden. Somit ist die aktuelle Funktionalität sichergestellt. Wer möchte kann dann die neuen Regeln testen und seine vorhandenen Scripte etc entsprechend anpassen. Wenn dann alles zufriedenstellend läuft können die alten Target raus bzw der neue Branch mit dem Head zusammengeführt werden.
Gruß
mogway
-
dietmarw
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
-
Barf
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Inzwischen habe ich eine Version von Makefile.am, configure.ac etc in einer Branch namens "newmake" eingecheckt.
Hier gibt es aber eine ganz neue Version. Insbesonderes ist es dadurch möglich, sowohl yadd als auch Images (alle 6) in ein enzelne Makelauf zu erzeugen, z.B. mit "make yadd-all flash-all-all-all" oder "make everything". Das --with--targetruleset=[flash|standard] ist mit --enable-flashrules ersetzt worden. (Falls das nicht die work-around-schwächen-in-alten-System-scripts kaputtmacht! ) Also kein "make distclean" mehr zwischen yadd-bauen und image-bauen.
Leider ist alles nicht ganz perfekt. Z.B. ist neutrino/enigma-Bauen noch marker-basiert.
make mostlyclean sollte nützlich sein, um "Tuxbox-eigene SW" zu cleanen.
make dboxflasher bastelt ein spezielle u-boot namens dboxflasher wie Hier. (Homer hat leider seine Quellen geheimgehalten. Meines Wissens ist hier die einzige open-source flasher!)
Und eine Menge andre Fixes und Features.
BUILD.changes sagt:
Hier gibt es aber eine ganz neue Version. Insbesonderes ist es dadurch möglich, sowohl yadd als auch Images (alle 6) in ein enzelne Makelauf zu erzeugen, z.B. mit "make yadd-all flash-all-all-all" oder "make everything". Das --with--targetruleset=[flash|standard] ist mit --enable-flashrules ersetzt worden. (Falls das nicht die work-around-schwächen-in-alten-System-scripts kaputtmacht!
) Also kein "make distclean" mehr zwischen yadd-bauen und image-bauen. Leider ist alles nicht ganz perfekt. Z.B. ist neutrino/enigma-Bauen noch marker-basiert.
make mostlyclean sollte nützlich sein, um "Tuxbox-eigene SW" zu cleanen.
make dboxflasher bastelt ein spezielle u-boot namens dboxflasher wie Hier. (Homer hat leider seine Quellen geheimgehalten. Meines Wissens ist hier die einzige open-source flasher!)
Und eine Menge andre Fixes und Features.
BUILD.changes sagt:
Code: Alles auswählen
Configuration options:
--with-targetruleset=[standard|flash] has been replaced by
--[enable|disable]-flashrules. As opposed to previous files,
building yadds and buildung flash images do not exclude
oneanother. Using --enable-flashrules targets for creating flash
images are included in the generated Makefile, otherwise not. By
default they are disabled. If enabled, all compilation is done using
the flash-optimized compilation flags (no debugging info, stripped,
compiled with -Os (optimize for size). Other than that,
--enable-flashrules has no disadvantages, and can normally be left
on. (Will possibly become default in the future.) Using
--with-targetrulset now gives a fatal error (to force users to
think); in the future it should be completely eliminated.
--[enable|disable]-libcrypto has been eliminated. libcrypto is not
built by default; no reason to treat it differently from other
optional libraries.
--serversupport=DIR: New option. Build template files for
/etc/dhcpd.conf, /etc/fstab for a Linux server.
--logosdir=DIR: New option. Picks logo files from this directory, if found.
--ucodesdir=DIR: New option. Installs ucodes from this directory, if
found. (An image containing Betaresearch ucodes may not legally be
distributed.)
--enable-maintainer-mode still exists, but does nothing. It did
nothing (sensible) previously either...
FILENAMES:
Naming system: A file system image is generally named
[root,var]-[neutrino,enigma].[cramfs,squashfs,jffs2]. Full images have
names like [neutrino,enigma]-[cramfs,squashfs,jffs2].img[1x,2x]. The
semantics is hopefully obvious.
The previous version of this work used the notation "jff2fs". It has
been replaced by "jffs2" ("journaled flash file system 2").
Makefile[.am]:
Restructuring to make more target-driven (but still not
perfect). No unnecessary recursive invocation instead of dependencies.
Customization-hooks: Many rules calls customization script, if present.
Now builds root/.version file that can be parsed by neutrino.
Installs only a few plugins per default.
Built full images are checked by checkImage.
The partitioning table file linux/drivers/mtd/maps/dbox2-flash.c is now
generated from an m4-file, for all the different configurations.
Changed targets:
all: different semantics
busybox: replaced by $(targetprefix)/bin/busybox (for yadd) and
$(flashprefix)/root/bin/busybox (for flashing). For this, configurion
files busybox.config and busybox-flash.config merged to
busybox.config.m4.
mostlyclean: deletes built "tuxbox code", but not
unpack-build-install-delete code.
New (public) targets (see doc):
serversupport, everything, yadd-[all,none,neutrino,enigma,lcars], dboxflasher.
POSSIBLE PROBLEMS:
-- rules-installed-flash is now ignored. Problems with this?
-- Due to the new dependencies, sometimes rebuilds too much.
-- Neutrino contains ($(appsdir)/tuxbox/neutrino/src/gui/update.cpp)
stuff like #ifdef SQUASHFS. This brain damage should be fixed in Neutrino.
TODO:
-- Support kernel 2.6. Can this be done without building the kernel
version into the CDK environment?
-- Neutrino and Enigma should be installed (in flash) with something like
$(MAKE) -C $(appsdir)/tuxbox/neutrino install prefix=$(flashprefix)/root/...
-- Plugin configuration.
-- Possibly restructure Makefile.am, with non-essential stuff in
included files,...?
-- Merge all the u-boot-*.dbox2.h files (or at least the ones we are
using) into an m4-file. (Like I did with the busybox.) Combine with
update to u-boot 1.1.3?
-- Ditto for rcS[.insmod],
-- and possibly also for the kernel .config? (Probably best to get 2.6
running first.)
-- Check dependencies carefully, to minimize unnecessary rebuilds.
-- teach neutrino's flashfunction to recognize my file extensions
NICE THINGS TO HAVE:
-- download/build mkcramfs, mksquashfs, mkjffs2, mkfs.jffs2 (fakeroot?)
-- Exactly when (if at all) is fakeroot needed?
-- Really fix the "Kein System"-problem (that checkImage is scratching on).
-- Some rules (e.g. %/lib/ld.so.1) still look awful.
-- At least optionally, it should be possible to build an absolutely
minimal system.
DISADVANTAGES in comparision to old version:
-- Needs more space to build,
-- May rebuild unnecessarily.
-- No support for images with more than one GUIs.
-
Houdini
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
-
Homar
- Senior Member
- Beiträge: 1278
- Registriert: Mittwoch 5. September 2001, 00:00
@Barf: die sind veröffentlicht auf meinem Server und das was eingecheckt ist, sind meine Änderungen 
einige Kleinigkeiten, wie z.B. yadd-booten über cygwin/linux und LCD-Ausgabe beim Flashen, kannste noch aus den Sourcen ersehen auf https://www.remote-admin.info/upload/sc ... _yadd.diff
einige Kleinigkeiten, wie z.B. yadd-booten über cygwin/linux und LCD-Ausgabe beim Flashen, kannste noch aus den Sourcen ersehen auf https://www.remote-admin.info/upload/sc ... _yadd.diff
-
Barf
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Der Patch wird gegen Branch HEAD appliziert, z.B.
cd ..../cdk
gzip -c -d < newmake-2005-11-02.diff.gz | patch -p1
Dadurch wird Makefile.am, configure.ac und acinclude.m4 angefummelt, und neue Dateien doc/BUILD.changes, doc/README-installflash.en sowie Patches/busybox.config.my und Patches/dbox-flash.c.m4 erzeugt.
Anyhow, ich habe das Ganze im Branch "newmake" in CVS eingecheckt.
@Homer: Den Eindruck, dass du die dboxflasher-Quellen lieber nicht ausgeben wurde habe ich von unterschiedliche Threads, z.B. hier gewonnen. Ich freue mich, dass es (am mindestens jetzt) nicht mehr stimmt
Unterschiede zwischen Homers und mein dboxflasher:
-- Homers sagt "flashing image" wo meinem (dummerweise) "loading kernel" sagt.
-- Homers flasher startet einfach die neue Kernel, mein resettet die dBox. Vorteil mit reset: Testet die neu geflashte u-boot, bootet von alle Filesysteme, nicht nur cramfs. Nachteil: falls der dchp-server und tftp-server noch läuft, flasht nochmals. Und vielleicht nochmals, und nochmals...
-- Eventuell etwas mit filenames?
cd ..../cdk
gzip -c -d < newmake-2005-11-02.diff.gz | patch -p1
Dadurch wird Makefile.am, configure.ac und acinclude.m4 angefummelt, und neue Dateien doc/BUILD.changes, doc/README-installflash.en sowie Patches/busybox.config.my und Patches/dbox-flash.c.m4 erzeugt.
Anyhow, ich habe das Ganze im Branch "newmake" in CVS eingecheckt.
@Homer: Den Eindruck, dass du die dboxflasher-Quellen lieber nicht ausgeben wurde habe ich von unterschiedliche Threads, z.B. hier gewonnen. Ich freue mich, dass es (am mindestens jetzt) nicht mehr stimmt
Unterschiede zwischen Homers und mein dboxflasher:
-- Homers sagt "flashing image" wo meinem (dummerweise) "loading kernel" sagt.
-- Homers flasher startet einfach die neue Kernel, mein resettet die dBox. Vorteil mit reset: Testet die neu geflashte u-boot, bootet von alle Filesysteme, nicht nur cramfs. Nachteil: falls der dchp-server und tftp-server noch läuft, flasht nochmals. Und vielleicht nochmals, und nochmals...
-- Eventuell etwas mit filenames?
-
Homar
- Senior Member
- Beiträge: 1278
- Registriert: Mittwoch 5. September 2001, 00:00
Sorry Barf, ich habe dein Posting nicht gelesen gehabt.
Die diffs sind schon länger Online wie du sicherlich an dem Datum sehen kannst.
Die restlichen Änderungen sind notwendig, wenn mann mit dboxbootmanager unter Windows die YADDs booten möchte, und/oder die klassische Linux-Methode mit dhcp benutzen möchte.
btw. falls noch jemand von mir was haben wollte und nicht gekriegt hat, sollte sich melden.
Ist nicht böse gemeint, manchmal übersehe ich einiges in Stresssituationen
MFG
Homar
Die diffs sind schon länger Online wie du sicherlich an dem Datum sehen kannst.
Die restlichen Änderungen sind notwendig, wenn mann mit dboxbootmanager unter Windows die YADDs booten möchte, und/oder die klassische Linux-Methode mit dhcp benutzen möchte.
btw. falls noch jemand von mir was haben wollte und nicht gekriegt hat, sollte sich melden.
Ist nicht böse gemeint, manchmal übersehe ich einiges in Stresssituationen
MFG
Homar
-
dietmarw
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
nach einigen problemen der erste test des diffs gegen den head..
er patch et
er baut alles
beim imageerstellen error:
der erste test des diffs gegen den head..er patch et
er baut alles
beim imageerstellen error:
make[1]: Leaving directory `/home/dietmarw/tux_test/20051103_0400/tuxbox-cvs/apps/tuxbox/lcars'
touch .deps/lcars
[ -x yadd-all-local.sh ] && sh yadd-all-local.sh /home/dietmarw/tux_test/20051103_0400/dbox2/cdkroot /home/dietmarw/tux_test/20051103_0400/tuxbox-cvs/cdk || true
make: *** Keine Regel vorhanden, um das Target »/home/dietmarw/tux_test/20051103_0400/dbox2/cdkflash/neutrino-cramfs.img1x«,
benötigt von »flash-neutrino-cramfs-1x«, zu erstellen. Schluss.
-
Barf
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
-
dietmarw
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
-
Nico 77
- Semiprofi
- Beiträge: 1383
- Registriert: Freitag 18. April 2003, 15:12
-
Homar
- Senior Member
- Beiträge: 1278
- Registriert: Mittwoch 5. September 2001, 00:00
habe ich schon gekuckt, leider nicht mehr available
ich glaube das es einen cvs update -dpaC zum opfer gefallen sein muss.
aber da war nicht viel drin.
ves1820 kann kein Autoinversion und einige delays wurden nach der alten methode gamacht.
dann noch die Initialisierung der Register wie früher, nicht nach linuxtv
ich glaube das es einen cvs update -dpaC zum opfer gefallen sein muss.
aber da war nicht viel drin.
ves1820 kann kein Autoinversion und einige delays wurden nach der alten methode gamacht.
dann noch die Initialisierung der Register wie früher, nicht nach linuxtv
-
snowmen
- Neugieriger
- Beiträge: 19
- Registriert: Samstag 5. November 2005, 16:09
Meckerecke
Hallo Ihr
Auch wenn dies hier mein erstes Posting ist (ich les schon seeehr lange ... )
Ich muss mal ne Kritik loswerden , ob angebracht oder nicht , obs in diesen Tread passt oder nicht !
Ich unterstütze Barf's Initiative die Makerules zu vereinfachen.weil es durchaus sinn macht.
Ich hab nem Kumpel eine Nokia Dbox geschenkt ,und ihm mit auf den Weg gegeben wie er die Software Kompilieren kann (oder sollte mit ein paar netten diff's) er ist nicht der Dümmste (sozuzusagen) weil als SysAdmin in unserer Firma weiß er schon ein bissel was er tut , I hope so ...
ABER : Ich muss das jetzt mal für einen aussenstehenden " unbedarften" Anfänger sprechen ---- der auch noch gewillt ist sich in die Materie einzuarbeiten:
Könnten sich die beteiligten Imagesriptler wie Yadi , Jtg bzw die (sich verantwortlich fühlenden) devs mal im Chat zusammenfinden und sich auf einheitliche Rules zu einigen und dies dann auch noch zu dokumentieren.?
Ich meine , ICH für meine Person kann mir schon ein Image bauen ,aber wenn sich ein Neuling da mal ernsthaft einarbeiten will , der wird doch ...irre... ob der 1000 Rules ,oder sehe ich das falsch ?
Nix für ungut , des ist meine Meinung
..und nun schlagt mir..
Auch wenn dies hier mein erstes Posting ist (ich les schon seeehr lange ... )
Ich muss mal ne Kritik loswerden , ob angebracht oder nicht , obs in diesen Tread passt oder nicht !
Ich unterstütze Barf's Initiative die Makerules zu vereinfachen.weil es durchaus sinn macht.
Ich hab nem Kumpel eine Nokia Dbox geschenkt ,und ihm mit auf den Weg gegeben wie er die Software Kompilieren kann (oder sollte mit ein paar netten diff's) er ist nicht der Dümmste (sozuzusagen) weil als SysAdmin in unserer Firma weiß er schon ein bissel was er tut , I hope so ...
ABER : Ich muss das jetzt mal für einen aussenstehenden " unbedarften" Anfänger sprechen ---- der auch noch gewillt ist sich in die Materie einzuarbeiten:
Könnten sich die beteiligten Imagesriptler wie Yadi , Jtg bzw die (sich verantwortlich fühlenden) devs mal im Chat zusammenfinden und sich auf einheitliche Rules zu einigen und dies dann auch noch zu dokumentieren.?
Ich meine , ICH für meine Person kann mir schon ein Image bauen ,aber wenn sich ein Neuling da mal ernsthaft einarbeiten will , der wird doch ...irre... ob der 1000 Rules ,oder sehe ich das falsch ?
Nix für ungut , des ist meine Meinung
..und nun schlagt mir..
-
mogway
- Semiprofi
- Beiträge: 1287
- Registriert: Montag 30. Dezember 2002, 08:02
-
JtG-Riker
- Image-Team
- Beiträge: 1015
- Registriert: Freitag 7. Februar 2003, 18:37
-
Barf
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Ich habe Neues in branch newmake eingecheckt:
- Weitere cleanup, insbesonderes in $(srcdir)/root/...
- rcS und rcS.insmod gemerged. Ich beschreibe dies in einem separatem Thread. (Warning: rcS und rcS.insmod wird überschrieben.)
- --enable-oldtargets ist neu configure-Option. Dadurch wird ein Anzahl targets (z.B. flash-cramfsneutrinoimages) die in dem alten Makefile, aber nicht in meinem Makefile vorhanden war, definiert. Die Kompatibilität mann dadurch gewinnt soll nicht übertrieben werden: Die Semantik ist nicht immer identisch. "rebuild-flash" ist und bleibt krank. enabled ist default (in Interesse des Kompatibilität!).
-------------------------------------
Zu den letzen Beiträgen:
Für (vielleicht) zwei Jahren war das Imagebuilden eine schwarze Magie. Das Yadi-Projekt hat versucht, dies zu beseitigen. Dazu zwei Massnahmen:
- Zusammenpacken für diverse sachen "mann braucht",
- Einigermasse automatisierte Buildverfahren. Mann hat hier nicht die grundlegende Schwächen addressiert, sondern eine Anzahl Shellskripts geschrieben, die eine Menge "private" Maketargets benutzt. Mann hat dadurch Make als Buildsystem quasi ersetzt.
Sicherlich hat mann viel erreicht, und wir sollen darüber dankbar sein.
Yadi ist ein Workaround rundum die wesentlicht Schwächen. Das ist nichts Schlimmes oder Böses in sich. Aber wenn der Workaround (für Probleme die inzwischen behoben sind onder wird) ein Grund wird, Veränderungen zu wiedersprechen, dann ist Yadi nicht ein Teil der Lösung; es ist ein Teil des Problems.
- Weitere cleanup, insbesonderes in $(srcdir)/root/...
- rcS und rcS.insmod gemerged. Ich beschreibe dies in einem separatem Thread. (Warning: rcS und rcS.insmod wird überschrieben.)
- --enable-oldtargets ist neu configure-Option. Dadurch wird ein Anzahl targets (z.B. flash-cramfsneutrinoimages) die in dem alten Makefile, aber nicht in meinem Makefile vorhanden war, definiert. Die Kompatibilität mann dadurch gewinnt soll nicht übertrieben werden: Die Semantik ist nicht immer identisch. "rebuild-flash" ist und bleibt krank. enabled ist default (in Interesse des Kompatibilität!).
-------------------------------------
Zu den letzen Beiträgen:
Für (vielleicht) zwei Jahren war das Imagebuilden eine schwarze Magie. Das Yadi-Projekt hat versucht, dies zu beseitigen. Dazu zwei Massnahmen:
- Zusammenpacken für diverse sachen "mann braucht",
- Einigermasse automatisierte Buildverfahren. Mann hat hier nicht die grundlegende Schwächen addressiert, sondern eine Anzahl Shellskripts geschrieben, die eine Menge "private" Maketargets benutzt. Mann hat dadurch Make als Buildsystem quasi ersetzt.
Sicherlich hat mann viel erreicht, und wir sollen darüber dankbar sein.
Yadi ist ein Workaround rundum die wesentlicht Schwächen. Das ist nichts Schlimmes oder Böses in sich. Aber wenn der Workaround (für Probleme die inzwischen behoben sind onder wird) ein Grund wird, Veränderungen zu wiedersprechen, dann ist Yadi nicht ein Teil der Lösung; es ist ein Teil des Problems.
... wobei das langfristige Ziel natürlich eine Merge sein muss.das in einen eigenen Branch eingecheckt hat, so kann jeder nutzen was er möchte.
-
dietmarw
- Contributor
- Beiträge: 1833
- Registriert: Mittwoch 10. April 2002, 15:39
erste testergebnisse hier..
http://tuxbox.trale.de unter test_new_flashrules_barf
ungestrippt wäre die yadd ca. 1gb
http://tuxbox.trale.de unter test_new_flashrules_barf
ungestrippt wäre die yadd ca. 1gb
-
Barf
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Und heute eine neue Version eingecheckt, in branch newmake. Plugins werden installiert: bei Neutrino tuxmail, tuxtxt, texcom, vncviewer und die fx2-plugins (ausser bouquet). Bei Enigma die enigma-plugins (= in Unterverzeichniss apps/tuxbox/plugins/enigma), sowie die fx2-plugins.
Ferner soll alle abhänigkeiten von "doofen" Markerfiles weg sein ("doof" sind solche, die eine notwendige neukompilierung verhindert, siehe eine frühere Beitrag von mir). Also keine
rm .deps/dingsbums
mehr! Leider ist alles mit den dependencies nicht ganz richtig: es wird einige unnötige builds ausgeführt. Unterstützung für kernel 2.6 fehlt.
Die involvierte files sind:
Ich habe auch ein vollständiges diff hier abgelegt.
Ferner soll alle abhänigkeiten von "doofen" Markerfiles weg sein ("doof" sind solche, die eine notwendige neukompilierung verhindert, siehe eine frühere Beitrag von mir). Also keine
rm .deps/dingsbums
mehr! Leider ist alles mit den dependencies nicht ganz richtig: es wird einige unnötige builds ausgeführt. Unterstützung für kernel 2.6 fehlt.
Die involvierte files sind:
Code: Alles auswählen
cdk/Makefile.am
cdk/configure.ac
cdk/acinclude.m4
cdk/doc/BUILD.changes
cdk/Patches/busybox.config.m4
cdk/Patches/dbox2-flash.c.m4
cdk/root/Makefile.inc
cdk/root/etc/init.d/Makefile.am
cdk/root/etc/init.d/rcS.m4
cdk/root/share/udhcpc/Makefile.am
cdk/backwards_compat.mk
cdk/root/etc/Makefile.am
apps/tuxbox/plugins/configure.ac
apps/tuxbox/tools/configure.ac
apps/tuxbox/tools/misc/Makefile.am
-
mb405
- Tuxboxer
- Beiträge: 2331
- Registriert: Donnerstag 24. März 2005, 21:52
ausgehend von dem anderen thread mal meine fragen an dich Barf.
1.) da es keine rm .deps/blabla nicht mehr gibt, wie mache ich die änderungen wirksam
2.) an welcher stelle des erstellprozesses kann ich meine manuellen änderungen, patches einspielen.
wäre wirklich sehr nett, wenn du das für die newbies bisserl besser erklären könntest. ich habe bis jetzt immer das yadi-script genutzt, wo ich die enigmas und jffs images auscommentiert habe im erstellprozess.
1.) da es keine rm .deps/blabla nicht mehr gibt, wie mache ich die änderungen wirksam
2.) an welcher stelle des erstellprozesses kann ich meine manuellen änderungen, patches einspielen.
wäre wirklich sehr nett, wenn du das für die newbies bisserl besser erklären könntest. ich habe bis jetzt immer das yadi-script genutzt, wo ich die enigmas und jffs images auscommentiert habe im erstellprozess.