autoconf
[Top][All Lists]
Advanced

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

Re: deleting config.cache upon CFLAGS variable change


From: Eric Blake
Subject: Re: deleting config.cache upon CFLAGS variable change
Date: Wed, 23 Mar 2011 14:26:56 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.9

On 03/23/2011 07:15 AM, Mathieu Lacage wrote:
> hi,
> 
> Recently, I discovered the "./configure CFLAGS=-O0" syntax:
> previously, I used to do "CFLAGS=-O0 ./configure" (I wonder if they
> are really equivalent but, this is not really my main question today).

Main question or not, I'll answer it:

Passing via the environment only preserves precious variables.

Passing via an argument to configure preserves all other variables.

When doing repeated runs, you want to preserve all variables to have
predictable results.  Therefore we document that ./configure CFLAGS= is
the preferred form.

However, CFLAGS happens to be one of the few precious variables
(./configure --help lists all precious variables), so in this regards,
you are right that you aren't seeing any difference.

> 
> So, anyway, I use "./configure CFLAGS=-O0" and I regularly switch to
> "./configure CFLAGS=-O2". I would like to know if deleting
> config.cache is sufficient to ensure that the build is correct or if I
> should "make distclean" instead.

Deleting config.cache is sufficient to make sure that the generated
Makefiles pick up the new definition.  However, depending on the
project, it is usually insufficient to force a rebuild of all objects
(it would require that every file depend on config.status and be rebuilt
if any configuration changes are made, which can feel rather expensive;
however some projects have encoded that dependency into their Makefiles).

So running make clean before deleting config.cache is often a safer,
albeit more time-consuming, approach.

> A couple of tests done by building
> the gdb tarball appear to show that "make distclean" is the only way
> to ensure that the new build obeys the new flags.

For projects I maintain, I make sure that 'make clean' should be
sufficient, and using 'make distclean' is overkill for just changing
CFLAGS.  But there are probably existing projects out there that require
the extra level of cleanup provided by 'make distclean'.

> 
> If so, my question is: is there a programatic way to check whether or
> not the flags I am asking configure to use are different from the old
> ones so that I can "make distclean" only when needed ?

My other favorite thing to do in projects I maintain is to use VPATH
builds.  Then I can do CFLAGS=-O0 in build0 and CFLAGS=-O2 in build2,
and keep both directories intact without ever having to run 'make clean'
(just switch directories when I want to test different flags).  But that
requires that your project works well with VPATH (not all of them do).

-- 
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]