newmake vs head an alle Dev`s

[petb]

Hallo,

barf, sei mir bitte nicht böse.
Ich fand es klasse z.B. bzgl. des "Switch" auf deiner Seite mehr Infos zu bekommen. Auch wenns in English ist.
Aber fürs Image erstellen finde ich es im Moment nicht gut.

"ich" muss immer wieder nach bestimmten Worten suchen und verstehe den Sinn eben manchmal nicht.
Beim alten Kram fand ich jede Menge Infos auf Deutch und konnte immerhin mein Image bauen.
Beim neuen hagelt es immer wieder mal irgend ne Fehlermeldung.
Aber das sollte jetzt nicht der Punkt sein, wie gut oder nicht gut "ich" damit klarkomme.

Ich meine nur, es gibt bestimmt viele, die allein am English scheitern.
Und wenn dann noch Rules und was man sonst noch kennen sollte nicht vollständig aufgeführt sind, wird es eben noch schwerer.
Auch wenn das Ziel eigentlich eine Vereinfachung sein soll.

"Mir" ist nicht damit geholfen wenn ich ein einfaches Image bauen kann.
Mir fehlt z.B. Info, wie kann ich eigene Dateien reinbringen, das ganze als yadd nutzen usw. (Ich weis, einiges wurde schon erklärt.)

Was ich meine ist, es fehlt eine Anleitung Round about auf deutsch, die auch Image DEV es zufriedenstellt.

Ich hoffe das ist nicht zu viel verlangt ?

Danke
bye
PetB

[ed_2]

Hi,

so wollte mal wider nachfragen wie der Stand ist was wird jetzt Standart Head oder Newmake???

@JtG-Riker

bist du jetzt mit newmake klar gekommen konntest du die Sachen die dich Stören eleminieren??

@Tommy

Wie sieht es bei dir aus bist du noch dran den Artikel von Barf zu übersetzen??? Die Temperaturen sind ja noch nicht so gestiegen

@all dev`s

Wie sieht es aus keiner Intresse an diesem Thema oder ist es egal ob head oder newmake oder arbeiten schon alle entwickler zweigleisig für head und newmake oder wie ??????


Mfg

ed_2

[Tommy]

@ed_2: Antreiber

[Bimmel]

Nachdem 'alle' gegen Newmake sind , bleib uns wohl head erhalten.
Man darf doch nicht so leicht ein Image bauen können.

[Houdini]

du kannst dir doch dein newmake auschecken, wo ist das Problem?

[dietmarw]

Nachdem 'alle' gegen Newmake sind...

die mehrzahl der aktiven dev es hat sich eher dafür ausgesprochen..

http://forum.tuxbox-cvs.sourceforge.net ... highlight=

yadi hat sich gar nicht geäußert..
jtg sträubt sich noch ein wenig..

[ed_2]

Hi,

dann bitte ich doch mal das YADI TEAM um eine stellungnahme würde mich auch sehr interessieren.
Sonst habe ich auch immer mit yadi kompieliert jetzt habe ich alles was ich sonst im yadi hatte auch ins newmake eingebaut.

Was meint denn das YADI TEAM dazu???

Bitte freundlich um eine stellungnahme.

Mfg

ed_2

[dietmarw]

Was meint denn das YADI TEAM dazu???

Bitte freundlich um eine stellungnahme.

das hab ich schon vor monaten..

[Bimmel]

du kannst dir doch dein newmake auschecken, wo ist das Problem?

Ja , jetzt geht das , aber was wird nach 6.7.8.... monaten ?
Glaube kaum , dass Barf es weiter pflegen wird , nach dem Motto 'Ich bin dabei' und kernel2.6.x soll auch mal kommen.

[ALexH]

Wie soll man eigentlich Skript-gesteuert erkennen können, ob beispielsweise flash-neutrino erfolgreich durchcompiliert hat? Bisher wurde immer getestet, ob

Code: Alles auswählen

$DBOX/cdkflash/.part_neutrino

existiert, das wird jetzt aber nicht mehr angelegt, wenn flash-neutrino erfolgreich fertig gebaut hat.

Viele Grüße
AlexH

