severity 12164 wishlist tags 12164 wontfix thanks On 08/09/2012 09:58 PM, Bruce Korb wrote: > Hi, > > It seems that AM_PROG_CC > Huh? There is no such think like 'AM_PROG_CC'. I guess you mean AC_PROG_CC.
> likes to default CFLAGS to "-g -Wall" > Since AC_PROG_CC comes from Autoconf, this is not due to Automake in any way. Maybe you should ask on their list how to prevent this from happening. > and COMPILE puts CFLAGS at the end of the option list. > Rightly so, because user overrides are expected to always take precedence. > That means that -Wall over-rides my AM_CFLAGS setting and chokes > and dies. > How can -Wall cause the compiler to die? Have you added -Werror to $(AM_CFLAGS) maybe? > My library uses a large array of bytes to hold many strings, > some of which are formatting strings and gcc is really clever about > noticing that there are embedded NUL bytes separating each substring. > (I actually added -Wno-format-contains-nul shortly after this new > cleverness was added...) The deal is that if someone does a: > > make CFLAGS='-Dsomethingforme -Wall' > > and I were to add this nul thingey to the end of CFLAGS, then > my effort is for naught. I think it useful to have a PROJECT_CFLAGS > that always gets stuck at the end in the COMPILE macro. > This would go against the principle that "the user is always right (when he is explicit)". If your users want to instruct your package to do something stupid, allow them; it might turn out that what might seem stupid is actually subtly clever or useful in some corner-case situations. So, in this case above, the user will just learn to add a '-Wno-error' option to his CFLAGS if he wants to avoid spurious errors; maybe he is using '-Wall' not to cause extra errors, but because he wants to see which the warnings you have disabled are, for his own reasons (good or bad, that is not for us to speculate about). Your proposed idiom would prevent him from doing so easily. We can't start trying to double-guess or out-smart the user: there lies madness (and some Windows programs ;-) Because, in the end, what would prevent the user from overriding $(PROJECT_CFLAGS) as well? > Meanwhile, I'll specify it twice -- once in CFLAGS and again in AM_CFLAGS > in hopes it remains active regardless. > This way, you are preventing your user a way to define $(CFLAGS) himself; not a good move. > (Actually, gcc probably ought not override a specifically set option > with a "-Wall", but this the wrong forum for that...) > > Thanks - Bruce > Regards, Stefano
