Mal eine vielleicht ungewöhnliche Frage:
Ich brauche gelegentlich ein paar Zusatzfunktionen, die in den
vorkompilierten Standardversionen von Kicad, Spice, Octave usw. in
Debian Linux nicht enthalten sind. Auf die Schnelle mal einen kleinen
Patch geschrieben, der das Gewünschte erledigt, und dann warte ich 10
Minuten - 10 Stunden aufs Kompilieren.
Sehr hilfreich wäre eine Datenbank von relativen Kompilierungsdauern,
also z.B. "Octave-3.8 braucht 42 mal so lange wie ngspice-25.1".
Natürlich hängt das von allen möglichen Flags, Kompilerversion usw. ab,
aber ein grober Anhaltspunkt, ob ich ein paar Minuten warten muss oder
erst mal schlafen gehen kann, wäre enorm hilfreich.
Gibt es solche Daten, vielleicht im Zusammenhang mit dem
Linux-from-scratch Projekt?
Martin
Martin schrieb:> Gibt es solche Daten, vielleicht im Zusammenhang mit dem> Linux-from-scratch Projekt?
Warum ergänzte nicht die build-scripte um ein date >> Log.txt und
compilierst den Kram auf deinem Referenzrechner selbst?
Geringfügig mehr script und du kannst das ganze über nacht laufen
lassen.
Wesarion schrieb:> Warum ergänzte nicht die build-scripte um ein date >> Log.txt und> compilierst den Kram auf deinem Referenzrechner selbst?
Weil ich gerade dann, wenn ich ein Tool zum ersten Mal kompiliere gerne
vorher schon in etwa wüsste, auf welche Wartezeit ich mich einstellen
muss.
Martin schrieb:> Ich brauche gelegentlich ein paar Zusatzfunktionen, die in den> vorkompilierten Standardversionen von Kicad, Spice, Octave usw. in> Debian Linux nicht enthalten sind. Auf die Schnelle mal einen kleinen> Patch geschrieben, der das Gewünschte erledigt
hast du mal ein Beispiel, was du so alles an Features in diese Tools
reinimplementiert hast?
Irgendwie fällt es mir schwer zu glauben dass du dich derart schnell in
fremden Code reinfuchst, deine Änderungen implementierst (natürlich an
einer architektonisch sinnvollen Stelle), kein Debuggen notwendig ist
und du dich dann über die halbe Stunde Kompilieren ärgerst.
Klingt weltfremd und ist such Quatsch, weil niemand abschätzen kann, wie
deine Änderungen sich auf die Kompilierzeit auswirken.
Diese Werte müssten ständig angepasst werden.
Martin schrieb:> Hat vielleicht irgendjemand auch eine sinnvolle Antwort?
Die sinnvolle Antwort: solch eine Tabelle wirst du nicht finden.
Es gibt einfach viel zu viele Randbedingungen und viel zu wenige
Anwendungsfälle, als dass sich jemand die Mühe machen würde, sowas
zu tabellieren.
Grob gerechnet kannst du erstmal sagen: je größer der Sourcecode
des Pakets, desto länger wird das Compilieren dauern.
Jörg W. schrieb:> Es gibt einfach viel zu viele Randbedingungen und viel zu wenige> Anwendungsfälle, als dass sich jemand die Mühe machen würde, sowas> zu tabellieren.
Es soll sich niemand die Mühe machen. Ich frage mich nur, ob die Daten
nicht schon irgendwo vorhanden sind. Z.B. bei Buildsystemen der
Linuxdistributionen, für deren Lastverteilung es auch sinnvoll sein
sollte, abschätzen zu können, wieviel Kompilierungszeit gebraucht wird,
wenn eine bestimmte Menge an Patches eingegangen ist.
Jörg W. schrieb:> Grob gerechnet kannst du erstmal sagen: je größer der Sourcecode> des Pakets, desto länger wird das Compilieren dauern.
Ich glaube, da ist es eine bessere Abschätzung, zu sagen, dass jedes
Paket 10 Minuten zum Kompilieren braucht. Die Größe des Quellcodes hat
nun wirklich den allerkleinsten Einfluss. Um eine halbwegs brauchbare
automatische Abschätzung zu haben, müsste man schon die generiertem
Makefiles analysieren, nachsehen, welche Abhängigkeiten bestehen,
inwieweit einzelne Dateien parallel kompiliert werden können, wie tief
Klassenhierarchien verschachtelt sind, usw...
Nun aber bitte wirklich nur noch sinnvolle Antworten. Es hilft einfach
nichts, wenn jeder, der solche Daten noch nicht gesehen hat, seinen Senf
loswerden muss und behauptet, dass es solche Daten nicht geben kann.
Martin schrieb:> Es soll sich niemand die Mühe machen. Ich frage mich nur, ob die Daten> nicht schon irgendwo vorhanden sind. Z.B. bei Buildsystemen der> Linuxdistributionen,
In den Buildlogs des FreeBSD-Portbuild-Clusters vielleicht.
Aber da könnte ich dir jetzt auch nicht genau sagen, wo man da
anfangen müsste zu suchen.
>> Grob gerechnet kannst du erstmal sagen: je größer der Sourcecode>> des Pakets, desto länger wird das Compilieren dauern.>> Ich glaube, da ist es eine bessere Abschätzung, zu sagen, dass jedes> Paket 10 Minuten zum Kompilieren braucht. Die Größe des Quellcodes hat> nun wirklich den allerkleinsten Einfluss.
Das widerspricht sehr deutlich meiner eigenen Erfahrung (ich baue
im Rahmen der FreeBSD-Ports so gut wie alles selbst). Die entspricht
eher dem, was ich da oben geschrieben habe.
Installier dir doch Gentoo, dann findest du das ganz genau heraus.
Ist leider ähnlich sinnvoll wie eine Compiledauertabelle.
Compiledauer hängt von vielen Faktoren ab, Load auf der Maschine,
Compilerversion, welcher Compiler überhaupt, in welcher Sprache das
geschrieben ist, was du an Optionen zur Compilezeit festlegst, das
darunterliegende Filesystem
foobar schrieb:> Installier dir doch Gentoo, dann findest du das ganz genau heraus.
Von genau schrieb ich nie etwas.
> Compiledauer hängt von vielen Faktoren ab,
Ach nee, sach an. Hast du außer meiner Überschrift noch etwas von meinem
Beitrag gelesen?
Man kann ja einfach schon nebenbei den Compiler einmal laufen lassen.
Nur im ersten Lauf muß ja alles compiliert werden, danach nur noch der
geänderte Teil.
Peter D. schrieb:> Man kann ja einfach schon nebenbei den Compiler einmal laufen lassen.> Nur im ersten Lauf muß ja alles compiliert werden, danach nur noch der> geänderte Teil.
Kommt darauf an wie clever das makefile geschrieben wurde. Wenn die
Änderungen h files betreffen siehts dann evt. nochmal anders aus.
Ausserdem schwankt sowas extrem mit der vorhandenen Hardware: SSD,
prallelisierung, ...
foobar schrieb:> https://buildd.debian.org/status/logs.php?pkg=octave&arch=amd64
Na bitte, geht doch. Und für alle anderen, wenn man keine Ahnung hat,
... ihr wisst schon. Keinem ist geholfen, wenn jeder zu jedem Thema in
der einen oder anderen Form schreibt "Ich habe keine Ahnung, aber hier
kommt auch noch mein Senf." Das hier ist alles ein Riesenhaufen
Senfsoße.
Martin schrieb:> foobar schrieb:>> https://buildd.debian.org/status/logs.php?pkg=octave&arch=amd64>> Na bitte, geht doch.
in der Tat interessant, aber was bringen dir die Zahlen, ohne die
Randbedingungen zu kennen, unter denen sie zustande kamen? ...oder habe
ich etwas überlesen?
Martin schrieb:> Keinem ist geholfen, wenn jeder zu jedem Thema in> der einen oder anderen Form schreibt "Ich habe keine Ahnung, aber hier> kommt auch noch mein Senf."
...naja, solange der Senf zum Thema beiträgt und (z.B.) dein
Anliegen/Ideen auf Sinnhaftigkeit hinterfragt, vielleicht doch! Zu
mindestens machen die Leute sich Gedanken zu deinem(!) Problem und
versuchen dir zu helfen...
Martin schrieb:> Das hier ist alles ein Riesenhaufen> Senfsoße.
...dann frage einfach nicht hier!
Martin schrieb im Beitrag #4543268:
> fünününü
...ist das jetzt eine Frage oder eine Antwort auf welche Frage?
nono schrieb:> in der Tat interessant, aber was bringen dir die Zahlen, ohne die> Randbedingungen zu kennen, unter denen sie zustande kamen?
Man kompiliert sich selbst ein Paket - wie binutils - und nimmt dabei
die Zeit. Damit hat man die eigene Zeit und die von Debian, für
beliebige Pakete kann man nun näherungsweise einfach Dreisatz benutzen.