[Barf]

Wie soll man eigentlich Skript-gesteuert erkennen können, ob beispielsweise flash-neutrino erfolgreich durchcompiliert hat?

Bitte sehe es nicht abwertend, aber "oldmakers" ticken einfach anderes. Normalerweise "kontrolliert" mann nicht falls etwas durchgelaufen ist, mann gibt "etwas" als prerequisite für ein Target an. Damit übernimmt make die Verantwortung. Auch das mehrfache "make target" ist möglich, da ein vernünftige Maketarget idempotent sein soll. (Hier hat "HEAD make" seine Schwächen.)

Natürlich kann mann ja kontrollieren falls $(flashprefix)/root-neutrino oder $(flashprefix)/root-neutrino/bin/neutrino existiert...

[ALexH]

Damit übernimmt make die Verantwortung

Wenn make die Verantwortung dafür übernimmt, daß alles erfolgreich compiliert, dann solls mir recht sein

Aber wäre es denn nicht beispielsweise denkbar, daß man einfach einen touch am Ende solch einer rule einbaut, um Skript-gesteuert irgendwelche Fehler zu erkennen?
Bringt ja irgendwie nichts, wenn man den Rest weiterbauen lässt und erst beim Hochladen auf die Box erkennt, daß das eigentlich gar nicht funktioniert.

Sucht man im Skript nach einer bestimmten Datei oder einem Verzeichnis, welche(s) zum Schluss erstellt wird, so geht das so lange gut, bis am Makefile was gebastelt wird. Und immer wieder die Skripte anzupassen ist einfach nicht machbar.

[Barf]

Aber wäre es denn nicht beispielsweise denkbar, daß man einfach einen touch am Ende solch einer rule einbaut, um Skript-gesteuert irgendwelche Fehler zu erkennen?

Wenn make an ein Fehler stoßt wird der Makelauf unterbrochen. Das merkst du falls du es willst oder nicht. Du musst dich nicht besonderes anstrengen um "irgendwelche Fehler zu erkennen". Was ist das Problem?

Bringt ja irgendwie nichts, wenn man den Rest weiterbauen lässt und erst beim Hochladen auf die Box erkennt, daß das eigentlich gar nicht funktioniert.

Make weiterbaut nicht nach Fehlern. Bei der -k-Option wird es weitergebaut, aber nur am Targets die nicht vom Fehler betroffen sind. Am höchstens falls du dich anstrengt, make zu "zweckentfremden", und, z.B. mit diverse schmutzige Tricks für make zu "lügen".

Sucht man im Skript nach einer bestimmten Datei oder einem Verzeichnis, welche(s) zum Schluss erstellt wird, so geht das so lange gut, bis am Makefile was gebastelt wird. Und immer wieder die Skripte anzupassen ist einfach nicht machbar.

Hier verstehe ich nicht richtig was du sagen willst. Meinst du möglicherweise "Makefile[.am]" wenn du "Skript" sagst? In einem reifen umgebung wird es nicht ständig rumgefummelt. Falls es trotzdem der Fall ist, ist die richtige Lösung dass die Targets vom Makefile abhängt -- so mache ich es tatsächlich bei einige kleinere Projekte.

[Tommy]

wie wurde den bisher die Überprüfung vorgenommen? Also wenn bei newmake ein Fehler auftritt hört es auf zu bauen an der stelle. (hatte ich schon mehrmals durch eigene dumme Fehler) im cdk-flash befinden sich dann keine images die fehlerhaft seien können. Auf "bad magics" kann auch geprüft werden.
Ich mache fast jeden Tag einen Durchlauf um für mich das Puzzle zum (für mich) perfekten Image fortzusetzen. Es ist grundsätzlich so, das wenn Images/ root partition erstellt worden diese auch laufen.

[Barf]

@ALexH: Ich möchte gerne diesen alten Beitrag empfehlen (auch wenn in einige Punken veraltet), wo ich versuche einigermasse pedagogisch zu erklären, warum "oldmake" eine "Zweckentremdung" von make ist.

Bitte entschuldigt mich auch falls ich gelegentlich etwas polemisch klinge.

