On 2017-10-05 17:29, Laurent Bercot wrote: >> Hm, that is a problem indeed. The goal is always for the user CFLAGS to >> override the automatic CFLAGS. I'm going to fix that. > > Actually, things are working as intended. The contents of the CPPFLAGS, > CFLAGS and LDFLAGS *environment variables* do not override the defaults > in the Makefile. However, when CPPFLAGS/CFLAGS/LDFLAGS is used as a > *make variable* ("make CFLAGS=-fstack-protector=yes"), then it does > override the defaults. > If you want the environment variables to also override the defaults, > you can run "make -e". > > I should still modify the Makefile to make it easier to override > CFLAGS and friends without having to manually redefine the -I and -L > paths.
Yes, I obviously don't want to replace CFLAGS or CPPFLAGS whole-sale, as there might actually be necessary options in there, and I certainly don't want to pick those out and have to provide them manually. I just thought that the way you meant for people to add to CFLAGS was by having those set in the environment at _configure_ time, since you very explicitly initialize CFLAGS_AUTO to $CFLAGS in the configure scripts. The problem is then that all the configure logic appends to that variable, and at the end sets the CFLAGS make variable to $CFLAGS_AUTO. So maybe a simpler fix is to just do -CFLAGS_AUTO="$CFLAGS" +CFLAGS_AUTO="" .... -CFLAGS := $CFLAGS_AUTO +CFLAGS := $CFLAGS_AUTO $CFLAGS but that won't catch bad user-supplied cflags at configure time, though. Dunno, it's up to you, but I'd really like some way to pass _additional_ CFLAGS that are guaranteed to have precedence; I don't care much whether I have to do it at configure or make time, or whether I need to set a make or environment variable. -- Rasmus Villemoes Software Developer Prevas A/S Hedeager 3 DK-8200 Aarhus N +45 51210274 rasmus.villem...@prevas.dk www.prevas.dk