On Thu, 11 Apr 2002 20:02:07 +0200, Josef Spillner wrote:
Eine andere Realisierung dürfte schwer sein, da es ja transparent für alle Beteiligten sein muß.
Sicher ist eine andere Realisierung schwerer. Ich finds aber blöd, wenn der Aufruf von gcc auf jedem System was anderes tut.
Wer Farben oder andere defaults fürs Optimieren will, muß halt was anderes aufrufen z.B. 'colorgcc' oder man baut den Wrapper so, daß man den "normalen" gcc-Aufruf komplett hinter dem Wrapper schreibt. Der diet-Wrapper von der dietlibc ist ein Beispiel dafür. Der will mit "diet gcc ..." aufgerufen werden.
Also wenn ich meine Pakete baue, dann hab ich das konsequent auf i386 gestellt weil ich sonst böse Mails bekommen würde :)
Ja, das ist ok. Die Pakete stellen alle explizit i386 ein. Bei normalen .tar.gz-Paketen mit autoconf reicht setzen von $CFLAGS vorm ./configrure. Das ist bei Debians Paketen außer Kraft gesetzt. Also muß man sich was einfallen lassen.
Bisher sind ja die wenigsten Pakete optimiert (z.B. kernel-image-xxx für xxx Element aus {386,586,686,k6,k7}), wobei man das Problem hat daß die Kombination von Features nur eingeschränkt möglich ist. Alles andere würde zu einer Paketexplosion führen.
Extra binary-Archive für Pentium oder Athlon seitens Debian finde ich auch sinnlos. Letzlich sind die aktuellen Rechner so schenll, daß sie beim update notfalls allles neubauen können. Das könnte man in apt einbauen.
Andere Pakete bekommt man also nur vom Source optimiert, und dafür ist configure zuständig, was ja einen String wie i586-pc-gnu-linux liefert was dann ausgewertet wird.
Eben. Grundsätzlich muß configure die Stelle bleiben, bei der der Wunsch nach bestimmten Optionen angemeldet werden muß. (indem man CFLAGS CXXFLAGS vorm Aufruf von configure entsprechend setzt)
Unterschieben von Optionen durch einen gefakten gcc ist böse weil:
Der Autor des Upstream-Pakets sollte letzlich das letzte Wort zu den beim Compilieren verwendeten Optionen haben. Der Upstream Autor muß die Chance behalten, bei einigen Files nur ganz bestimmte Flags zuzulassen. Er kann z.B. beim Compilieren eines einzigen Files seines Pakets die CFLAGS ignorieren weil er genau weiß, daß dieses File wegen eines gcc-Bugs mit -march=pentium Schrott wird. Mit dem Wrapper des pentium-builders hat der Upstream Autor diese Chance nicht mehr und der Debian-Maintainer hat die Arbeit.
Ich würde mir 2 Dinge wünschen: 1. ein Konfigfile in /etc welches die default Optionen für auf diesem Rechner gebaute Debian-Pakete enthält. Steht da nix drin, wird so gebaut wie bisher (also für die alten Systeme wie i386 oder sparcv7)
Diese Optionen dürfen NUR beim Bauen von Debian-Paketen aktiv werden, NICHT wenn ein Nutzer einfach mal "gcc hello.c" sagt!!!!!!!!
2. einen zu "apt-get apdate; apt-get upgrade" ähnlichen Aufruf von apt, der alle neu zu installierenden Paket als Source saugt und mit den in /etc definierten Flags baut und installiert. Vielleicht einfach als Option in die apt.conf um weiter "apt-get apdate; apt-get upgrade" nutzen zu können.
Es gibt ja Überlegungen für Debian, sowas wie BSD-Ports über apt-get bereitzustellen. Beispielsweise gibt man ein apt-get source-autobuild mozilla und der holt die Quellen des Paketes und der Abhängigkeiten, kompiliert die im Hintergrund durch und schickt dann eventuell eine Mail wenn's fertig ist, so daß man nur noch apt-get install-autobuild eingeben muß und dann alles installiert wird. Oder so ähnlich ;)
So meinte ich das auch.
Jetzt könnte man wieder diskutieren ob man jegliches Paket so optimieren muß, aber für alles was ständig aktiv ist (Kernel, glibc, X11, ...) lohnt sich sowas sicher.
Denk ich auch.
Reinhard