autoconf
[Top][All Lists]
Advanced

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

Wholesale sharing of config.cache across many packages


From: tsuna
Subject: Wholesale sharing of config.cache across many packages
Date: Tue, 9 Oct 2012 02:27:10 -0700

Hi all,
in my current continuous integration environment we run configure
scripts on the order of 10^5+ times a day.  Each build starts in a
clean workspace that is almost akin to a fresh Linux install.  We
don't ship a config.site, and we build many packages in parallel.  I
tried to use the "same" --cache-file to speed things up.

I wrap my ./configure invocations with a small dance that can be
summarized like this:
  if test -f /tmp/config.cache; then  # We already have something
    TMP_CACHE=`mktemp`
    cp /tmp/config.cache $TMP_CACHE
  fi
  if ./configure --cache-file=$TMP_CACHE [..other flags..]; then  # Success
    mv $TMP_CACHE /tmp/config.cache
  fi
  rm -f $TMP_CACHE

This way each run of configure operates on its own file to avoid race
conditions, but benefits from the cache variables populated by
previous runs.  Of course in practice the dance above is also written
in a way to be atomic, the code above is a simplification.

This works fine except for one thing: if one package decides to invoke
configure with different CFLAGS/CXXFLAGS (or any other precious
variable for that matter), I get the annoying:

configure: loading cache /tmp/configure.cache.ea93QN
configure: error: `CFLAGS' has changed since the previous run:
configure:   former value:  `-g'
configure:   current value: `-g -Wall -Werror'

In http://lists.gnu.org/archive/html/autoconf/2011-03/msg00042.html
someone asked whether there is a programatic way to do something when
this situation arises – without duplicating all the code in configure
to catch this case, obviously.  I'm not aware of any, but I'm looking
for a workaround.  Other than parsing's configure output when it
errors out and iterating again after patching the config.cache file,
which would be a very ugly kludge.

Any suggestions?  Thanks in advance.

-- 
Benoit "tsuna" Sigoure



reply via email to

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