Re: configure sets CFLAGS or how to disable default CFLAGS='-g -O2' for gcc?

[Ralf Corsepius]

On Tue, 2006-04-04 at 05:41 -0600, Ed Hartnett wrote:
> Peter Volkov <address@hidden> writes:
> 
> > On Вск, 2006-04-02 at 13:06 -0400, Chris Pickett wrote:
> >> On Sun, April 2, 2006 7:35 am, Peter Volkov wrote:
> >> > AM_CFLAGS = $(GLIB_CFLAGS) -O3 -Wall -ffast-math
> >> 
> >> I wouldn't worry about -O3 and -ffast-math unless you are sure they will
> >> make a difference.
> >
> > Yes. -O3 makes difference.
Yes, it can make the difference between a functional compiler invocation
and a failing one - However, you as the package author who doesn't have
access to the platform an installer/users is using have no chance to
know ;)

Packagers/installers/integrators however are supposed to know which
CFLAGS they want/need.

>>> I use AC_SUBST in configure.ac to define STRICT_CFLAGS, BROKEN_CFLAGS,
>>> DEBUG_CFLAGS and OPT_CFLAGS.  Strict flags give as many gcc warnings as
>>> possible, broken flags are those that don't play well for whatever reason
This invalidates all configure checks a configure script performs during
configuration, because it causes you to using different flags at
"configure-time" and "make-time".

> >> You can use AC_ARG_ENABLE to get debugging and optimizing configure
> >> options, which can then be used inside Makefiles, just look at some
> >> examples of how this macro is used.  The one thing you should avoid is
> >> clobbering the environment CFLAGS in a configuration file, the end user
> >> should always be able to override (at least the important bits of) what
> >> you specified.
> >
> > Ralf, in his mail mentioned that any setting of CFLAGS in program should
> > be avoided, but in my current program such approach could be very
> > convenient.
The problem is portability.

The "-g -O2" autoconf uses is nothing but a default, which is known to
be safe on the majority of platforms and therefore is likely to be safe
as a compromise between "optimization" and "non-optimization".

Anything else is beyond autoconf's scope and beyond your knowledge.

> In a similar situation, I first check to see if CFLAGS is set, then
> only muck with it if it has not been set:
> 
> AC_MSG_CHECKING([whether configure should try to set CFLAGS])
> if test "x${CFLAGS+set}" = xset; then
>    enable_cflags_setting=no
> else
>    enable_cflags_setting=yes
> fi
> AC_MSG_RESULT($enable_cflags_setting)
> 
> then later...
> 
>         test "x$enable_cflags_setting" = xyes && CFLAGS="$CFLAGS -q64"

> This way, if the user sets CFLAGS, his choice is respected (though it
> might make the build crash - but that's his problem).

Well, IMO this is your problem and qualifies as a bug in your configure
script:  You are providing a default that probably is invalid for most
compilers and is likely to cause building to fail or do something else
than you expect.

> If the user doesn't set CFLAGS, then I take the liberty of setting it
> to what will work on his platform. (Otherwise he will just email me
> and ask me how to set it, so this saves us all the trouble.)
If you really want to do something like you do, you'd have to check the
compilerm, if it accepts "-q64" and if "-q64" actually does what you
expect it to do.

In short: You have opened a can of worms, you'd better avoid.

Ralf