[ALexH]

wie wurde den bisher die Überprüfung vorgenommen?

Vereinfacht ausgedrückt folgendermaßen: Bisher wurde, nach dem beispielsweise durch das Skript "make flash-neutrino" aufgerufen wurde getestet, ob im cdkflash-Verzeichnis die Datei ".part_neutrino" existiert. Diese wurde nämlich dann angelegt, falls die make-rule komplett abgearbeitet werden konnte.

Stößt make auf einen Fehler wird zwar in diesem Fall neutrino nicht komplett gebaut. Dem Skript macht dies, falls es nicht irgendwie automatisiert erkennbar ist, gar nichts. Es führt einfach make flash-enigma aus. Anschließend wird über das Skript manuell einfach das Image erzeugt (ohne make-rule). Kopiert man dies auf die Box, so bootet diese trotzdem, es fehlt halt in diesem Fall ein lauffähiges Neutrino. Dies wäre vor allem bei Neutrino-only-Images etwas ärgerlich.

Ich möchte gerne diesen alten Beitrag empfehlen

Werde ich mir mal bei einer ruhigen Minute zu Gemüte führen, kann aber noch ne Weile dauern.

[wolgade]

Zum einen brauchst du kein Skript mehr, sondern nur noch make. Wenn make ohne Fehlermeldung beendet wird, dann hat es alles getan, was man vom ihm verlangt hat.

Natürlich könntest du make in ein Skript einbinden, also aus diesem aufrufen. Auch da kann doch aber eigentlich nichts schiefgehen. Unter Linux liefert doch jedes Programm einen Rückgabewert. Wenn der nicht Null ist, dann ist was schiefgelaufen. Diesen Rückgabewert kann das Skript auswerten. Aber das ist doch nichts Neues. Machen doch fast alle möglichen Skripte so, die sich auf einer Linux-Kiste so finden.

Der grundsätzliche Denkfehler ist nach meiner Meinung: Zum Erstellen eines Images braucht man ein Skript, das die vielen Dinge, die zu tun sind, automatisiert. Ohne geht es nicht. Das ist das Dogma. Und wenn ich das Skript brauche, dann kann ich newmake nicht gebrauchen, weil mein Skript ja damit nicht funktioniert.

Das hat mittlerweile was Religiöses. Da kommt Barf daher, lästert die Götter und behauptet: Die Welt ist eine Kugel. Das wird von den einen nicht geglaubt und von den anderen bekämpft, weil sie ihre Interessen beeinträchtigt sehen.

Werde ich mir mal bei einer ruhigen Minute zu Gemüte führen, kann aber noch ne Weile dauern.

Solltest du mal machen. Ist sehr lesenswert. Eine ausführliche, überzeugende Begründung für newmake, der auf der Ebene noch nichts entgegenghalten wurde.

[Tommy]

^ 100% Ack

[digi_casi]

ich habe mir zwar das newmake nicht angeschaut, aber bin auch der meinung, dass zum erstellen eines images kein script notwendig sein sollte.
ist bei enigma fuer dreambox auch so. dort ruft man make enigma-flash-compress (oder so aehnlich) auf, und es wird ein image erzeugt.

[ALexH]

Zum einen brauchst du kein Skript mehr, sondern nur noch make

Hmm... das wird aber schwer, die kompletten Skripte in newmake zu basteln. Ich mache mal ein paar Beispiele:

- Setzen von Image-Pfad, Typ, Version, Ersteller
- Automatisches checkout vom CVS (bei Vorhandensein Update, ansonsten oder auch auf Wunsch komplett)
- Ausführen von autogen und configure
- Patchen verschiedenster CVS-Bereiche
- Erstellen von u-boot, 1x und 2x, für jffs2- und squashfs-images mit eigener Partitions-Größe
- Einfügen von temporären Änderungen, bis das CVS angepasst wird
- Compilieren und Einbauen von eigenen Programmen
- usw. usw.

