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.
Hat vielleicht irgendjemand auch eine sinnvolle Antwort?
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?
https://buildd.debian.org/status/logs.php?pkg=octave&arch=amd64 In Zukunft solltest du vllt etwas an deinem Tonfall arbeiten. Die buildd Stats zu ergooglen ist wirklich nicht schwierig. :-*
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.
Als Dank könntest du noch kundtun, was zu z.B. alles in Octave implementiert hast. Vielleicht hat die Community ja auch gefallen an deinen Features?
Schöne Art "Danke" zu sagen. Absichtlich werd ich dir nicht nochmal helfen.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.