Fortschrittsanzeige bei ebuild Emerge

[Finswimmer]

Hi!

Ich weiß nicht, wie es euch geht.

Aber hier mein Beispiel:

Hab vor einer halben Std. ein emerge angeworfen, und nun will ich ins Bett.

Ich möchte eigentlich nicht den emerge unterbrechen. Bin faul, klar könnte ich das über ebuild path/to/ebuild/ emerge machen...

Darum gehts aber nicht

So...

Klar ist, dass man nicht sagen kann, wielange so ein emerge geht, außer man hat das betreffende Paket schon installiert (genlop -t Paket)

Aber:

Man könnte doch eigentlich einen Counter mitlaufen lassen, wieviele Unterverzeichnisse bearbeitet worden sind, und wieviele noch fehlen.

Das hätte doch den Vorteil, dass man nicht abbricht, wenn man sieht, dass der Compiler schon bei 89/90 Unterverzeichnissen ist.

Dass damit noch lange nicht gesagt ist, wielange das letzte Verzeichnis + make install + merge dauert, ist klar.

Aber es wäre doch schonmal ein Anhaltspunkt...

Was haltet ihr davon?

Könnte man das realisieren?

Bin gespannt auf eure Ideen.

Tobi

[Anarcho]

Klar, schreib nen Patch für make! Die werden sich sicher freuen!

Aber eine Lösung für das indirekte Problem hätte ich für dich:

Wenn du ins Bett willst, einfach im emerge-Fenster STRG-Z drücken,
dann einfach mit

[Finswimmer]

*gg*

Ja, das mit dem Patch könnte sich als etwas schwierig gestalten.

Gibt es denn in jedem dieser Unterverzeichnisse eine Makefile?

Dann könnte man einfach alle Makefile zusammenzählen:

find|grep Makefile|grep -v ".am"|grep -v ".in"|wc|gawk -F " " '{ print $1 }'

Und nun müsste ich doch "nur" ne Funktion einbauen, die sobald eine Makefile geöffnet wird, einen Counter hochsetzt.


Andere Idee:

Ist es so, dass jede Makefile, nachdem sie bearbeitet worden ist, "anders" aussieht?

Sprich: Wie mergt Emerge, wenn ich make abbreche, und wieder starte, was schon kompiliert worden ist?
Damit müsste ich doch auch gut arbeiten können?

Dann wäre es noch einfacher:

1) find|grep Makefile|grep -v ".am"|grep -v ".in"|wc|gawk -F " " '{ print $1 }'
--> gibt die Gesamtanzahl aus

2) Suche nach abgearbeiteten Makefiles
--> Statusanzeige (Abgearbeitete Makefiles / Gesamtanzahl)

Das dann in ein Script, was automatisch alle 10 Sek aufgerufen wird, oder immer sobald ein Unterverzeichnis gewechselt wird...

Könnt ja mal schreiben, ob das zu umständlich ist.

Gruß

Tobi

[l3u]

Wenn du was abbrichst, dann fängt emerge wieder von vorne an. Du kannst allerdings ccache benutzen, dann benutzt der Compiler beim mehrfachen Kompilieren der selben Datei mit den selben Parametern eine schonmal kompilierte Datei, die er aus dem Zwischenspeicher holt. Das beschleunigt das ganze dann merklich.

Ansonsten hab ich mir auch schonmal überlegt, ob man nicht vor dem Merge die Verzeichnisse in /tmp/xyz speichern könnt, und dann im Merge-Log des entsprechenden Pakets nach make[\d*]: Entering dirtectory ... leaving directory ... suchen könnt (damit sparst du dir anderweitige Handstände, weil da steht ja dann, sofern man das Loggen in der /etc/make.conf zuläßt, alles drin, was man auch auf dem Bildschirm zu sehen bekommt). Halt alles per Script -- damit könnt man dann sehen, welche Verzeichnisse schon bearbeitet wurden.
Inwiefern das ganze auch aussagekräftig ist, sei dahingestellt ... weil es kann ja sein, daß der Compiler im einen Verzeichnis gar nix macht und im anderen Stunden brauch ...
Aber wär doch ganz nett, oder? Dann konnt man z.B. makeprogress paket eingeben und sieht dann, wieviele Verzeichnisse zu bearbeiten sind, und wieviele noch fehlen.