Dies alles geht über Skripte sehr zügig. Diese komplett umzubauen, Patches für newmake zu erstellen damit wieder alles so baut, wie man es persönlich am besten findet und bis das ganze dann auch funkioniert wird wohl noch sehr viel Zeit brauchen. Außerdem würde es dann nach jeder Änderung am Makefile Ewigkeiten dauern, bis wieder jeder seine eigenen Patches auf dem neuesten Stand hätte.

[wolgade]

Setzen von Image-Pfad, Typ, Version, Ersteller

Wie funktioniert das denn bei Head? Ich nehme an, du meinst die Textkonsole, die beim Booten angezeigt wird. Ist eine ernstgemeinte Frage, da ich das noch nicht rausgefunden habe.

Automatisches checkout vom CVS

Ich bin wirklich kein CVS-Auskenner, aber das ist eine Zeile. Daß das CVS-Checkout der erste Schritt von allen durchzuführenden ist, ist auch klar. Erst Compilieren und dann per Checkout den Quellcode verändern, wäre ziemlich sinnfrei.

Ausführen von autogen und configure

Also ich habe es bei HEAD nur bis zur Yadd geschafft. Wie das geht ist ja auch gut dokumentiert. Checkout, autogen und configure sind bis jetzt dann drei Zeilen Skript. Die Parameter für configure sind etwas andere als bei HEAD.

Patchen verschiedenster CVS-Bereiche

Was patcht ihr denn standardmäßig, so daß man es über ein Skript automatisieren könnte? Auch die Frage ist ernst gemeint.

Erstellen von u-boot, 1x und 2x, für jffs2- und squashfs-images mit eigener Partitions-Größe

Ob sich für die jeweiligen Imagetypen verschiedene Partitionsgrößen angeben lassen, weiß ich nicht. Barf aber ganz sicher. Wieder eine ernstgemeinte Frage: Wofür ist das wichtig?

Einfügen von temporären Änderungen, bis das CVS angepasst wird

Hier habe ich ein Verständnisproblem. Ist das nicht das gleiche wie Patchen?
Wenn ich das richtig verstehe, geht es darum, einen nicht zufriedenstellenden CVS-Stand durch was Brauchbares zu ersetzen.

Compilieren und Einbauen von eigenen Programmen

Hat Barf meines Wissens mal beantwortet. Läuft auf jeden Fall nicht per Skript, sondern über make. Dafür ist es ja da.

bis das ganze dann auch funkioniert wird wohl noch sehr viel Zeit brauchen

Ich hab ja erst ein einziges Image kompiliert. Die größten Probleme dabei waren der Checkout von newmake, da man ja zusätzlich auch noch Sachen von HEAD braucht. Nachdem mir DietmarW da auf die Sprünge geholfen hatte, war der Rest einfach:

autogen.sh
configure
make

Fertig. Das war's. Das einzige Problem waren die verdammten "bad magics". Die haben aber nichts mit HEAD oder newmake zu tun. Wie löst ihr das Problem mit den "bad magics" eigentlich?

[gmo18t]

Dies alles geht über Skripte sehr zügig. Diese komplett umzubauen, Patches für newmake zu erstellen damit wieder alles so baut, wie man es persönlich am besten findet und bis das ganze dann auch funkioniert wird wohl noch sehr viel Zeit brauchen.

... ist aber eigentlich gar nicht so wild: nachdem "newmake" einigermassen weit fortgeschritten war und ich mich mit der Funktionsweise näher vertraut gemacht hatte, war es dann ziemlich fix erledigt, meine bestehende "buildscript-Sammlung" (war der von yadi ähnlich) anzupassen. Natürlich kann bzw. darf man in Zs. mit "newmake" noch scripte einsetzen. Alles was vor dem eigentlichen Buildprozess, der durch (new)make angestossen wird, gemacht werden muß, läßt sich somit (immer noch) wunderbar automatisieren und meist in unveränderter Form.

Den Gesamtprozess hab ich in folgende Phasen unterteilt und für jede dieser Phasen ein passendes Script erstellt
1) CVS auschecken
2) CVS Stand patchen (Sourcen)
3) autogen und configure durchführen
4) Buildprozess mit Hilfe von newmake

