new flashrules barf beispiel

[dietmarw]

hier mal ein beispiel für diejenigen die mal testen wollen..

ist nur ein schnell zusammen kopierter teil aus meinem build script..
(also nicht wundern über die evtl. doppelte symlink erstellung )

#! /bin/bash

# - anpassen ------------------------------------------------------------------------------------------------

USERDIR="username"

# - anpassung nicht unbedingt nötig (verzeichnisse sollten schon da sein ) ------------------------------------------------------------
LOGODIR=/home/$USERDIR/Logos
CP=/home/$USERDIR/tuxbox-cvs
DB=/home/$USERDIR/dbox2
ARCHIVEDIR=/home/$USERDIR/Archive

export CVS_RSH=ssh

# -----------------------------------------------------------------------------------------------------------

cd "$CP"

cvs -d anoncvs@cvs.tuxbox-cvs.sourceforge.net:/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 --with-checkImage=rename --with-logosdir="$LOGODIR"

make flash-neutrino-all-all
#make flash-all-all-all
#make everything

edit: checkout string editiert und date entfernt

edit2:
feedback von cvs nutzern.. ..weitere sollten folgen, hab div. angeschrieben

- ...eine sinnvolle Überarbeitung des Makegeraffels halte ich aber für sehr angebracht... ...Ggf. den bisherigen Stand als "oldmake" taggen...
- ...wenn die Proteste nicht begruendet waren, rein damit ins cvs...
- ...wegen mir nur rein damit, ich fand die Lösung mit den "Markern" schon immer daneben...
- ...Also ich habe nix dagegen, das das eingecheckt wird... ...Falls die "new flashrules" auch die Dreambox betreffen, solltest du dich wohl vor allem mit Ghost/tmbinc kurzschliessen...
- ...Ich werden bald auf barf's make umstellen...
- ...kann wegen mir default werden...
- ...frischer Wind und neue Ideen sind immer gut...
- ...ich bau keine flashfiles, von daher ist es _mir_ relativ egal, solange es weiter baut...
- ...stimme ich auch dafür, dass es in den Standard Zweig übernommen wird...
- ...sind die neuen Regeln ein wirklicher Fortschritt...
- ...Ich würde dann umsteigen, wenn dies mit geringem Zeitaufwand möglich wäre... was es jetzt scheinbar war

[DieMade]

Ich habs mal als "Wichtig" markiert, damit der Beitrag oben bleibt.

[wolgade]

cvs -d anoncvs@82.149.243.100:/cvs/tuxbox -z3 co "$CVSDATE" .
cvs -d anoncvs@82.149.243.100:/cvs/tuxbox -z3 up -r newmake cdk/root/etc/Makefile.am cdk/Makefile.am cdk/configure.ac cdk/acinclude.m4 cdk/doc cdk/Patches/busybox.config.m4 cdk/Patches/dbox2-flash.c.m4 cdk/root/Makefile.am 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 apps/tuxbox/plugins/configure.ac apps/tuxbox/tools/configure.ac apps/tuxbox/tools/misc/Makefile.am

scheint nicht mehr zu funktionieren, da Barf ein paar Tags geändert hat.

cvs -d anoncvs@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox -z3 co -f -r newmake -P .

funktioniert stattdessen.

[DieMade]

Bugs bitte hier posten/bearbeiten: http://forum.tuxbox-cvs.sourceforge.net ... hp?t=40324

[Barf]

Ein Paar Bemerkungen:

1. Das funktioniert/nicht funktioniert im Poll finde ich etwas unglücklich. Die meine Meinung nach relevante Frage ist: "Zukunftsträchtiger, gesunder Weg weiterzuarbeiten?", eher als genau weilche Bugs es z.Z. gibt. Ich habe selbst Angst für "Tests" wie: "Ich habe probiert Linux zu installieren, hat nicht mein USB-Maus erkannt. Was für ein Müll!". Es ist auch z.B. leicht, (z.B.) durch fehlerhaftives oder missgelungenes Auschecken zu "funktoniert nicht" zu kommen.

2. Es ist mehr als die Flashtargets, was newmake von HEAD unterscheidet. Insbesonderes das mann nicht separat für YADD und Images konfigurieren muss, sondern kann alles in einem Rutsch builden. In HEAD wird sogar dek Compiler neu gebaut, falls mann von YADD-Herstellung zu Imageherstellung umstellen muss...


3. @gm018t: Kuck die Kompatibilitätstargets in backwards_compat.mk an.