Frage dazu: Wie kommt man auf die Nummer, die im Log vor dem Paket steht (z.B. "3863-inkscape-0.43.log")? Die bräucht man natürlich dazu ...

[Finswimmer]

Wenn ich meinen emerge Vorgang abbreche, sind alle Teile in /var/tmp/portage/PAKET enthalten.

Gehe ich da dann rein, und sage make, so kompiliert er weiter. Und auch nur das, was noch nicht kompiliert worden ist.

Das Ganze kann man mit ebuild /path/to/package/ emerge automatisieren.

Von daher ist dein Weg wohl etwas zu umständlich.


Ich will keinen Weg, der mir das abbrechen erleichtert, das, was ich beschrieben habe, ist schon gut.

Ich möchte gerne sowas, was du dir unter makeprogress vorstellst.

Daher sind meine Fragen nach der technischen Realisierung noch offen.


Die Nummer ist, soweit ich weiß der darugehörende Prozess. Denn theoretisch könntest du ja so schlau sein, und zweimal das gleiche emergen. Dann gäbe es Probleme mit der eindeutigen Zuordnung.


Gruß Tobi

[Anarcho]

Also das "Fortführen" der Kompilation erledigt make selber. Es schaut sich die ergebnisse an und
vergleicht das Datum mit dem Datum der Sourcen. Wenn es neuer ist als diese wird
es nicht neu kompiliert.
_________________
...it's only Rock'n'Roll, but I like it!

[mrsteven]

Eigentlich könntest du für deine Zwecke auch genlop ("emerge genlop") einsetzen, z.B.:

[l3u]

Daß make von selber da weitermacht, wo es aufgehört hat, weiß ich schon -- aber daß man das auch mit emerge da fortsetzen kann, wußte ich noch nicht. Naja, man lernt nie aus ;-) Nichtsdestotrotz ist ccache nicht schlecht und schadet auch nix.

genlop -c zeigt mir auch immer nur an, daß derzeit kein Programm kompiliert ...

Aber sowas wie "makeprogress" (hab ich mir einfach mal schnell so überlegt den Namen ;-) sollte ja eigentlich nicht allzu schwer zu realisieren sein. Weiß einer, was mir die Zahlen vor der Logdatei sagen wollen?

[Finswimmer]

@mrsteven: Das was du beschreibst ist die Gesamtdauer.

Ich möchte aber ein Programm erstellen, was den Fortschritt innerhalb eines einzigen Pakets angibt.

@Anarcho:

Du meinst, der Kompiler vergleicht die Daten.
Er wird doch nicht jede Datei vergleichen, auf welche Datei sollte ich mich da sinnvollerweise beschränken?


Bzw.: Es muss doch eine übergeordnete Prozedur vorhanden sein, die dieses Vergleichen ausführt. Weißt du, wo die ist, denn dann müsste ich da doch meine eigene Prozedur reinschreiben...

Danke

Tobi

[Anarcho]

[Finswimmer]

Das letzte von mir war ein großer Denkfehler.

Ich dachte, dass das Ganze so abläuft:

1.Prozess überprüft Unterverzechnis auf Aktualität und ruft dann evtl make auf.

Aber da make das, wie du mir eben geschrieben hast, alles selbst erledigt, ist die Idee natürlich nicht richtig.


Und aus Versehen habe ich eben Kompiler mit make synonym verwendet. --> Noch ein Fehler


Ich müsste also diese Zählprozedur, die mir vorschwebt, in make unterbringen, und genau bevor make das Verzeichnis auf das aktuelle Datum überprüft?