Jedes der Scripte kann noch mehr oder weniger über Aufruf- Parameter variiert werden, wobei ich dies aber lediglich für 4) ausgenutzt habe: dort wird dann in Abhängigkeit der Parameter der "Vorbau" für "newmake" gemacht, was im Wesentlichen das Kopieren passendener root-scripte nach 'tuxbox-cvs/cdk' ist. Die "letzte Zeile" im 4)er-Script ist dann ein 'make' mit dem passenden "target".

Wichtig zu wissen: alle Modifikationen, die nicht in den Phasen 1) bis 3) möglich sind (wie z.B. " -Einfügen von temporären Änderungen, bis das CVS angepasst wird" oder
"- Compilieren und Einbauen von eigenen Programmen") können elegant in den root-scripten erledigt werden, ... dazu ist in keinem das Patchen von "newmake"-Bestandteilen an sich nötig !

In meinem Fall hab ich das 4)er-Script u.a. so ausgelegt, daß ich verschiedene Optionen, wie
- Images für alle Filesysteme bauen
- nur squashfs-Image bauen
- nur cramfs-Image bauene
- nur jffs2-Image bauen
- yadd bauen
pro Aufruf wählen kann. Auch ist der "wiederholte" Aufruf mit der gleichen Option (nach einem build Fehler) oder mit einer anderen Option, wenn ich z.B. später doch noch ein "yadd" bauen will, möglich.

Der Aufwand zur Umstellung meiner bisherigen Scripte betraf die Sachen für Phase 1) bis 3) nur geringfügig. Lediglich das Script für Phase 4) war eine "Neuauflage", wurde aber dank "newmake" einfacher und übersichtlicher Und wenn man sich ein wenig mit der Materie beschäftigt, endeckt man immer noch weitere Möglichkeiten und findet auch für anfänglich "unlösbar" scheinende Aufgaben dann doch noch einen geeigneten Weg.

Wie gesagt, bei mir war die Ausgangssituation ähnlich wie für "yadi". Und bestimmt gibt es ein paar Leute hier im Forum, die den
"yadi2newmake"-Umstieg ein wenig supporten werden ...

- GMo -

[digi_casi]

also aus meiner sicht wird das yadi script mit newmake ueberfluessig.
bzw. es wird ganz kurz und simple:
- auschecken
- autogen.sh
- configure.....
- make image
fertig.
so sollte es sein, oder?

[Tommy]

Wie löst ihr das Problem mit den "bad magics" eigentlich?

ganz simpel im configure

guckst Du Barf's Page:

http://www.bengt-martensson.de/dbox2/fl ... usiness%3F

EDIT: Wenn ich Bad Magics habe, ändere ich einfach die Dateigröße der start_neutrino durch zufügen oder entfernen einer "sinnlosen" Kommentarzeile. Mest klappt es danach. Vermutl kannst Du auch irgendwo eine Dummy- Datei variabler Größe ablegen. Ist halt ein wenig Black Magic nötig

[dwilx]

Ich mach das jetzt noch nicht allzulange aber kann Newmake eigentlich nur empfehlen. Meine persönlichen Anpassungen habe ich bisher alle einbauen können, auch eigene Tools oder Plugins konnte ich (zumindest testweise) bisher einbauen und wüsste auch nicht wo das Problem liegen sollte. Ich hatte allerdings erst nicht bemerkt, dass Barf seine Doku (Eindeutschung wäre absolut angebracht!) erweitert hatte, sonst wäre mir das sicher früher eingegangen, wie man dafür vorgehen muss, dann hätte ich mir auch diese Anfrage (http://forum.tuxbox.org/forum/viewtopic ... 458#297458)
sparen können. Je mehr ich mich da reindenke, um so mehr Lichter gehen einem da auf, was alles machbar ist.
Im Großen und Ganzen denke ich, dass Newmake eine Chance verdient hat, Standard zu werden und mit etwas guten Willen sollte das auch machbar sein und wenn einige Unklarheiten oder Unschlüssigkeiten beseitigt werden, und das müssen sie, wird wohl auch zwangläufig eine Entscheidung fallen ... dafür hat Barf im übertragenen Sinne mit viel frischem Wind jede Menge Staub aufgewirbelt...