[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ed Hartnett
Subject: Re: configure sets CFLAGS or how to disable default CFLAGS='-g -O2' for gcc?
Date: Tue, 04 Apr 2006 05:41:08 -0600
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (gnu/linux)

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.
>> Save CFLAGS before you call AC_PROG_CC, and restore it after, if you don't
>> want "-g -O2".  Search the Autoconf list for AC_PROG_CC, there was a
>> fairly clean way of doing it suggested in the last couple of years.  I
>> know this because I recently had a similar problem: I wanted -O0 as the
>> default.  AC_PROG_CC has been doing this since 1996.
> Great! This works :) Thank you!
>> > Another related question is what if I want to have different CFLAGS for
>> > release and for debugging. How should I do this? I thought about different
>> > AM_CFLAGS in and chose between them with
>> > AM_CONDITIONAL, but now I don't know what to do.
>> 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
>> and can't be used everywhere (e.g. I link against a library with variadic
>> macros and so I have to put -Wno-variadic-macros in there, since I am
>> using -ansi -pedantic -Werror).  Then to use these in a I do
>> AM_CFLAGS += @STRICT_CFLAGS@, for example; you could also have them
>> associated per-program.
>> 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. Thank you again!

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

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).

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.)

Good luck!

Ed Hartnett  -- address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]