David Haller wrote:
Hallo,
On Sam, 10 Feb 2001, Ralf Corsepius wrote:
Wenn wir schon pedantisch, dann auch richtig:
*g*
* -O2 gehört definitiv zu den CFLAGS. Ob -Wall, -ansi, -pedantic auch zu den CFLAGS gehören, darüber kann man sich streiten. Viel Entwickler zählen sie dazu (Ich auch), andere wiederum nicht.
Klar gehoeren die dazu. Nur mehrfach-Angabe schadet nix. (s.u.)
<Pendantik-Modus> Mehrfach-Angaben von echten CFLAGS schaden nicht, doch sollten gcc-Driver- (z.B. -B..), Linker- oder Präprozessorflags hineingeraten, .. </Pedantik-Modus>
* CFLAGS aus Environmentvariablen heraus zu exportieren (export CFLAGS=..) und auf der Command-Line zu verwenden (gcc $CFLAGS) ist eine reichlich fragwürdige Geschichte und sollte man sich besser nicht angewöhnen.
Wieso? Es ist extrem fehlerträchtig, da Du die Kontrolle darüber verlierst und es nicht unwahrscheinlich ist, dass Du Dich in einem halben Jahr nur noch diffus daran erinnern wirst, wenn Du nach einem Systemwechsel oder nach einem Login auf einer Sparc/Alpha/Mips/m68k/ix86 plötzlich mit merkwürdigen Übersetzungsproblemen zu kämpfen hast.
Der Grund ist, ich habe halt keine Lust immer:
"-Wall -O2 -march=i686 -mcpu=athlon -fno-strict-aliasing -mpreferred-stack-boundary=2 -malign-functions=4 -fschedule-insns2 -mwide-multiply" Auch über den Sinn dieser Flags kann man streiten. .. werde ich jetzt aber nicht :)
einzugeben ;). Das -O2 usw. schrieb ich dahinter, damit mindestens diese Optionen gesetzt werden, falls jemand keine CFLAGS exportiert hat. Und genau das ist das Hauptproblem: Manchmal werden gewisse CFLAGS bewusst nicht gesetzt. In der Regel wissen die Entwickler eines Paketes besser als der "Casual Installer" warum sie gewisse Flags setzen und warum nicht. So wissen auch die gcc-Entwickler ziemlich genau warum sie gewisse Flags als Default setzen und welche nicht.
Ein weiteres Problem sind Konflikte zwischen deinen exportierten Shell-Variablen und Makefile/configure-Script Shell- bzw. Make-Variablen, z.B.: * Beim Übersetzen/Verwenden von Cross-Compilern/Toolchains: CFLAGS ist nach autoconf/automake Konventionen host-Architektur abhängig (bei Dir offensichtlich Athlon). Solange Du nur für eine Plattform übersetzt, wirst Du kaum Probleme haben, sonst aber ... * Viele Pakete unterscheiden nicht zwischen Präprozessorflags (z.B. -I..), Linkerflags (z.B. -L..) und Compilerflags (z.B. -O2), sondern packen alle Flags in eine Shell- oder Makefile-Variable. Oft wird CFLAGS dazu verwendet. Du wunderest Dich dann später nur darüber, dass irgendetwas nicht so tut wie es sollte, weil Deine Shell-Variable CFLAGS mit den Variablen des Paketes in Konflikt gerät. * Deine CFLAGS sind gcc-spezifisch. Solltest Du sie in ~/profile o.ä. setzen, bekommst Du Probleme wenn Du in einem Netz arbeiten oder auch verschiedene Compiler verwenden solltest.
Ausserdem erleichtert das (mir) das kompilieren generell sehr, es reicht ein ./configure ... statt einem CFLAGS="[s.o]" ./configure ... Ja, beides ist nahezu gleichbedeutend und hat entsprechend auch die gleichen generellen Probleme. Nur, im letzteren Fall gibst Du sie in jedem Einzelfall explizit an und läufst weniger Gefahr in oben erwähnte Probleme zu geraten.
Im Übrigen spielt dies auf einem Einzelplatzsystem so gut wie keine Rolle, in einem (heterogenen) Netz wird es allerdings relevant. Derartige Dinge sind oft die Ursache für "Bei mir daheim tuts, am Arbeitsplatz, an der Uni, beim Kunden, bei meinen Kumpel plötzlich nicht mehr" Fälle :). Ralf