newmake Build Skripte

[yjogol]

Dies ist die Fortsetzung dieses Threads http://forum.tuxbox-cvs.sourceforge.net ... 552#320552

Es gibt nun die Build Skripte "yBuild".
Ich halte es für sinnvoll, wenn wir uns auch auf eine einheitliche Ordner-Struktur einigen.

Also ab den "Hauptordner" z.B. /home/<username>/tuxbox
könnte eine Ordnerstruktur folgendermaßen aussehen:

Code: Alles auswählen

/home/<username>/tuxbox
- tuxbox-cvs
- dbox2
  - cdk        (make generiert)
  - cdkroot    (make generiert)
  - cdkflash   (make generiert)
  - tftproot   (make generiert)
- Archive      (Archive ablegen und per ln auf cdk/Archive abgebildet)
- yBuild       (Build Helper Scripts)
  - include    (Skript Includes)
  - examples   (Beispieldateien)
    - locales   ( ..  für locales)
    - patches  ( ..  für patches)
- Private      (customizing)
  - files      (Files samt Unterordnern, die via *local.sh für YADD oder Flash Verzeichnisse kopiert werden)
  - logos      (für --with-logos-dir)
  - ucodes     (für --with-ucodes-dir)
  - patches    (eigene Patches, die auf CVS checkout angewendet werden)
  - locales    (für --with-customizationsdir)

In yBuild kann dann einen neue Option eingebaut werden: Führe patch für alle *.diff in Private/patches aus.

Weiterhin gibt es viele ..-local.sh für newmake. Wir können einen Satz unter examples bereitstellen, in dem wir die Erfahrungen hier aus dem Board wiederspiegeln und es auch Einsteigern einfacher machen.

Ich hatte auch mal Skripte die ein durchschnittliches Linux mit den benötigten Tools versorgt (apt get etc.). Vielleicht hat ja jemand Lust hierauf. Dann kann man ein nacktes Linux nehmen, das Skript ausführen ... und fertig ist die build-Umgebung.

Eine Anpassung / Erweiterung auf oldmake ist natürlich auch denkbar.
So ich konsolidiere jetzt die letzte Version von StevenSch mit meinen Änderungen und erweitere mal um das patchen. Downloadlink kommt nachher.

Was haltet ihr von der Ordnerstruktur? Was fehlt?

Gruß
yjogol

[Tommy]

In yBuild kann dann einen neue Option eingebaut werden: Führe patch für alle *.diff in Private/patches aus.

GEIL - ich tu mich immer so schwer mit den Parametern und den Verzeichnisebenen

[PT-1]

Vor allem hat irgendwie jeder seine eigene Struktur und wenn dann copy & paste dann hapert es da immer...

Genial & Danke an alle

[det-box]

JO,

super so

Det

[retabell]

Moin alle,

Was haltet ihr von der Ordnerstruktur? Was fehlt?

ich würde es schön finden, das archiv-DIR absolut einstellen zu können
(ohne Linken) auch unterhalb des home-Dirs
z.B auf /media/usb-disk/Archive.

ist für die VM sehr praktisch , und vielen Dank für das tolle VM-Image!!!

Dann kann man ein nacktes Linux nehmen, das Skript ausführen ... und fertig ist die build-Umgebung.

z.B. Kanotix/Sidux mit einem einfachen, Script geht super in Deiner VM
auch VM mit ISO-Boot-Image und union-fs sollte funktionieren, dann sollte sich
auch ein kleineres Grund-VM-Image realisieren lassen.

Gruss retabell

[yjogol]

So nun die neue Version (1.0.3)
Was ist neu?

Code: Alles auswählen

10.01.2007 (yjogol)
- added patches directory
- Rename ..MAKEDIR to .. LOCALSDIR
- added dboxfile directory
- added yb_version.txt
- added pre-download of yb_version.txt to look if there is a newer Version for cmd "upd"
- added checking if ccache is installed
- added comandline parameter for SDEBUG (Script debug) (yb_start 1)
- changed the way --with-rootpartitionsize="$ROOTPARTSIZE" is added to configure, check if value is set
- added DEBUG for cvs operation. If set, then all cvs operations are done with "-n -t" -n. dont change files, -t: trace what will be done
- added patch all files listet in patch/patches.txt
- added create diff from all against CVS

