Dbox2 Entwicklungsumgebung
Development
- Allgemein
- Neutrino-HD-Entwicklung
- dbox2 Entwicklung
Inhaltsverzeichnis
Allgemeines
Newmake ist eine Überarbeitung des alten "make" Prozesses, inzwischen auch als Oldmake bezeichnet, und wurde durch Barf ins Leben gerufen.
Neben einer deutlich strukturierteren Basis, bietet es unter anderem auch den Vorteil, dass es auch ohne ohne großes Verständnis für den Buildprozess gelingen kann, Flashimages und YADDs unter Linux zu erstellen.
Basierend auf Newmake gibt es inzwischen auch eine auf Scripts basierende Quasi-Frontendlösung, mit der sich Flashimages oder YADDs benutzerdefiniert erstellen lassen, das sogenannte yBuild.
Dieser Artikel basiert zum größtem Teil auf die deutsche Version von Barfs Newmake-Dokumentation, die er uns freundlicheweise zur Verfügung gestellt hat.
Eine detaillierte Beschreibung (auch der make targets) unter anderem auch in englischer Sprache befindet sich auf Barf's Homepage.
Dieser Artikel behandelt Newmake aus Sicht des Benutzers (nicht Entwickler). Es behandelt die Image- u. YADD-Herstellung sowie einfache Beipiele für Benutzeranpassungen ("Customization").
Zur Geschichte
Vor einigen Jahren war die Imageherstellung für die Tuxbox so etwas wie "Schwarze Kunst". Die Makefile-Unterstützung war, insbesondere für andere Images als cramfs-Images, ziehmlich lückenhaft. Die CVS Werkzeuge waren schlecht, oder unvollständig. Noch schlimmer, einige Teile wurden absichtlich geheim gehalten. Vorallem das Werkzeug, jetzt als mkflfs bekannt, welches inzwischen aber im CVS-Verzeichnis .../hostapps/mkflfs zu finden ist, wurde zurückgehalten.
Laut eines Forumsbeitrags aus dieser Zeit, waren die meisten Entwickler nicht in der Lage, eigene Images herzustellen. Die "Gilde der Imagehersteller" wurde geboren. Aus dieser Zeit dürften die "AlexW-Images" ein Begriff sein.
Hauptsächlich bestanden diese aus reinen CVS-Sources mit einigen mehr-oder-weniger geheim gehaltenen "Fixes", (vermutlich) notwendig für das Herstellen eines funktionierenden Images aus dem CVS-Quellcode.
Im August 2003, wurde es für das GNU DBox2 Software-Projekt in zunehmendem Maße peinlich, mkflfs geheim zu halten und der Quellcode für mkflfs wurde ins CVS eingecheckt. Auch die Funktionalität der Makefiles wurde stufenweise verbessert. Noch war viel zu wünschen übrig: Funktionalität, Pflegbarkeit, gesundes Software-Design...
Ein Image aus reinen CVS-Dateien zu bauen, war nicht wirklich möglich.
2004 wurde das YADI ("Yet Another DBox Image") Projekt geboren.
Sein Ziel war es, das "Imagebauen" zu automatisieren und zu vereinfachen. Zu diesem Zweck wurden eine Anzahl von Scripten und Patches gesammelt und/oder geschrieben. Zusätzlich wurden flashfertige Images zur Verfügung gestellt.
YADI war ein grosser Erfolg. Das Ziel wurde erreicht. Images wurden zur Verfügung gestellt, die (fast) vollständig auf freier Software basierten, sowohl inhaltlich als auch bezüglich der benötigten Werkzeuge, in einer Weise, die für den Benutzer durchaus nachvollziehbar war.
Mit dem YADI-Skript war das automatische Imagebuilden zwar möglich, jedoch statt grundlegende Schwächen im CDK-Imagebau-Prozeß zu beseitigen, stellte man Skripte zum Imagebauen zur Verfügung. Es wurde kein übliches Buildsystem zur Verfügung gestellt, wie dies beispielsweise von Make, oder ein neuerer Nachfolger wie Ant,Cmake oder Maven könnten.
Newmake, verfügbar als alternativer Branch im CVS, versucht diese Schwächen zu beseitigen.
Ein spezieller Dank an jedem, der Bugreports und Feedback geliefert hat. Insbesonderes gilt dies für dietmarw, der Newmake benutzt, um die dietmarW-Images zu erzeugen.
Ziel
Das Ziel des vorliegenden Artikels ist es, dem Leser grundlegendes Know-How zu vermitteln. Es ist nicht das Ziel, eine idiotensichere Schritt-für-Schritt Anweisung bereitzustellen, wie das bei sogenannten HOWTO's der Fall wäre.
Kenntnisse im Umgang mit Shellskripten wird für viele Teile, insbesondere für das Customization-Kapitel, aber nicht für Image/YADD-Herstellung in seiner einfachsten Art und Weise vorausgesetzt.
Der vorliegende Artikel versucht nicht die innere Funktion der Makefiles und des Makeprozesses zu beschreiben. Hierfür wird der Leser auf diverse Quellen, und zu relevanten Threads im CDK-Forum des Tuxbox-Forums hingewiesen. Alle Optionen für configure werden auch nicht beschrieben, nur die Allgemeinsten und Wichtigsten.
Wie schwierig ist es?
Die Antwort könnte lauten: Es ist so schwerig wie man diesen Artikel zu lesen versteht. Für den Leser, der ohne Probleme den Inhalt dieses Artikels versteht, sollte es kein Probleme sein. Leser, für die das Meiste nur Kauderwelsch ist, sollten vielleicht besser bei fertigen Images bleiben.
Images und YADD's bauen
Targets
Es gibt neben zahlreichen untergeordneten Zielen (Targets), zwei hauptrangige Targets. Diese wären entweder
oder
Ein YADD besteht aus einigen Dateien, die die DBox anstatt aus dem Flash über den TFTP-Service lädt, sowie ein Filesystem, das über einen NFS-Server der dBox zur Verfügung gestellt wird.
Diese Betriebsart hat insbesondere während der Softwareentwicklung oder beim Erlernen des Systems viele Vorteile.
Der Name "YADD" bedeutet übrigens "Yet Another DBox Distribution" ("noch eine dBox Verteilung").
Erste Schritte und Überlegungen
Eine Empfehlung für den angehenden "Image/YADD-Lehrling" wäre:
Baue zuerst ein YADD mit Deiner Lieblings-GUI, und lerne damit umzugehen.
Nächster Schritt wäre dann, ein jffs2-Image mit der Lieblings-GUI zu erstellen.
Meistens möchte man die folgenden Schritte kombinieren und/oder automatisieren.
In diesem Artikel bezeichnet "GUI" entweder
Das "Filesystem" im Kontext eines kompletten Images bezeichnet das Dateisystem, in dem das root-Verzeichnis liegt. Diese kann ein
- cramfs (ein komprimiertes, Read-only filesystem für embedded Systeme) sein,
- squashfs (ein weiterd komprimiertes read-only-Dateisystem, was leistungsfähiger als cramfs betrachtet wird)
oder
- jffs2 (ein "journalled" Read-Write-Filesystem).
Ein "cramfs Komplett-Image" besteht aus einem Root-Dateisystem mit dem cramfs Dateisystem und einem kleineren jffs2-Filesystem, das nach /var gemounted wird.
Analog gilt dies auch für "squashfs Komplett-Images", während ein "jffs2 Komplett-Image" kein separates /var-Dateisystem enthält, weil jffs2 an sich beschreibbar (var) ist.
Zusätzlich enthalten die Komplett-Images eine weitere Partition, die den u-boot-Bootloader enthalten. Diese Partition ist zwischen dBoxen mit einen und zwei Flashchips unterschiedlich. Dieses wird durch "1x" und "2x" angezeigt. Ein komplettes Image würde demnach so benannt werden:
[neutrino, enigma]-[cramfs, squashfs, jffs2].img[1, 2]x,
z.B. als fertiges Image:
neutrino-jffs2.img2x.
Buildsystem Voraussetzungen
Die Voraussetzungen auf dem Buildhost können in etwa so zusammengefasst werden:
Ein modernes Unix/Linux System mit ca. 2 GB freiem Speicherplatz. Epfehlenswert ist es aber mehr Speicherplatz einzuplanen, da beispielsweise bei Verwendung von ccache einiges an Daten zwischengelagert wird und je öfter man kompiliert, es dann doch eng werden könnte.
Das Tuxbox Projekt hat keine favorisierte Buildumgebung. Fragen wie "geht es mit Redhat x.y?" lassen sich nicht genau beantworten. Der Grund hierfür ist, dass niemand sich wirklich dafür interessiert, die Eigenschaften der bestimmten Distributionen zu erkunden. Gewisse Anforderungen werden dagegen für Versionen der Werkzeuge, wie autoconf, automake, make usw. formuliert. Die meisten davon sind in den gängigsten Distributionen bereits enthalten bzw. können nachinstalliert werden. Die momentan erfordelichen Toolversionen sind in folgendender Tabelle zusammengefasst:
Tool | Version | |
cvs | ||
autoconf | 2.57a | |
automake | 1.8 | |
libtool | 1.4.2 | |
gettext | 0.12.1 | |
make | 3.80 | |
makeinfo | Texinfo | |
tar | ||
bunzip2 | bzip2 | |
gunzip | gzip | |
patch | ||
infocmp | ncurses | |
gcc | = 2.95 or >= 3.0 | |
g++ | = 2.95 or >= 3.0 | |
flex | ||
bison | ||
pkg-config | ||
wget |
Der Buildprozess überprüft zu Beginn automatisch einige dieser Anforderungen. Wenn eines dieser Tools fehlt, oder wenn die Version zu alt zu sein scheint, ist es in der Regel einfacher, die erforderliche Version nachträglich zu installieren, entweder als kompiliertes Paket, z.B. im rpm-Format vom jeweiligem Distributor, oder sich direkt die Quellen zu besorgen, zu kompilieren und zu installieren, als zu versuchen oder herauszufinden, ob die oben genannten Anforderungen wirklich notwendig sind.
Hinweis:
In anderen Anleitungen zum Buildvorgang wird gefordert, dass Tools wie fakeroot,
mksquashfs, mkcramfs, mkjffs2fs (oder mkfs.jffs2), vielleicht auch mklibs
oder ccache, auf Ihrem System installiert sein müssen. In dieser Umgebung ist dies nicht
erfordelich, da einige entweder überhaupt nicht benötigt werden bzw. die Installation im
Makeprozess selbst vorgenommen wird!
Builden auf einem Unix-non-Linux System sollte vermutlich auch möglich sein, so weit die erforderlichen GNU Werkzeuge vorhanden sind. Mit einem anderen make als GNU wird es fast sicher nicht funktionieren, da die GNU-Erweiterungen uneingeschränkt verwendet werden.
Es wird daher davon abgeraten eine Umbegebung z.B. mit Cygwin aufzubauen, da es höchstwahrscheinlich nicht funktionieren wird. In dieser Richtung wurde zwar Einiges für den Makeprozess eingebaut, jedoch dürfte der gegenwärtige Entwicklungsstand nicht den gegenwärtigen Anforderungen entsprechen, um aktuell auch damit arbeiten zu können.
Empfehlenswert ist allerdings eine Buildumgebung mittels VMWare aufzubauen. Hierfür gibt es auch eine "konfektionierte" Lösung von yiogol, der hierfür ein passendes VMWare-Image erstellt hat, dass im Prinzip alle notwendigen Zutaten enthält.
Auschecken
Die Tuxbox Quellen werden durch den Tuxbox CVS-Server bereitgestellt.
Regelmäßige Quellreleases sind niemals gemacht worden, und sind auch nicht für die Zukünft geplant. Für unsere Zwecke werden die Quellen anonym "ausgecheckt", was bedeutet, dass diese auf die eigene Festplatte kopiert werden, indem man zuerst auf einer (lokalen) Festplatte mit "ordentlich" freiem Platz ein leeres Verzeichnis erstellt, z.B. /tuxbox-cvs und in diesen Ordner wechselt, und diesen Befehl ausführt.
cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -f -r newmake -P .
Dieser Befehl checkt die Newmake Files aus. In Fällen, in denen keine Newmake Version vorhanden ist, wird die HEAD-Version ausgecheckt.
Hinweis:
Im HEAD gibt es zwei Files:
- cdk/root/etc/init.d/rcS
und
- cdk/root/etc/init.d/rcS.insmod
Im Newmake werden diese nicht benötigt da sie mittels
cdk/root/etc/init.d/rcS.m4
erzeugt werden.
Um auf der sicheren Seite zu sein, ist es ratsam, diese beiden zu löschen.
Nachdem die Daten ausgecheckt wurden, könnte kann man jetzt einige Patches auf die Quellen anwenden.
Wenn man aber zum ersten Mal kompiliert, ist es ratsam, vorerst keine Patches anzuwenden. Wenn Probleme auftreten, ist es viel einfacher (technisch sowohl als auch für jeden selbst) jemand zu helfen, der die "unveränderten CVS Quellen" verwendet.
Konfiguration
Jetzt müssen einge Zwischenschritte erledigt werden, damit der Buildprozess auch erkennt, was und vorallem wie er es machen soll.
Man wechselt nun in das CDK-Unterverzeichnis
cd cdk
und gibt diesen Befehl ein (ohne Argumente).
./autogen.sh
Dieser erzeugt unter anderem ein Shellskript namens configure.
Wird autogen.sh ausgeführt, wird dabei eine Anzahl von Optionen übergeben, um das System für das Builden eines Images, YADD oder aller anderen gewünschten Ziele entsprechend den Benutzerwünschen vorzubereiten.
Optionen
Für eine komplette Liste von Optionen, benutze den Befehl
./configure --help
Hier einige Ausgaben:
- Program names:
--program-prefix=PREFIX prepend PREFIX to installed program names --program-suffix=SUFFIX append SUFFIX to installed program names --program-transform-name=PROGRAM run sed PROGRAM on installed program names
- System types:
--build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] --target=TARGET configure for building compilers for TARGET [HOST]
Optional Features:
--enable-uclibc enable rules for creating uclibc linked targets --enable-kernel26 set up the CDK to use the 2.6 kernel (experimental) --enable-maintainer-mode enable make rules and dependencies not useful
(and sometimes confusing) to the casual installer
--disable-flashrules disable rules for creating flash targets - build cdk instead --enable-german-keymaps include loadkey and German keymaps in yadds and images --enable-ide include ide/mmc and ext2/ext3 drivers in yadds and images --disable-ext3 exclude ext2/ext3 drivers in yadds and images --enable-xfs include xfs drivers in yadds and images --enable-mmc include mmc drivers in yadds and images - you need to activate a filesystem --disable-drive-gui disables neutrino gui-setup for ide hdd mmc administration - uses utillinux fdisk instead of busybox --enable-nfsserver enable the dBox NFS server --enable-automount enable automount daemon --disable-gui-mount disable GUI mount functionality --enable-sambaserver enable the dBox samba server --enable-upnp include upnp support - depends on audioplayer --enable-flac include Neutrino flac audio support - depends on audioplayer --disable-audioplayer include Neutrino audioplayer/internetradio --disable-pictureviewer include Neutrino pictureviewer --disable-movieplayer include Neutrino movieplayer --disable-radiotext include Neutrino Radiotext support --disable-fx2plugins disable fx2-plugins (games) for gui's --enable-aformat enable aformat - dbox2-only --enable-cdkVcInfo include cdkVcInfo in yadds and images --enable-clock enable clock --enable-dboxshot enable dboxshot --enable-dropbear enable dropbear --enable-dvbsnoop enable dvbsnoop --disable-dvbsub disable dvbsub --enable-esd enable esound --enable-fbshot enable fbshot --enable-gdbserver enable gdbserver --enable-getrc enable getrc --enable-hddtemp include hddtemp in yadds and images - depends on IDE support --enable-input enable the tool named input --enable-ipkg include ipkg in yadds and images --enable-lcshot enable lcshot - dbox2-only --enable-lirc include lirc in yadds and images - dbox2-only --enable-msgbox enable msgbox --enable-openvpn include OpenVPN in yadds and images and build tun kernel module --disable-rtc disable rtc hardware support - dbox2-only --enable-satfind enable satfind --enable-shellexec enable shellexec --enable-sqlite enable sqlite --enable-strace enable strace --enable-sysinfo enable sysinfo --enable-tuxcal enable tuxcal --disable-tuxcom disable tuxcom --disable-tuxmail disable tuxmail --disable-tuxtxt disable tuxtxt completely --disable-internal-tuxtxt disable internal Tuxtxt cache, use only external Tuxtxt plugin instead -enable-tuxwetter enable tuxwetter --enable-ccache enable ccache supported compiling --enable-freesatepg enable UK FreeSat EPG --enable-movieplayer2 enable experimental neutrino movieplayer2 --enable-dreambox-serial-console enable serial console on dream
Optional Packages:
--with-toolchain=PATH, do not build a toolchain but use the one at PATH --with-boxtype valid values: dbox2,tripledragon,dreambox,ipbox,generic --with-boxmodel valid for dreambox: dm500, dm500plus, dm600pvr, dm56x0, dm7000, dm7020, dm7025) valid for ipbox: ip200, ip250, ip350, ip400 --with-targetruleset=NAME OBSOLETE, use --[enable|disable]-flashrules instead --with-assume-kernelsources-old Do not recompile due to new kernel sources --with-filesystems comma seperated list of filesystems to be used, first disk filesystem will be used as default for /hdd entry in /etc/fstab allowed values: nfs (always enabled in yadd), cifs, smbfs, lufs (ftpfs), xfs (not kernel2.4/uClibc), ext2, ext3, extfs (ext2/3), vfat, reiserfs --with-rootpartitionsize=SIZE size of the root partition --with-flashfstype=FS_TYPE type of flash root filesystem partition for the yadd kernel (squashfs+lzma/squashfs) --with-defaultlocale=LOCALE default locale --with-targetprefix=DIR prefix for target files [PREFIX/cdkroot] --with-hostprefix=DIR prefix for host files [PREFIX/cdk] --with-bootprefix=DIR prefix for boot files [PREFIX/tftpboot] --with-flashprefix=DIR prefix for flash files [PREFIX/cdkflash] (only used for flash building) --with-serversupport=DIR prefix for server file templates [PREFIX/serversupport] --with-ucodesdir=DIR optional directory containing ucodes (dbox2 only) [NONE] --with-logosdir=DIR optional directory containing logos [[CVS/]logos] --with-customizationsdir=DIR optional directory containing customization scripts CVS --with-updatehttpprefix=URL optional URL containing the URL of a directory with update images "disable" completely disables internet update code [NONE] --with-busybox-conf=M4_FILE personalized optional m4 busybox configuration file [config/busybox.config.m4] --with-kernel-conf=FILE optional personalized linux kernel config file [config/dbox2_kernel-KERNEL_VERSION.config.m4] [[#--with-checkImage=[none,rename,warn]|--with-checkImage=[none,rename,warn]]] How/if to invoke checkImage [none] --with-cvsdir=DIR where to find the cvs --with-appsdir=DIR apps dir from cvs [[CVS/]apps/] --with-bootdir=DIR boot dir from cvs [[CVS/]boot/] --with-driverdir=DIR driver dir from cvs [[CVS/]driver] --with-hostappsdir=DIR hostapps dir from cvs [[CVS/]hostapps] --with-gnuserver=ADDRESS the gnu server for gnu-stuff (without ftp://) --with-defaultserver=ADDRESS the server that is taken if no server is given/works (without http://) --with-maxcachesize=SIZE maximal ccachesize for ccache --with-maxcachefiles=COUNT maximal count of cachefiles for ccache --with-webif=NAME dreambox webif [standard,expert] --with-epg=NAME dreambox epg [standard,private] --with-mhw-epg enable capture of mhw epg (default off) --with-flashtool=NAME dreambox flashtool [standard,expert] --with-ext-flashtool=NAME dreambox ext-flashtool [yes,no] --with-enigma-debug=NAME dreambox enigma-debug [yes,no]
Für uns sind vorerst nur wenige Optionen interessant. Die Standardvorgaben reichen vorerst völlig aus.
Eine typische Anwendung (Konfiguration), der mit z.B. den Pfadnamen oben kompatibel wäre, könnte so eingestellt werden:
./configure --with-cvsdir="/tuxbox-cvs" --prefix="/dbox2" --enable-maintainer-mode
- --with-cvsdir
sagt wo die Quellen zu finden sind, (darin sollte auch ein Unterverzeichnis .../cdk besitzen). In der Regel ist dies das Verzeichnis in das die Quelldaten gerade ausgecheckt wurden, während
- --prefix
bedeutet, dass eine Anzahl von wichtigen Verzeichnissen als Unterverzeichnisse des besagten Verzeichnisses erstellt werden sollen. Ihre Position kann durch andere Konfigurationsoptionen weiter beeinflußt werden.
- --enable-maintainer-mode
ist, auch für Nichtmaintainers praktisch, da er den hergestellten Makefiles ermöglicht, sich automatisch neu zu erzeugen, sobald die Notwendigkeit entsteht, zum Beispiel nach einem Software-Update.
Es gibt sicher noch andere nützliche Optionen. Einige werden später noch besprochen.
Fehlerausgaben
Überprüfe bitte die Ausgaben von autogen auf Fehler ("Error") und Warnungen.
Hierbei können diese Warnungen ignoriert werden:
/usr/local/share/aclocal/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES from autogen.sh
ebenso folgende Warnungen von configure:
... configure: WARNING: using tuxbox mklibs checking for mkcramfs... no configure: WARNING: using tuxbox cramfs checking for mkjffs2... no checking for mkfs.jffs2... no configure: WARNING: using tuxbox mkfs.jffs2 checking for mksquashfs... no configure: WARNING: using tuxbox squashfs ...
Dies sind nur Hinweise darauf, dass hier projekteigene Versionen einiger Tools verwendet werden.
Beachte!
Wenn man diesen Artikel mit ähnlichen Beschreibungen aus vergangenen Zeiten
vergleicht, bemerkt man, dass die Option --with-targetruleset=[standard,flash] nicht mehr
vorhanden ist. Bisher war es notwendig, bei der Konfiguration sich entweder auf Builds von YADDs
oder Images einzuschränken. Bei Newmake ist dieses nicht mehr notwendig.
Versuche niemals, als root zu bauen!
Kompilieren
Die high-level make Targets, die für das Builden von Komplett-Images relevant sind, lauten:
flash-[neutrino, enigma, all]</nowiki>
flash-[cramfs, squashfs, jffs2, all]</nowiki>
[1x, 2x, alle]</nowiki>
Für YADD-Builds, sind diese:
yadd-[neutrino, enigma, all]</nowiki>
Beispiele:
make flash-neutrino-jffs2-all
erzeugt flashbare jffs2-only Images mit Neutrino, für 1x-Boxen und für 2x-Boxen (Dateinamen neutrino-jffs2.img1x und neutrino-jffs2.img2x).
der Befehl:
make yadd-enigma
erzeugt ein YADD, das Enigma enthält.
Zeitaufwand
Das Kompilieren kann bei so einem Projekt und je nach Konfiguration und Rechnerleistung schon einige Zeit in Anspruch nehmen.
Auf einem Athlon XP 1800 dauert ein Befehl wie make yadd-neutrino mit leeren Verzeichnissen etwa 1 und 1,5 Stunden.
Verwendung von ccache
Um den Vorgang insbesondere bei wiederholten Kompilieren und besonders auf langsameren Rechnern zu beschleunigen, steht die Option
- --enable-ccache
zur Verfügung, welche man mit in die Konfiguration einbinden kann. Erfahrungsgemäß wird so durchschnittlich ca. 1-2 Drittel der Zeit eingespart.
Durch die Option --enable-ccache wird erreicht, sollte das Tool bereits in deiner Distribution installiert sein, dass ccache automatisch erkannt wird und in das Tuxbox-CDK eingebunden wird. Ist es nicht installiert, wird dies auch von configure angezeigt:
... ---------------------------------------- ccache support: no ccache installdir: ccache is not installed please run make ccache or install it and configure again ---------------------------------------- ...
Dann sollte man das Tool nachinstallieren oder mit dem Target
make ccache
in das CDK einbauen und configure wiederholen.
Hinweis
Ccache macht sich erst bemerkbar, nachdem der Buildvorgang mindestens einmal durchgelaufen ist!
Die Option --enable-ccache ist normalerweise völlig ausreichend. Es stehen aber noch weitere untergeordnete Sub-Optionen zur Verfügung, die in Ausnahmefällen verwendet werden können:
- --with-ccachedir=DIR
Diese Option kann man verwenden, wenn man ccache beispielsweise nur als Binary abgelegt hat und den Pfad dazu bestimmen möchte.
Hinweis
Die Option --with-ccachedir bewirkt auch das die mit make ccache installierte Version im CDK und/oder auch die evtl. im System installierte Version ignoriert wird!
- --with-maxcachesize=SIZE maximal
Hier gibt man an, wieviel Speicher ccache verwenden darf in GB z.B: für 2GB
--with-maxcachesize=2
- --with-maxcachefiles=COUNT
Hier kann man angeben, wieviele Dateien ccache cachen darf.
--with-maxcachefiles=20000
Hier würden es logischeweise 20000 sein.
Die Wirksamkeit von ccache lässt sich mit dem Befehl
ccache -s
prüfen. Als Ergebnis werden einige Statistiken über das Cache-Verhalten von ccache ausgegeben:
cache directory /home/<USER>/.ccache cache hit 4 cache miss 191 called for link 17 multiple source files 4 compile failed 17 preprocessor error 2 not a C/C++ file 5 autoconf compile/link 178 no input file 15 files in cache 382 cache size 7.1 Mbytes max cache size 976.6 Mbytes
Tipp
Um die benötigte Zeit genau zu ermitteln, kann man den Befehl time einbauen.
time make yadd-neutrino
Am Ende des Bauvorganges werden damit die entsprechenden Zeitinformationen ausgegeben.
Beispiele
Hier einige Beispiele mit denen man Images, Yadds oder einzelne Targets bauen kann. Diese Beispiele sollten so wie sie hier vorgegeben sind ohne Veränderung auf jedem Linux-System mit den bisher beschriebenen Voraussetzungen laufen. Da die Systeme trotzdem Unterschiede aufweisen können, kann man das aber nicht garantieren.
neutrino-jffs2-Image
#! /bin/bash # beispiel.sh # Diese Script baut neutrino-jffs2 Images, jeweils 1x und 2x #---------------------------------------------- USERDIR=/home/$(whoami) #---------------------------------------------- LOGODIR=$USERDIR/Logos CP=$USERDIR/tuxbox-cvs DB=$USERDIR/dbox2 ARCHIVEDIR=$USERDIR/Archive export CVS_RSH=ssh #----------------------------------------------- cd "$CP" cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -f -r newmake -P . cd cdk /bin/ln -sf $ARCHIVEDIR/ Archive ./autogen.sh ./configure --prefix="$DB" --with-cvsdir="$CP" --enable-flashrules --enable-ccache --with-checkImage=rename --with-logosdir="$LOGODIR" make flash-neutrino-jffs2-all
Neutrino YADD
#! /bin/bash # beispiel.sh # Diese Script baut ein Neutrino Yadd #---------------------------------------------- USERDIR=/home/$(whoami) #---------------------------------------------- LOGODIR=/Logos CP=$USERDIR/tuxbox-cvs DB=$USERDIR/dbox2 ARCHIVEDIR=$USERDIR/Archive export CVS_RSH=ssh #----------------------------------------------- cd "$CP" cvs -d anoncvs@cvs.tuxbox.org:/cvs/tuxbox -z3 co -f -r newmake -P . cd cdk /bin/ln -sf $ARCHIVEDIR/ Archive ./autogen.sh ./configure --prefix="$DB" --with-cvsdir="$CP" --with-logosdir="$LOGODIR" --enable-ccache make yadd-neutrino
Was kommt dann...?
Booten von YADD
Wenn ein YADD frisch erzeugt wurde, kann damit auch die Box booten. Näheres dazu auch im Artikel CDK booten.
Newmake hält auch ein Make-Target für den serversupport bereit.
make serversupport
Dieses erzeugt einige Konfigurationsdateien für den Server der das YADD-Build nahtlos an das Server-Setup anknüpft.
Flashen des Images
Wenn ein Image gebaut wurde, ist der logische nächste Schritt das Einspielen des Images in den Flash der Box. Hierfür ist entweder, das interaktive Flashen innerhalb der GUI (Expertenfunktionen) zu benutzen, oder der dboxflasher zu verwenden. Der dboxflasher wird durch das Make-Target
make serversupport
erzeugt. Andere Möglichkeiten des Flashens werden hier beschrieben.
Inkrementelle Builds
Im allgemeinen ist man nicht an einem einmaligen Build der Software interessiert. Verbesserungen an den Quellen werden in das CVS täglich eingecheckt. Oft möchte man die Software durch eigene Programmierung verbessern oder Patches anwenden. Es ist dabei wünschenswert, dass genau nur die Teile neu erzeugt wird, die neu erzeugt werden sollen, nicht mehr und nicht weniger. Newmake geht einen direkten Weg in diese Richtung.
Um ein Target neu zu bauen, benutze den Befehl
make [target]
und make wird es, falls notwendig, neu erzeugen.
Es kann auch passieren, dass make zusätzlich einen vollständig anderen Bestandteil neu erzeugt! Dies ist dann der Fall, wenn das jeweilige Target von anderen Teilen abhängt, die sich geändert haben.
In einige Situationen kann es auch wünschenswert sein, ein erneutes Bauen einer Komponente zu erzwingen. Einige Komponenten werden in einem Distributionsfile zum Verzeichnis cdk/Archive heruntergeladen, und wenn das Build stattfindet, ausgepackt, evtl. Patches angewendet, konfiguriert, kompiliert, installiert und die Quellen dann wieder gelöscht.
Alles findet automatisch statt. Die Installation eines bestimmten Pakets wird durch das Anlegen einer Markerdatei im Verzeichnis cdk/.deps vermerkt.
Falls gewünscht, kann solch eine Markiererdatei entfernt werden, um das Neuerzeugen der entsprechenden Komponetne zu erzwingen. Es gibt hierfür auch entsprechende Targets, die "Cleaning Targets".
Cleaning targets
Es gibt mehrere unterschiedliche Aufräum-Targets:
make distclean
Das drastischste Reinigungs-Target, (fast) alles löschend, was nicht vom CVS ausgecheckt wurde.
Dieses ist eher selten notwendig.
make mostlyclean
Ein intelligenteres Target ist mostlyclean. Es säubert die Verzeichnisse, die Tuxboxquellen enthalten, lässt aber die Kompilationsumgebung und alle Auspacken-kompilieren-installieren-löschen-Komponente unberührt.
Auch das cdkroot Verzeichnis, (d.h. die Yadd-Installation), sowie die TFTP-Files (Kernel und u-boot) werden nicht angefasst.
make depsclean
Löscht alle Markerdateien im /cdk/.deps Verzeichnis und zwingt so zum Neukompliieren aller Auspacken-kompilieren-installieren-löschen-Komponenten.
Dies ist selten sinnvoll: Diese hängen von ihren Quellen und vielleicht von einem Patchfile ab, und der Makefile kennt diese Abhängigkeiten.
make clean
Kombiniert mostlyclean, depsclean, und flash-clean. Versucht auch soviel wie möglich im cdkroot-Verzeichnis zu löschen, das nicht während des Bootstrapdurchlaufes installiert war. So wird
versucht, die Umgebung in einem Zustand zu bringen, wo die Buildumgebung gerade kompiliert worden ist, z.B. mit make bootstrap.
make flash-semiclean
Dieses Target löscht die meisten Verzeichnisse in $(flashprefix), mit Ausnahme der Boot-Partitionen und der Kernelbauverzeichnisse.
Dieses ist oft sinnvoll, da diese Bestandteile verhältnismässig sich selten ändern.
make flash-mostlyclean
Zusätzlich zum flash-semiclean löscht dieses Target auch Bootfiles und die Kernbauverzeichnisse. Vollimages werden unberührt gelassen.
make flash-clean
Dieses Target löscht Alles in $(flashprefix).
Einige Quellverzeichnisse können mit einem Befehl wie
make -C /tuxbox-cvs/apps/tuxbox/neutrino clean
gesäubert werden.
Aktualisierung des CVS-Quellcodes
Um die Quellen mit neueren Checkins zu aktualisieren, verwende diesen Befehl für das toplevel CVS Verzeichnis (oder von einem anderen Verzeichnis, wenn Ihr wisst, was ihr tut;-). Mögliche Fehler werden in das logfile cvs.log geschrieben.
cvs up -f -r Newmake -dP > cvs.log 2>&1
Tipp
Um mit dem CVS arbeiten zu können nimmt man für gewöhnlich die Konsole für Eingaben. Es gibt aber auch verschiedene Frontendwerkzeuge wie z.B. CrossVC oder Cervisia um nur einige zu nennen, die einen recht komfortablen Umgang mit den CVS-Daten ermöglichen.
Auch einige IDE's wie z.B. Anjuta
bieten solche CVS-Schnittstellen an.
Customization
Bisher lief immer alles darauf hinaus Images oder Yadds zu bauen, die aus unveränderten CVS-Quellen gebaut wurden.
Images und die Yadds können aber auch angepasst ("customized") werden, ohne die Makefiles zu ändern.
Hier gibt es verschiedene Möglichkeiten.
Konfigurationsoptionen
hier einige nützliche Optionen:
Hiermit kann ein Verzeichniss angegeben werden, welches die Ucodes enthält, die im Image enthalten sein sollen.
--with-ucodesdir=[DIR]
Hinweis:
Ein Image, dass ucodes enthält, darf nicht verbreitet werden!
Mit der Option
--with-logosdir=[DIR]
kann ein Verzeichniss angegeben werden, das boot-logos (logo-lcd und logo-fb) enthält, die im Image enthalten sein sollen.
Diese Option
--with-defaultlocale=[LOCALE]
sorgt dafür, dass die gewünschte Sprache schon beim bauen eingestellt wird.
Ändern der Partitionierung
Die Rootpartitionsgröße für cramfs und squashfs Images kann mit der Configure-Option
--with-rootpartitionsize=[SIZE]
angegeben werden.
Die Größe der var-Partition wird automatisch berechnet, wobei man den restlichen Flashspeicher nutzt, der nicht durch die anderen Partitionen benutzt wird. Die Standardgröße ist 0x660000.
Diese Zahl sollte eine Multiple der Erasesize, momentan 0x20000 sein. Dies wird allerdings ignoriert falls es wie bei der jffs2-Imageerstellung unsinnig wäre.
Variablen
Pfade
Es sind noch weitere Benutzeranpassungen möglich. Dafür ist es aber notwendig, etwas Wissen über die innere Funktionsweise der Makefiles zu haben.
In der Folge bezeichnet
$(flashprefix)
den Wert der Makefile Variablen flashprefix (mit Konfiguration wie oben /dbox2/cdkflash)
$(targetprefix)
bezeichnet den Wert der Makefile Variablen targetprefix (mit Konfiguration wie oben /dbox2/cdkroot), und
$(buildprefix)
bezeichnet den Wert der Makefile Variablen buildprefix (mit der Konfiguration oben /tuxbox-cvs/cdk).
Um z.B. ein neutrino-cramfs.img2x zu erzeugen, werden die folgenden Verzeichnisse erstellt:
- $(flashprefix)/root (enthält Filesystem- und GUI-unabhängige Bestandteile)
- $(flashprefix)/root-cramfs (enthält den Kernel, für Root-Filesystem auf cramfs konfiguriert, zusammen mit seinen Treibern) und
- $(flashprefix)/root-neutrino (enthält die Neutrinoinstallation).
Aus diesen drei Verzeichnissen, werden das Rootfilesystemverzeichniss
var-filesystemverzeichnis
- $(flashprefix)/var-neutrino gebaut.
Hiermit ist es möglich, einen Befehl wie
make $(flashprefix)/root-neutrino-jffs2
bzw. wenn man sich im Verzeichnis ./tuxbox-cvs/cdk befindet, den Befehl
make root-neutrino-jffs2
einzugeben, wobei man bei erster VAriante natürlich $(flashprefix) selbst durch den realen Pfad ersetzen muss, da $(flashprefix) nur eine make-Variable ist, welche in unserem Beispiel den Pfad zu ./dbox2/cdkflash darstellt.
Man kann so manuell gewünschten Änderungen an $(flashprefix)/root-neutrino-jffs2 vornehmen, und dann, mit dem Befehl
make flash-neutrino-jffs2-2x
den Imagebau abschließen, um ein Image zu erstellen, das diese manuellen Änderungen enthält.
Dieses kann zwar für den einmaligen Imagebau sinnvoll sein, jedoch in vielen Fällen dürfte eine automatisierte und systematischere Methode erforderlich sein.
Customization-Scripte
Sofern vorhanden und ausführbar werden innerhalb der wichtigsten Targets sogenannte Customization-Scripte aufgerufen. Das bzw. die Scripte müssen im customizationsdir liegen. Dies ist bei Bedarf mit der Option
--with-customizationsdir=[DIR]
einstellbar. Standardverzeichnis ist ./cdk.
Auf diese Scripte werden zwei Argumente zur Laufzeit übergeben:
Für Imagetargets sind dies
- $(flashprefix)
und
- $(buildprefix)
für Yaddtargets sind diese
- $(targetprefix)
und
- $(buildprefix)
Die Bezeichnung "Script" ist etwas irreführend, da sie eigentlich wie normale Programme mit zwei Argumenten ausgeführt werden. Anstelle eines Shell-Scripts könnte dies z.B. ein kompiliertes C Programme, oder ein Perl-Script sein.
Der Name eines Customization Scriptes besteht in der Regel aus dem Namen eines Targetverzeichnisses bzw. in einigen Fällen einem Target und dem angefügtem *-local.sh.
Für Flash-Targets
Der Name der Customization Scripte für Images besteht aus den wie oben benannten Verzeichnissen in flashprefix,
- root
dem Namen der jeweilige Benutzeroberfläche, als "GUI" in Klammern bezeichnet, also
"FS" zeigt an welches Filesystem gemeint ist.
so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut:
- root-local.sh
- root-[GUI]-local.sh
- root-[GUI]-[FS]-local.sh
- root-[FS]-local.sh
- var-[GUI]-local.sh
Beispiele:
root-local.sh root-neutrino-local.sh root-neutrino-squashfs-local.sh root-squashfs-local.sh var-neutrino-local.sh
Für Yadd-Targets
Für Yadds ist das Prinzip ähnlich, nur dass es hier quasi nur einen Ordner gibt. Dafür stellvertretend steht dann
- yadd.
Das "GUI" in Klammern bezeichnet auch hier die jeweilig betroffene Benutzeroberflche, also
so wäre die Bezeichnung der jeweiligen Scripte so aufgebaut.
- yadd-[GUI]-local.sh
Beispiel:
yadd-neutrino-local.sh
Andere Customization Scripte
Die bisher benannten Customization Scripte für Flash- u. Yadd-Targets sind die gebräuchlichsten. Diese werden allerdings gewissermaßen nur an die bestehenden Targets angehängt, anders als es bei den anderen, von denen es in Newmake noch jede Menge mehr gibt, bei denen dies als Ersatz der eigentlichen Targets dienen.
Im Prinzip ginge dies auf so gut wie alle Targets anzuwenden. Möchte man z.B. ein Contrib-Tool "customizen", etwa hdparm, kann man ein Script erstellen:
- hdparm-local.sh
Führt man dann das Target:
make hdparm
aus, wird dann das ausgeführt was im Customization Script angelgt wurde. Die Aktionen im Original-Makefile werden übersprungen.
Auch diese Funktion ist recht interessant und dürfte recht oft Anwendung finden:
Während des make-Durchlaufs werden einige Targets ausgeführt, welche die /.version-Files bei YADD
- version
bzw.
- flash-version
im Image erstellt.
Sofern eines dieser Scripte;
- version-local.sh
- flash-version-local.sh
vorhanden und ausführbar ist, wird es als Ersatz statt des originalen Targets ausgeführt, welches mit
make version
bzw.
make flash-version
angestoßen wird.
weitere Beispiele für Custiomization
Das Custiomizationscripting soll durch das folgende Beispiel noch mehr veranschaulicht werden. Beispiel:
In einem jffs2-Image wird dies gewünscht:
1. Eigene /etc/hosts benutzen, 2. Eigene neutrino.conf, bouquets.xml, services.xml benutzen 3. einschließlich lirc-Komponenten, zusammen mit eigenen lirc Konfigurations-Dateien.
1. und 3. sind Erweiterungen, die nach $(flashprefix)/root kommen sollten, während 2. Neutrino-regeln sind, welche nach sollten $(flashprefix)/root-neutrino-jffs2 gehöhren.
Um 1. und 3. zu erreichen, wird das Script root-local.sh erstellt, z.B.:
#!/bin/sh # root-local.sh flashprefix=$1 buildprefix=$2 newroot=$flashprefix/root myfiles=/home/somewhere/dbox/myfiles cp -f $myfiles/etc/hosts $newroot/etc make flashlirc cp -fr $myfiles/var/tuxbox/config/lirc $newroot/var/tuxbox/config
Das Script für 2. heist root-neutrino-local.sh, was dem verherigen sehr ähnlich ist:
#!/bin/sh # root-neutrino-local.sh flashprefix=$1 buildprefix=$2 newroot=$flashprefix/root-neutrino myfiles=/home/somewhere/dbox/myfiles cp $myfiles/var/tuxbox/config/neutrino.conf $newroot/var/tuxbox/config cp $myfiles/var/tuxbox/config/zapit/bouquets.xml $newroot/var/tuxbox/config/zapit cp $myfiles/var/tuxbox/config/zapit/services.xml $newroot/var/tuxbox/config/zapit
Bitte beachten: Diese Scripte sollen als Beispiele dienen und können vermutlich nicht ohne Anpassung verwendet werden.
Einige "best practices"
In diesem Abschnitt befinden sich einige Richtlinien, die zwar nicht zwingend "notwendig" sind, um korrekte Ergebnisse zu erzeilen, jedoch werden sie langfristig helfen, bessere, zuverlässigere und pflegbare Software zu erstellen. Dies betrifft Customizations, sowie zukünftige Änderungen am Makefile und deren Bestandteile selbst.
Wenn man diese Richtlinien nicht mag, kann man sie ignorieren, zumindest wenn man Customization Scripte für den eigenen Bedarf schreibt.
Idempotens
Es ist fast immer eine gute Idee zu versuchen, ein Installationsscript idempotent zu schreiben. Dies bedeutet, dass das mehrmalige Ausführen den gleichen Effekt hat wie das einmalige Ausführen.
Benutze "make install".
In der Vergangenheit hat das Tuxbox Makefile die Komponenten zuerst in $(targetprefix) installiert, und dann die Imageverzeichnisse durch Kopieren der einzelnen Files aus der $(targetprefix) Hierarchie erstellt. Dieses ist keine sehr gute Softwaretechnik.
Zuerst gehört das Know-How bzgl. Installation des Paketes in das Makefile des Pakets, und soll nicht in einem einzigem großen Makefile sitzen, das einfach einzelne Files rüberkopiert. Wenn dieses Paket sich ändert, z.B. man ein Konfigurations-File hinzufügt oder löscht, wird es auch notwendig, das globale Makefile zu ändern.
Es ist häufig der Fall, dass das Makefile, das zu einem Paket gehört, include-Files, (statische) Bibliotheken, Info-Files etc. installiert, die nicht auf einem enbedded System mit beschränktem Speicher erwünscht sind. Die korrekte Lösung zu diesem (wirklichen!) Problem wäre, das Makefile des betreffenden Pakets zu ändern, entweder, um ein flashinstall-Target zu schreiben, oder das Makefile mit einem Parameter wie installsize=[full,flash] zu versehen.
Wenn dies nicht durchführbar ist, ist es durchaus sinnvoller, daß nach make -C ... install das Löschen unerwünschter Files besser ist, als das kopieren einzelner Files.
Zu erwähnen ist auch, daß in dem Schritt, der die Verzeichnisse $(flashprefix)/root-gui-filesystem erzeugt, das include-verzeichnis, sowie alle statischen Bibliotheken gelöscht werden und dynamische Bibliotheken von unbenutzten Symbolen gestrippt werden.
Antworten auf einige Fragen
Falls das Build nicht gelingt
Es gibt kein Standardverfahren was zu tun wäre, wenn das Build misslingt. Es wird versucht, hier einige Richtlinien zu geben und diese zu lesen bevor man im Forum postet.
Zuerst, überprüft man den Output der ersten zwei Schritte, autogen.sh und configure auf Fehler und Warnungen. Jede Warnung oder Fehler, außer den fünf Warnungen, die oben genannt wurden, zeigen ein Problem an, dass ein Build wahrscheinlich unmöglich macht.
Wenn ein Build abbricht, kann es die Umgebung in einem inkonsistenten Zustand versetzen. Dies gilt insbesondere für die Verzeichnisse in $(flashprefix). Wenn der Bau solch eines Make-Targets abbricht, besteht das Verzeichnis, ist entsprechend seiner Änderungszeit aktuell, und ein folgender make Befehl behandelt ihn wie fertig und okay.
Selbstverständlich wird ein fehlerhaftes Build das Ergebniss sein. Wenn ein Build eines Unterverzeichnisses von $(flashprefix) in die Brüche geht, dann lösche man es, bevor ein anderer Make Befehl ausgeführt wird.
Bei "es funktionierte gestern"-Problemen, ist vermutlich die Umgebung in solch einem Zustand. Ein mehr-oder-weniger drastischer Reinigungsbefehl (siehe oben) ist hierbei oft schneller als eine Problemsuche.
Wenn man Hilfe benötigt, siehe unten!.
Nach dem Flashen: "Kein System" auf dem LCD/Was ist diese "bad magic byte" Zeugs?
Diese Frage kommt hoffentlich nicht... Die kurze Antwort ist: Man weiß es nicht. Wir wissen es nicht. Aber, wenn Ihr diesen Artikel so weit gelesen habt, erwartet bitte keine "kurze Antworten", sondern "gute Antworten". O.K. Das Thema ist ausführlich hier besprochen worden.
Kurz gesagt, das Image "ist" in Ordnung, es ist nur dass irgendwelche Firmware in der dBox es zurückweisen wird, weil es einige "schlechte magische Bytes" auf bestimmten Adressen finden wird.
Das Programm checkImage aus dem CVS, zu finden im Verzeichnis ./hostapps/checkImage ermittelt diese "schlechten Bytes", aber ändert nichts daran, um diese zu beheben. Die Erfahrung zeigt, daß Images, die checkImage für gut findet, wirklich laufen. Cramfs-, oder squashfs Images, worüber sich checkImage beschwert, laufen im allgemeinen nicht, in einigen Ausnahmefällen läufen sie aber doch.
Auch bei jffs2-Images ist dies manchmal der Fall, dass sich checkImage beschwert, die Images laufen, aber eben nicht immer. Mit diesen empirischen Beobachtungen ist man nun sich selbst überlassen.
Newmake weiß, wie dieses Programm aufgerufen werden kann, um die erzeugten Images automatisch zu überprüfen. Die Konfigurationsoption
--with-checkImage=[none,rename,warn]
wird hierfür verwendet. Falls warn gewählt ist, wird für jedes Image, das den Test nicht besteht, eine leere Datei erzeugt, am Namen wird "_bad" angehängt. Wenn rename gewählt wird, wird das fragliche Imagefile nur umbenannt indem "_bad" angehängt wird.
Es muss erwähnt werden, daß die "schlechten magischen Bytes" in einem (oder mehreren!) der Partitionsteile sitzt, und werden nicht durch den abschließenden Schritt erzeugt (die *.img1x und/oder *.img2x Files bauen). Es ist auch möglich, checkImage auf die Partitionsfiles anzuwenden *.jffs2, *.cramfs
- .squashfs
- .flfs1x
- .flfs2x
Schließlich hat checkImage eine Debugoption, die nützlich sein kann.
Ich habe ein Fehler gefunden!
Bugs, Unklarheiten, Verbesserungsvorschläge, etc. der Software sollten vorzugsweise im Cross Development Kit - Forum des Tuxbox-Boards gepostet werden.
Ich benötige Hilfe!
Supportanfragen können im Cross Development Kit - Forum des Tuxbox-Boards gepostet werden. Postings in deutsch oder englisch sind willkommen. Bitte nicht vergessen, die benutzten Konfigurationsoptionen zu erwähnen.
Anhang
Einige nützliche Customization Script Snippets
In diesem Anhang werden einige nützliche Customization Scripte gezeigt. Zwei Scripte sind bereits oben gezeigt worden.
Warnung Auch falls die Beispiele in einigen Fällen benutzbar sind, werden die Scripte als Beispiele, nicht als Lösungen zu den realen Problemen gezeigt. Aus diesem Grund sind die Beispiele hier als Codefragmente, nicht als downloadbare Dateien, veröffentlicht. Bitte nicht verwenden, es sei denn es ist ungefährlich und Ihr versteht, wie sie funktionieren. Es ist grundlegende Script-Erfahrung erfordelich.
Games und Languages nuker
Dieses Script löscht alle Spiele (definiert als plugins mit type=1 in ihrer Konfigurationsdatei), sowie unerwünschte Sprachfiles (Neutrino angenommen). Das File sollte von root-neutrino-$filesystem-local.sh aufgerufen werden.
#!/bin/sh # Nukes all game plugins, as well as all locale files not listed in LANGUAGES newroot=$1/root-neutrino-jffs2 LANGUAGES="deutsch english" for f in $newroot/lib/tuxbox/plugins/*.cfg; do grep 'type=1' $f>/dev/null && rm -f $newroot/lib/tuxbox/plugins/`basename $f .cfg`.* done for f in $newroot/share/tuxbox/neutrino/locale/*; do (echo $LANGUAGES | grep -v `basename $f .locale` >/dev/null) && rm -f $f done
/.version anpassen
Euere eigene /.version-File herzustellen (anggezeigt von Neutrino durch dBox -> Services -> Image-Version und cdkVcInfo beim Booten) ist sicher ein allgemeiner Wunsch.
- flash-version-local.sh
#/bin/sh USER=$(whoami) if [ $0 = $CDIR/flash-version-local.sh ] ; then outfile=$FLASHDIR/root/.version type="Image" else outfile=$TARGETDIR/.version type="Yadd" fi; echo Creating $outfile ... echo "version=`./mkversion -snapshot -version 200`" > $outfile echo "creator=$USER" >> $outfile echo "imagename=$USER-$type" >> $outfile echo "homepage=http://www.your-website.de" >> $outfile
mkversion
Das benannte Script mkversion erzeugt die etwas kryptische Versionszeichenkette:
#!/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
Archivierung der Images
Es ist eigentlich die Aufgabe des Buildprozesses, flashbare Images zu erzeugen, und nicht sie zu archivieren. Jedoch kann die Customization leicht dazu "missbraucht" werden, um irgendeine Art der Archivierung zu ermöglichen, wie das folgende Beispiel zeigt:
#!/bin/sh flashprefix=$1 imagefile=`basename $0|sed -e s/-local.sh//` imagefilebase=`echo $imagefile|sed -e s/\.img.x//` extension=`echo $imagefile|sed -e s/[-a-z0-9]*\.//` newfilename="barf-"$imagefilebase-`date --iso-8601`.$extension echo Copying $flashprefix/$imagefile to $flashprefix/$newfilename... cp $flashprefix/$imagefile $flashprefix/$newfilename
Das Script sollte einen oder mehr der Namen
[neutrino, enigma]-[cramfs, squashfs,jffs2].[img1x, img2x]
haben. Es benennt die Files entsprechend dem Tagesdatum um.
Links
- GNU Make manual
- Autoconf manual
- Automake manual
- GNU Autoconf, Automake, and Libtool
- GNU Coding standards
- Open Source Development with CVS, 3rd Edition
- Barf's Homepage: Barfs Newmake-Dokumentation]
Grundlagen - Installation - Debug-Mode - Hardware - CDK/Development
LCars - Neutrino - Enigma - Plugins - Spiele - Software - Tools - Howto - FAQ - Images
Hauptseite - News - Alle Artikel - Bewertungen - Gewünschte Seiten - Index - Neue Artikel - Impressum - Team
Hilfeportal - Seite bearbeiten - Bilder - Links - Tabellen - Textgestaltung