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
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 := $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.
DK-8200 Aarhus N