ACHTUNG die Variablennamen in der conf haben sich teils verändert.
Also per Menu nochmal anpassen.
Also ich habe die conf so vorbereitet wie der Ordnerstruktur-Vorschlag.

Ich denke am interessantesten von den Änderungen ist das Patchen.

Das geht so:
Im patch Ordner eine Datei patches.txt anlegen (siehe auch Beispiel in der yBuild.zip)
Für jede diff-Datei eine Zeile anlegen.
Form:
<pfad zum zu diffenden ordner>;<diff-datei>
Wenn ihr von .../tuxbox-cvs ein diff erstellt habt dann ist der Ordner <pfad zum zu diffenden ordner>="." D.h. die Pfadnangabe beginnt dort.
Anders gesagt <pfad zum zu diffenden ordner> ist die Pfadangabe ab tuxbox-cvs bis zu dem Ordner an dem das diff erstellt wurde.
Wie gesagt, die beiden beigelegten Beispiele werden es erklären.

Na ja und dann hab ich noch ein "create diff all" eingebaut.
Einfach "cd" im menu eingeben und dein ganzes lokales tuxbox-cvs wird gegen das aktuelle CVS gedifft und das diff nach patches/all.diff geschrieben.
Dann vergisst man auch nix.

Download über http://www.yjogol.de/download/yBuild.zip

yjogol

[det-box]

@yjogol

wo wird denn der Wert von "ROOTPARTSIZE" gespeichert??

Det

[det-box]

@yjogol

Bitte in der Datei "_yb_make.inc.sh"