1) Dokumentation u.A. "welches Target macht was" ? und nicht nur
"wie komme ich zu welchem Imagetyp" !

Beschränkte Zustimmung. Auch wenn Make es nicht direkt unterstützt, glaube ich in Trennung zwischen "private" und "öffentliche" Targets (vgl. OO).

[Bacwolf]

Dank deiner "vereinfachten" Flash-Rules konnte ich auch endlich mal erfolgreich ein enigma-2x Image bauen; meiner Meinung nach also der "richtige Weg"

Eine Frage nur noch; wurde glaub ich auch schonmal gestellt - wie ist es möglich vor Imageerstellung eigene Files in das root zu kopieren bzw. welche zu ändern?
Würde z.B. gern die Busybox nachträglich um ein paar funktionen erweitern, allerdings gibts für make busybox keine Regel

Sorry für etwas Unwissenheit, beim Dreambox-CVS ist das etwas einfacher...

[Barf]

wie ist es möglich vor Imageerstellung eigene Files in das root zu kopieren bzw. welche zu ändern?

Ich habe gerade ein Artikelchen darüber geschrieben. War längst überfällig (hallo dietmarw!) Ich hoffe (und glaube) dies deine Frage beantwortet.

Würde z.B. gern die Busybox nachträglich um ein paar funktionen erweitern, allerdings gibts für make busybox keine Regel

Die Targets heissen in der CVS-eingecheckte Version $(flashprefix)/bin/busybox bzw $(targetprefix)bin/busybox. In einer Version, die ich noch nicht eingecheckt hat, geht auch busybox und flash-busybox. Übrigens wird Änderungen in busyboxkonfiguration in Patches/busybox.config[.m4] gemacht; dies hat nichts mit Makefiles zu tun.

Sorry für etwas Unwissenheit, beim Dreambox-CVS ist das etwas einfacher...

Durchaus möglich. Die Dreamboxler arbeiten ja seit längere Zeit völlig für sich selber, checkt ein ausschliesslich in ihre einen Branch, nimmt kaum teil in der Diskussion in diesem Forum. Z.B. gab es bis neulich in rcS diverse total veraltete Dreamboxzeugs.

[dietmarw]

CUSTOMIZATION

The built images and yadds can be customized without changing the
Makefiles. For this, many of the major targets calls a customization
script, if present and executable. The name of the customization script is taken as
the non-directory part of the rule, with "-local.sh" appended. The script is
supposed to reside in the cdk directory, and is given two
arguments: For image targets these are $(flashprefix) and $(buildprefix)
(expanded); for yadd-targets these are $(targetprefix) and
$(buildprefix) (expanded).

Example:

In an image, it is desired to:

1. Use own ucodes,
2. Use own boot logos,
3. Use own /etc/hosts
4. Use own neutrino.conf, bouquets.xml, services.xml
5. Include the lirc component, together with own lirc configuration files.

For this: 1. and 2. are better with the --with-ucodesdir and
--with-logosdir options to configure. 3. and 5. are extensions that
should be to $(flashprefix)/root, while 4., being a Neutrino-fix,
should be to $(flashprefix)/root-neutrino-jffs2,
$(flashprefix)/root-neutrino-cramfs, and/or
$(flashprefix)/root-neutrino-squashfs. To achieve 3. and 5. we write
the script root-local.sh, say:

Code:

#!/bin/sh

flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root
myfiles=/home/somewhere/dbox/myfiles

cp -f $myfiles/etc/hosts $newroot/etc
make $flashprefix/root/sbin/lircd
cp -fr $myfiles/var/tuxbox/config/lirc $newroot/var/tuxbox/config

The script for 4., say root-neutrino-jffs2-local.sh, is entirely similar:

Code:

#!/bin/sh

flashprefix=$1
buildprefix=$2
newroot=$flashprefix/root-neutrino-jffs2
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

NOTE: These scripts are intended to serve as examples, and can probably not
be used without modification.

@barf

möglich wären also:

root-local.sh
root-cramfs-local.sh
root-enigma-cramfs-local.sh
root-enigma-cramfs-p-local.sh
root-enigma-jffs2-local.sh
root-enigma-jffs2-p-local.sh
root-enigma-squashfs-local.sh
root-enigma-squashfs-p-local.sh
root-jffs2-local.sh
root-neutrino-cramfs-local.sh
root-neutrino-cramfs-p-local.sh
root-neutrino-jffs2-local.sh
root-neutrino-jffs2-p-local.sh
root-neutrino-squashfs-local.sh
root-neutrino-squashfs-p-local.sh
root-squashfs-local.sh
var-enigma-local.sh
var-neutrino-local.sh

