autoconf
[Top][All Lists]
Advanced

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

Re: Setting optimizations without violating autotools principles


From: Eric Blake
Subject: Re: Setting optimizations without violating autotools principles
Date: Fri, 08 Jul 2011 07:04:45 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.10

On 07/07/2011 08:22 PM, Chris Stankevitz wrote:
> --- On Thu, 7/7/11, Ralf Wildenhues <address@hidden> wrote:
>> From: Ralf Wildenhues <address@hidden>
>> # Override CFLAGS if not set by the user.
>> test ${CFLAGS+set} = set || CFLAGS=-O0
> 
> Ralf,
> 
> Thank you.  I believe your method does not work when the user has set CFLAGS 
> to something that has nothing to do with optimizations (e.g. 
> CFLAGS=-I/foo/bar).
> 
> Would you please comment on the solution I came up with:
> 
> In configure.ac:
>   CFLAGS_ORIG=${CFLAGS}
>   AC_PROG_CC
>   CFLAGS=${CFLAGS_ORIG}

If the user set CFLAGS, then this is equivalent to:

CFLAGS_ORIG=$CFLAGS
AC_PROG_CC -> CFLAGS is set, so no change to CFLAGS
CFLAGS=$CFLAGS_ORIG -> no change to CFLAGS

However, if the user did not set CFLAGS, then this is equivalent to:

CFLAGS_ORIG=
AC_PROG_CC -> CFLAGS wasn't set, so now CFLAGS is either '-g' or '-g
-O2' depending on $CC
CFLAGS=''

which explicitly sets CFLAGS to the empty string, instead of leaving it
unset.

This might have ramifications for users that do ./configure -C, since
CFLAGS is a precious variable, and configure warns about a change
between a set-but-empty and an unset variable.

> 
> In Makefile.am:
>   if DEBUG
>   AM_CFLAGS = -g3 -O0
>   endif

The combination '-g3 -O0' is gcc-specific.  It will fail miserably on
other compilers, unless you took pains in configure.ac to ensure that
the automake conditional DEBUG can only be set if $CC is gcc.  But if
you did indeed take care to define the automake conditional
appropriately, then yes, this is a way to turn on debugging (for
comparison, look at coreutils.git, and see how coreutils turns on
optional warning flags when you configure --enable-gcc-warnings, where
coreutils took pains to ensure that the AM_CFLAGS adjustments are only
made to options already proven at configure time to work alongside the
user's $CC).

> 
> I believe my approach
> 1. Allows the user full control via the sacred CFLAGS
> 2. Does not touch, mutate, or alter the user's sacred CFLAGS

But points 1 and 2 are also met by following the autoconf manual's
approach of:

: ${CFLAGS="-g3 -O0"}
AC_PROG_CC

without having to modify AM_CFLAGS in the first place.  But you are
still stuck with the burden of verifying whether '-g3 -O0' works with
non-gcc $CC.

> 3. Works despite AC_PROG_CC mucking around with CFLAGS

AC_PROG_CC does _not_ muck around with CFLAGS.  If the user specified
CFLAGS, then AC_PROG_CC honors that.  If the user did not specify
CFLAGS, then AC_PROG_CC uses a default, and you as package author have
control over that default if you don't like autoconf's choice of '-g' or
'-g -O2'.  However, autoconf's default is safe for all compilers,
whereas you have to be careful when using a default like '-g3 -O0' that
is gcc-specific.

> 4. Works even when the user specifies CFLAGS that do not change the 
> optimization level
> 
> Thank you all for your help,
> 

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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