Code: Alles auswählen

			0)
				cp -v $MyMAKEDIR/*local.sh $CVSDIR/cdk
				chmod -v u+x $CVSDIR/cdk/*local.sh
				echo "Ready .... press Enter"
				read dummy
				;;

ändern in

Code: Alles auswählen

0)
				cp -v $MyMAKEDIR/*local.sh $CVSDIR/cdk
				chmod -v u+x $CVSDIR/cdk/*local.sh
				cp -v $MyMAKEDIR/mkversion $CVSDIR/cdk
				chmod -v u+x $CVSDIR/cdk/mkversion
				echo "Ready .... press Enter"
				read dummy
				;;

Danke

Det

[StevenSch]

@yjogol

wo wird denn der Wert von "ROOTPARTSIZE" gespeichert??

Det

in der in der datei yb_globals.conf nicht vorhandenen Zeile:

# your RootPartitionSize
ROOTPARTSIZE=0x600000

Am besten direkt nach dem Block "relative Directories Definitions" einfügen

Steven

[yjogol]

@yjogol

wo wird denn der Wert von "ROOTPARTSIZE" gespeichert??

Det

Da ist ein Fehler drin. Kannst du in die conf direkt eintragen. Der Fehler ist nur da, wenn der Eintrag ROOTPARTSIZE=.. nicht vorhanden oder leer ist.
Update stelle ich gleich auf meine Site. dann per "upd" installieren.

@yjogol

Bitte in der Datei "_yb_make.inc.sh"

Code: Alles auswählen

			0)
				cp -v $MyMAKEDIR/*local.sh $CVSDIR/cdk
				chmod -v u+x $CVSDIR/cdk/*local.sh
				echo "Ready .... press Enter"
				read dummy
				;;

ändern in

Code: Alles auswählen

0)
				cp -v $MyMAKEDIR/*local.sh $CVSDIR/cdk
				chmod -v u+x $CVSDIR/cdk/*local.sh
				cp -v $MyMAKEDIR/mkversion $CVSDIR/cdk
				chmod -v u+x $CVSDIR/cdk/mkversion
				echo "Ready .... press Enter"
				read dummy
				;;

Danke

Det

Das hatte ich vergessen ganz rauszunehmen. da ja jetzt --with-customizationdir verwendet wird.

Oder wozu? mkversion?

EDIT: update ist da.

[Tommy]

@Yjogol: Das mit dem updaten habe ich erstmalig gemacht - genial

hast Du eigentlich das löschen der rcs irgendwo mit untergebracht (nach dem auschecken)?

[yjogol]

@Yjogol: Das mit dem updaten habe ich erstmalig gemacht - genial

hast Du eigentlich das löschen der rcs irgendwo mit untergebracht (nach dem auschecken)?

jup ist drin

[PT-1]

@Yjogol oder andere Scropt-Goetter,

koenntet ihr noch eine Zeile einbauen die dann am Ende die Images umbenennt (username) und mit dem Datum tituliert = 1x oder 2x.IMG

Irgendwie hatte ich das mal vor einer Weile sogar selber nach stundenlagem testen irgendwie hinbekommen und wie das so im leben ist, ist mir dann mein VM Ware gestorben und ich hatte natuerlich kein Backup...

PT-1

z.B. pt-1_11_01_07_13_04_2x.IMG

EDIT:

Ein Bekannter hat mir jetzt das hier vorgeschlagen:

d=`date +%d-%m-%Y_%Hh%M`
mv $flashprefix/neutrino-jffs2.img2x $flashprefix/`grep imagename $flashprefix/root-neutrino-jffs2/.version | sed -e 's/imagename=//'`-`grep version $flashprefix/root-neutrino-jffs2/.version | sed -e 's/version=//'`_x2_$d.img

[yjogol]

@Yjogol oder andere Scropt-Goetter,

koenntet ihr noch eine Zeile einbauen die dann am Ende die Images umbenennt (username) und mit dem Datum tituliert = 1x oder 2x.IMG

Irgendwie hatte ich das mal vor einer Weile sogar selber nach stundenlagem testen irgendwie hinbekommen und wie das so im leben ist, ist mir dann mein VM Ware gestorben und ich hatte natuerlich kein Backup...

PT-1

z.B. pt-1_11_01_07_13_04_2x.IMG

EDIT:

Ein Bekannter hat mir jetzt das hier vorgeschlagen:

d=`date +%d-%m-%Y_%Hh%M`
mv $flashprefix/neutrino-jffs2.img2x $flashprefix/`grep imagename $flashprefix/root-neutrino-jffs2/.version | sed -e 's/imagename=//'`-`grep version $flashprefix/root-neutrino-jffs2/.version | sed -e 's/version=//'`_x2_$d.img

Ja, das wird in den locals gemacht. Ich glaube auf Barf's Seite war hierfür ein Beispiel.

[det-box]

@yjogol

mkversion wird benötigt um in .version die VersionsNummer automatisch generieren zu lassen.
siehe Auszug von Barf's seite:

Code: Alles auswählen

Customizing die /.version file

Ihre eigene /.version-File herzustellen (gezeigt von Neutrino durch dBox -> Services -> Image-Version) ist sicher ein allgemeinee Wunsch. Hier ist die File, die ich momentan für dieses benutze:

#/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

Dieses File kann sowohl mit dem Namen flash-version-local.sh, sowie mit dem Name version-local.sh, für das Erstllen des /.version- File für Images beziehungsweise yadds benutzt werden. Merken Sie die Auswertung von $0 (die den tatsächlichen Namen enthält, unter dem der Script aufgerufen worden ist). Das benannte Script mkversion stellt die etwas kryptische Versionszeichenkette her und ist einfach eine "Verkapselung" davon. Es wird hier gezeigt:

#!/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

das mit der ROOTPARTSIZE war ein verungückter hinnweis , darauf das dieser eben nicht gespeichert wird. (mach ich beim nächsten mal besser)

Det

[StevenSch]

Kann man eigentlich "reverse" diffen?
Also ein diff welches vor dem configure gegen eine Datei im cvs angewendet wurde -mit dem selben diff- wieder rückgängig machen ? So könnte man nach dem Build das cvs bereinigen und es wäre wieder der original cvs stand. Das wiederum würde bedeuten keine Fehler mehr beim cvs update, hier würden geänderte Dateien ignoriert werden.

[det-box]

Hi,
zum Umbenennen ist dies vom Barf:

Code: Alles auswählen

##!/bin/sh
# neutrino-squashfs.img1x-local.sh
#
#
# neutrino-squashfs.img2x-local.sh isz ein Link auf 
# neutrino-squashfs.img1x-local.sh
# umbenennen und verschieben des fertigen Image's
#
flashprefix=$1
buildprefix=$2
ImageDir=$HOME/Image/woDas ImageHinnSoll

echo "============================================================================================"
echo Hello, this is $0, flashprefix=$1 and buildprefix=$2
echo "============================================================================================"
set -x

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="det-"$imagefilebase-`date --iso-8601`.$extension

echo Copying $flashprefix/$imagefile to $flashprefix/$newfilename...
cp $flashprefix/$imagefile $flashprefix/$newfilename

#echo move Image in Ziel Ordner
mv $flashprefix/$newfilename $ImageDir

Det

[yjogol]

Kann man eigentlich "reverse" diffen?
Also ein diff welches vor dem configure gegen eine Datei im cvs angewendet wurde -mit dem selben diff- wieder rückgängig machen ? So könnte man nach dem Build das cvs bereinigen und es wäre wieder der original cvs stand. Das wiederum würde bedeuten keine Fehler mehr beim cvs update, hier würden geänderte Dateien ignoriert werden.

Ich glaub, ich habs gefunden

Code: Alles auswählen

       o update [-ACdflPpR] [-I name] [-j rev [-j rev]] [-k kflag] [-r  tag|-D
         date] [-W spec] files...
       -C

         Overwrite locally modified files with clean copies from  the  reposi-
         tory (the modified file is saved in .#file.revision, however).

Also mit -C im update würdest du dein Problem lösen.
yjogol

[Tommy]

kann man eigentlich den download der hostapps (wie MCE Manager) unterbinden? Das Zeugs brauchen die wenigsten und es belegt ein Haufen Platz, ganz zu schweigen vom Download nach distclean.

[yjogol]

so, gab noch ein Fehler beim configure mit dem LOCALSDIR
Gibt eine Version 1.0.6

[Tommy]

ich dreh noch durch - der compiler steigt jedesmal beim uboot aus 1.1.4. Ich habe schon alles gelöscht und neu geupdated. Woran kann das liegen?

powerpc-tuxbox-linux-gnu-gcc -g -Os -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0x40000 -I/home/y/tuxbox/tuxbox-cvs/cdk/u-boot-1.1.4/include -fno-builtin -ffreestanding -nostdinc -isystem /home/y/tuxbox/dbox2/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_8xx -ffixed-r2 -ffixed-r29 -mstring -mcpu=860 -msoft-float -Wall -Wstrict-prototypes -c -o cmd_fs.o cmd_fs.c
cmd_fs.c:59:78: invalid suffix "x" on integer constant
cmd_fs.c:59: error: initializer element is not constant
cmd_fs.c:59: error: (near initialization for `part_info[1].size')
cmd_fs.c:59: error: initializer element is not constant
cmd_fs.c:59: error: (near initialization for `part_info[1]')

[det-box]

Thanx

Det

[yjogol]

Also hier noch eine weitere Idee zur Vereinfachung und Vereinheitlichung der Skripte.
Die local.sh Skripte sind ja so vorgesehen worden, dass jeder sie selbst anpassen kann und soll.
Wenn man die vielen Fragen im Forum sich anschaut, scheint dies aber auch nicht all zu klar zu sein.

Vorschlag: für die Nutzung mit yBuild könnte man Standard-Skripte schreiben. Die Wiederum aus dem Menu übernommene Einstellungen realisieren.

Wenn man sich z.B. folgendes Skripts anschaut:

Code: Alles auswählen

#!/bin/sh
#==============================================================================
# root-local.sh
# will be executed before libary reduction
#==============================================================================

#------------------------------------------------------------------------------
# Get yBuild pathes and variables
#------------------------------------------------------------------------------
yb_home=$HOME/tuxbox/yBuild
. $yb_home/yb_globals.conf
. $yb_home/include/_yb_library.inc.sh
init_variables

#------------------------------------------------------------------------------
# init specific pathes and variables
#------------------------------------------------------------------------------
flashprefix=$1
buildprefix=$2
myfiles=$MYFILESDIR
newvar=$flashprefix/root
cdkroot=$DBOX_PREFIX/cdkroot

#------------------------------------------------------------------------------
# lets start
#------------------------------------------------------------------------------
echo "================================================================================"
echo "LOCAL: $0"
echo "flashprefix=$1 and buildprefix=$2"
echo "================================================================================"
#show_variables
set -x

#------------------------------------------------------------------------------
# my make targets
#------------------------------------------------------------------------------
#make flash-automount
make dvb_tools
make flash-dboxshot
make flash-fbshot
make flash-fcp

#------------------------------------------------------------------------------
# move files to take attention while stripping libs
#------------------------------------------------------------------------------
cp -r $myfiles/lib/* $newvar/lib

#---------------------------------------------------------------------------------
echo "================================================================================"
echo "END LOCAL: $0"
echo "================================================================================"

könnte man den Block

Code: Alles auswählen

#------------------------------------------------------------------------------
# my make targets
#------------------------------------------------------------------------------
#make flash-automount
make dvb_tools
make flash-dboxshot
make flash-fbshot
make flash-fcp

aus yBuild Einstellungen genereien.

Oder anderes Beispiel

Code: Alles auswählen

#!/bin/sh
#==============================================================================
# root-neutrino-jffs2-local.sh
#==============================================================================

#------------------------------------------------------------------------------
# Get yBuild pathes and variables
#------------------------------------------------------------------------------
yb_home=$HOME/tuxbox/yBuild
. $yb_home/yb_globals.conf
. $yb_home/include/_yb_library.inc.sh
init_variables

#------------------------------------------------------------------------------
# init specific pathes and variables
#------------------------------------------------------------------------------
flashprefix=$1
buildprefix=$2
myfiles=$MYFILESDIR
cdkroot=$DBOX_PREFIX/cdkroot
actual_local_dir=$flashprefix/root-neutrino-jffs2

#------------------------------------------------------------------------------
# lets start
#------------------------------------------------------------------------------
echo "================================================================================"
echo "START LOCAL: $0"
echo "flashprefix=$1 and buildprefix=$2"
echo "================================================================================"
#show_variables
#set -x

#------------------------------------------------------------------------------
install -d $actual_local_dir/hdd	# hdd mount dir

#------------------------------------------------------------------------------
# copy my own files
#------------------------------------------------------------------------------
echo "copying own files"
cp -r -v $myfiles/var/* $actual_local_dir/var
cp -r -v $myfiles/etc/* $actual_local_dir/etc
cp -r -v $myfiles/lib/* $actual_local_dir/lib

#---------------------------------------------------------------------------------
# include script to delete files
#---------------------------------------------------------------------------------
if [ -e $MyLOCALSDIR/my-delete-files.inc ]; then
. $MyLOCALSDIR/my-delete-files.inc
fi

#---------------------------------------------------------------------------------
# Remove not needed Plugins
#---------------------------------------------------------------------------------
PLUGINS="tuxcom" #customize here
echo "removing: plugins, games execpt: $PLUGINS"
#set -x
for f in $actual_local_dir/lib/tuxbox/plugins/*.cfg; do
	_plugin=`basename $f .cfg`
	(echo $PLUGINS | grep -v $_plugin) && rm -f $actual_local_dir/lib/tuxbox/plugins/$_plugin.*
done

#---------------------------------------------------------------------------------
# Remove not needed Language files
#---------------------------------------------------------------------------------
LANGUAGES="deutsch" #customize here
echo "removing: not needed language files execpt: $LANGUAGES"
for f in $actual_local_dir/share/tuxbox/neutrino/locale/*; do
    (echo $LANGUAGES | grep -v `basename $f .locale` >/dev/null) && rm -f $f
done

#---------------------------------------------------------------------------------
echo "================================================================================"
echo "END LOCAL: $0"
echo "================================================================================"

Hier habe ich z.B. ein customizing Datei my-delete-files.inc eingebaut
Mann könnte auch die Variablen LANGUAGES und PLUGINS über das Menü setzen.
Was meint ihr?

yjogol

[StevenSch]

Das könnte man grundsätzlich so machen, nur dürfen die Scripte ausschließlich als Beispiele in examples vorliegen und auch nur dort von Dir bei versionsbedingten Änderungen im Dateigerüst angepasst werden.

Ich meine einfach ausgedrückt: Ein Update dürfte nie direkt nach /locales/entpacken sonst überschreibt man sich ja seine auf sich angepassten Scripte.

[yjogol]

Das könnte man grundsätzlich so machen, nur dürfen die Scripte ausschließlich als Beispiele in examples vorliegen und auch nur dort von Dir bei versionsbedingten Änderungen im Dateigerüst angepasst werden.

Ich meine einfach ausgedrückt: Ein Update dürfte nie direkt nach /locales/entpacken sonst überschreibt man sich ja seine auf sich angepassten Scripte.

Jup, so hatte ich das gedacht.
Schon mal das patchen ausprobiert. Mir war garnicht klar, das ich das selbst dringend brauchte.