wobei für mich immer noch unklar ist wo der unterschied der -p teile ist??

[Barf]

... sowie die Yadd-targets yadd-neutrino, yadd-enigma, yadd-lcars, yadd-all, yadd-micro-neutrino. Wobei diese Liste nicht in Blei gegossen ist, grundsätzlich können alle Targets in Makefile.am mit der Zeile @TUXBOX_YADD_CUSTOMIZE@ bzw. @TUXBOX_CUSTOMIZE@ versehen werden.

Aus den -p Verzeichnisse (z.B. root-neutrino-cramfs-p) werden die ganz flashfertige ohne-p-Verzeichnisse gemacht. (Denke an "p" für "prepare".) Dadurch (bei cramfs und squashfs) wird ein var-Verzeichniss erzeugt und die root-verzeichniss wird read-only-tauchlich gemacht (links von /etc nach /var/etc etc).

[dietmarw]

fazit:

-die reaktionen waren in großer mehrheit positiv,
-die drei abstimmer mit "funktioniert nicht" und "pauschal dagegen" haben nicht wirklich begründet was nicht laufen soll, bzw was dagegen spricht.
-vom yadi team hatte ich nur mogway angeschrieben, da nur er in der letzten zeit im cvs aktiv war, aber er hat seine pn bisher nicht gelesen.
-JtG-Riker hat bisher scheinbar getestet aber keine größeren probleme gehabt?


also scheint nicht wirklich etwas dagegen zu sprechen den bisherigen stand als "oldmake" zu taggen und "newmake" in den head zu mergen?

[Nico 77]

Ich sehe keinen Bedarf newmake zum Standart zu machen nur weil ein paar Forenuser und Imagebauer hier der Meinung sind.
Zudem waren die Reaktionen nur der User die mitgemacht und voreingenommen positiv dafür waren auch dafür.
Die klägliche Abstimmung beweißt das nicht wirklich Interesse daran besteht.
Was das gegeben hat, hat man am sectionsd im CVS gesehen wo man sich jegliche lauffähigkeiten im Forum raussuchen muss, also sollte man das hier lassen wie es ist.
Zudem Kritiker hier eh kaum noch schreiben weil diese niedergemacht werden bevor Kritik angenommen wird.
In dem eigenen Branch ist das sehr gut aufgehoben, so kann jeder weiterhin seinen Standart nutzen.

[dietmarw]

...nur weil ein paar Forenuser und Imagebauer hier der Meinung sind...

es sind eher der großteil der aktiven cvs mitarbeiter der letzten 3 monate
siehe feedback oben..

[JtG-Riker]

fazit:

-die reaktionen waren in großer mehrheit positiv,
-die drei abstimmer mit "funktioniert nicht" und "pauschal dagegen" haben nicht wirklich begründet was nicht laufen soll, bzw was dagegen spricht.
-vom yadi team hatte ich nur mogway angeschrieben, da nur er in der letzten zeit im cvs aktiv war, aber er hat seine pn bisher nicht gelesen.
-JtG-Riker hat bisher scheinbar getestet aber keine größeren probleme gehabt?


also scheint nicht wirklich etwas dagegen zu sprechen den bisherigen stand als "oldmake" zu taggen und "newmake" in den head zu mergen?

Also ich hab zwar getestet bin aber noch nicht zufrieden, weil noch einge Sachen sind die noch nicht so recht laufen, ich kann z.B. als Imagebauer nicht mal eben einfach ein Update machen, da werden immer Kernel, Busybox,U-Boot usw neu gebaut, das find ich so nicht okay, denn ich brauch für mein Update das alles nicht, weiterhin kann man seine anpassungen nicht einfach mal testen, eben weil einiges neugebaut wird.

Ich erstelle nur alle paar Monate mal ein Komplett-Image, es gibt nun keine rule mehr die nur ein update erstellt...

Das find ich in den jetzigen rules besser, gut man muss selber gucken was eingecheckt wurde, aber ich mach jetzt nur z.B " rm .deps/neutrino && make neutrino && make rebuild flash und das dauert paar sekunden und ich hab ein neues cdkflash und rufe mksquashfs auf und dann hab ich nen neuen Snapshot, bei den neue rules dauert das ~4 5 Minuten und man sieht nicht was neu ist weil das alles undurchsichtig ist.



Dann sollte man auch noch die Yadi Leute fragen, immerhin sind die auch " offizielle" Imagebauer