Tobi

[l3u]

Wieso willst du denn ständig zählen? Langt doch, wenn man ne Verzeichnisliste macht, und dann per Log nachschaut, welche der Verzeichnisse schon abgearbeitet wurden. Also einmal zählen per Aufruf. Das ist doch viel leichert unterzubringen als was, was das ständig überprüft

[Finswimmer]

Das mit dem Zählen war ja nur eine Idee, weil mir bis jetzt noch nichts Einfacheres untergekommen ist.

So sieht meine emerge.log aus:

[l3u]

Debug? Nee, ich hab nix von debug geschrieben. Du mußt lediglich z.B.

[Finswimmer]

So.

Nun ists fertig.

Mir gefällts:

Hier die Ausgabe.

[Finswimmer]

Zusatz:

Es ist schlauer nach leaving zu suchen, statt nach entering.

Sonst zeigt er sobald man im letzten Verzeichnis ist, an, dass es x von x wären...und nicht x-1 von x.

Tobi

[Anarcho]

Ich will dich in deiner kreativen Phase nicht stoppen, aber nicht jedes Paket wird mittels make gebaut...
_________________
...it's only Rock'n'Roll, but I like it!

[Finswimmer]

Guter Einwand.

Was gibt es denn sonst noch für Möglichkeiten ein Paket zu bauen?

Und wie kann man die dann eventuell überprüfen?


Aber die Mehrzahl wird wohl doch mit make gemacht... Und darüber freue ich mich erstmal


Ciao

Tobi

[Romses]

Es gab da mal ein Script, welches einfach alle .c oder .cpp Dateien gesucht hat, und die mit der Anzahl der .o Dateien verglichen hat.
AFAIK könnte man so abschätzen, wieviele Dateien man noch zu verarbeiten hat.

Leider habe ich dieses Script nicht mehr...

Gruß Romses

[l3u]

Also ungefähr so hatte ich mir das auch vorgestellt. Aber zu bedenken ist, daß nur nach dem Namen des Paketes zu suchen nicht zwingend auch das entsprechende Logfile liefern muß ... weil wenn du ein Paket mehrfach kompilierst, dann wird je ein Logfile angelegt. Mit dem selben Namen drin, aber einer anderen Nummer vorne dran.

[Finswimmer]

@Libby: Gut. Das war ja auch erstmal einfach so reingehackt in den Pc. Damit was läuft, und das kann man ja durchaus verbessern.

Hast du schon einen gewissen Überblick, was die Zahlen nun wirklich aussagen?

Zuerst dachte ich, dass das die Prozessnummer sei, aber dem ist wohl nicht so.


Findest du, denn du hast das Loggen schon länger als ich, eine Regelmäßigkeit in den Zahlen?

Oder:

Man prüft, ob es mehrere LogDateien des gleichen Pakets nimmt, und nimmt die mit dem aktuellen Datum und Zeit.


Tobi

[l3u]

Also ehrlich gesagt: Ich hab keine Ahnung, was die Zahlen heißen. Die sind scheinbar eine UID für das Logfile ... aber woher man wissen soll, welche Zahl das ist ... keine Ahnung ... vielleicht soltle man da mal einen aus #gentoo-devs auf freenode fragen oder so ...

[Finswimmer]

[l3u]

Wie wär's mit "find /verzeichnis/ | grep"? Dann schreib schön nacheinander die Dateinamen hin. Aber Man müßte ja an sich rausfinden können, wo diese Nummer herkommt, dann kann man sich das Suchen sparen!

[Finswimmer]

Nee. Immer noch der gleiche Fehler.

Es scheint so, dass jeder Befehl, der den Inhalt dieses Verzeichnisses ausgibt, erst in eine Variable geschriebn wird, und dann damit weitergearbeitet wird.

Auch wenn man ls * > /tmp/test macht, läuft die Variable über.

Ich weiß leider grade nicht, wie ich das umgehen kann...


Tobi