[dietmarw]

...Dann sollte man auch noch die Yadi Leute fragen, immerhin sind die auch " offizielle" Imagebauer

leider hat sich das yadi team seit anfang der sache (div. monate) scheinbar überhaupt nicht damit befasst..
auf jeden fall kam keine reaktion die eine befassung mit dem thema vermuten ließ..

[Metallica]

nicht getestet, aber wenns läuft kann es standard werden

Ich habe so abgestimmt:
Ich habe mit nicht getestet, aber wenns läuft soll es standard werden.

[racker]

Kaum ist man 3 Tage nicht da ...

fazit:

-die reaktionen waren in großer mehrheit positiv,
-die drei abstimmer mit "funktioniert nicht" und "pauschal dagegen" haben nicht wirklich begründet was nicht laufen soll, bzw was dagegen spricht.
-vom yadi team hatte ich nur mogway angeschrieben, da nur er in der letzten zeit im cvs aktiv war, aber er hat seine pn bisher nicht gelesen.
-JtG-Riker hat bisher scheinbar getestet aber keine größeren probleme gehabt?


also scheint nicht wirklich etwas dagegen zu sprechen den bisherigen stand als "oldmake" zu taggen und "newmake" in den head zu mergen?

Solange kein "Feature freeze" stattgefunden hat, macht es keinen Sinn ein Fazit zu ziehen. ;-)
Das ganze sollte schon getestet sein, oder?
Im Moment habe ich sowieso das Gefühl, dass das Cross Development Kit zu einem Cross Distribution Kit verkommt.
Z.B. die Regeln für Kernel 2.6 fehlen noch, stattdessen wird das Imagebauen immer mehr verfeinert.

[Barf]

Mann wird ja deprimiert wenn mann einige "Beiträge" hier lesen. Warum strengen sich Leute an wenn sowieso alles perfekt ist? Ich glaube ich kann besseres mit meinem Kreativität machen, als in so ein Diskussion teilzunehmen. Irgendwie kommen die gleicht Themen immer wieder hoch in diesem Forum...

EInige Sachfragen sollte ich aber beantworten:

da werden immer Kernel, Busybox,U-Boot usw neu gebaut

Erstmals, die Kernaussage hier ist "ineffizienz", und hat, in Unterschied zu einige andere Beiträge, Substanz. Die Kritik ist, am mindestens teilweise, richtig. Zu diesem Thema habe ich heute substantielle Verbesserungen eingechekct (siehe den "Flashrules ... umgeschreiben" thread), und ich bin nicht sicher falls du zum gleichen Standpunkt heute kommen wurde. Das Problem mit unnötige Rebuilds von Kernel etc ist gelöst. Problem mit unnötiges Builden von u-boot bestand nie. Noch ist sicherlich nicht alles perfekt.

Ein Buildprozess soll viele Forderung erfüllen. Korrektheit, Pflegbarkeit, gute "Programmiersitten", Customizationmöglichkeit, Durchgänglichkeit, Benutzerfreundlichkeit sowohl für Experten als auch für einfache Benutzer, Dokumentation etc, sowie, natürlich auch Effizienz (Zeit und Plattenplatz). Für mich kommt Effizient nicht auf Prio #1.

Der HEAD-Prozeß verletzt fast alle Regeln für vernünfige Software. Trotzdem bevorziest du ihn. Wegen Effizienz...

Ich bin auch nicht sicher was du mit "Update" meinst. Update images sind da, z.B root-neutrino.squashfs.

Nochmals, probiere die heutige Version.

Meine Meinung zu YADI habe ich in andere Posts erklärt..

Zum Thema Branching, von einige hier hoch gelobt. Bitte lese DieMades beitrag. Branches sind wie friends in C++: eine problematische und unschöne Sache, nur da wenn alle Alternative noch schlecter sind. Zu glauben, dass Entwickler sich auf Dauer motivieren kann, parallele Branches zu unterhalten ist naiv.

[JtG-Riker]

@Barf

Wollte dich nicht ermutigen, denke die Sache geht in die richtige Richtung.

Mit den Updates hab ich doch geschrieben was ich meinte, es gibt (gab ? ) z.Zt keine regeln die einfach nur /cdkflash/root baut ohne die u-boot und Kernel geschichte, da du aber ja einiges geändert hast muss ich erst wieder testen.

Denke man bekommt das schon hin.

Riker

[StevenSch]

Eigentlich muss ich sagen schlagen bei diesem Thema 2 Herzen in meiner Brust:

1.) Ich bin dafür Barf's make-rules als Standart einzuchecken, denn sie kommen dem Anspruch das "das Image bauen können" nicht nur einem kleinen elitären Kreis vorbehalten bleibt näher als die derzeitigen.
Viele trauen sich bisher nicht an das Thema ran weil sie die Theorie die vor dem praktischen Ergebnis, sprich image, steht abschreckt und jeder auch hier im Board erklärt den Weg dahin ein wenig anders.

2.) Die "alten" Rules müssen bleiben, denn sie hatten - einen von JtG-Riker schon erwähnten - großen Pluspunkt: Ein schnelles Rebuild bei kleinen Änderungen im CVS oder kleinen eigenen Anpassungen. Hier geht es hauptsächlich um das ständige Neukompilieren der gcc und glibc. Die beiden laufen bei mir immer ca 1 Stunde und immer so lange warten um eine kleine Änderung zu testen ist unverhältnismäßig.

Steven

[Barf]

Ein schnelles Rebuild bei kleinen Änderungen im CVS oder kleinen eigenen Anpassungen. Hier geht es hauptsächlich um das ständige Neukompilieren der gcc und glibc. Die beiden laufen bei mir immer ca 1 Stunde und immer so lange warten um eine kleine Änderung zu testen ist unverhältnismäßig.

WIE kommst du zu so ein bizarren, und, Gott sei Dank, völlig fehlerhaftige Behauptung?? Bitte die Behauptung beweisen.

Worüber JtG-Riker gesprochen hat, ist unnötige Unkompilierungen von z.B. Kernel. Dies ist erstmals (am mindestens hauptsächlich) behoben, zweitens ein Problem was ein Paar minuten kostete, nicht Stunden! Deine Behauptung hat er niemals gemacht.

Die Wahrheit ist eigentlich ganz Anderes: Mit dem HEAD-Buildprozess merkt make nicht dass bei z.B cvs update etwas sich geändert hat. Einzige Methode sicher zu sein, dass alles erforderliches neu compiliert wird, ist make distclean. DAS dauert Stunden!

[StevenSch]

WIE kommst du zu so ein bizarren, und, Gott sei Dank, völlig fehlerhaftige Behauptung??

Also glibc und gcc bauen dauert bei mir nun mal je 30-35min.

Das ändert natürlich nichts daran, das ich scheinbar einige Grundlagen nicht verstanden habe.
Ich dachte bisher das bei jedem Neustart des Prozesses eine Art make distclean läuft und danach alles neu gebaut wird. Da dies aber nachweislich falsch ist, ziehe ich meine vorherigen aussagen zurück und behaupte das Gegenteil. Sorry.

[Tommy]

Hab mal im eigentlichen Sinne des Threads gevoted (1)

Begründung:
Die Erstellung von Images wird erleichtert vor allem in Bezug auf eigene Anpassungen. Ich bin erst ganz am Anfang und habe mit Sicherheit noch nicht alle Möglichkeiten für mich erschlossen. Trotzdem bin ich sicher das Barf auf dem richtigen Weg ist. Außerdem gibts für "newmake" (noch)guten Support

[just_me]

# - anpassen ------------------------------------------------------------------------------------------------
USERDIR="username"

ginge hier nicht auch

Code: Alles auswählen

USERDIR=`whoami`

oder

Code: Alles auswählen

USERDIR=$USER

damit das Editieren entfallen kann?

Ein bisschen unschön ist, dass über das Batchfile mehrere Verzeichnisse im Homeverzeichnis des Users angelegt werden. Dadurch lässt sich z.B. die Entwicklungsumgebung nicht einfach in ein tar verpacken und auf einen anderen Rechner transferieren. Ist ein absoluter Pfad wirklich nötig?

[Tommy]

ich hab nur 2 Verzeichnisse im homedir. Das ist einmal dbox (wo die Endprodukte landen) und tuxbox-cvs. Ist doch ok so?!

echo $User bringt bei mir unter ubuntu nix

[just_me]

ich hab nur 2 Verzeichnisse im homedir. Das ist einmal dbox (wo die Endprodukte landen) und tuxbox-cvs. Ist doch ok so?!

Vielleicht liegt der Fehler bei mir, hier entstehen noch:
Archive, apps, CVS, hostapps, driver, CVSROOT, boot, cdk

echo $User bringt bei mir unter ubuntu nix

Mit Grossschreibung sollte es gehen, $HOME oder `pwd` wäre wohl auch 'ne Möglichkeit (aber warum überhaupt ein absoluter Pfad?).