autoconf
[Top][All Lists]
Advanced

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

Re: dpkg hooks


From: William Pursell
Subject: Re: dpkg hooks
Date: Sun, 30 Sep 2007 09:06:11 +0100
User-agent: Icedove 1.5.0.12 (X11/20070607)

Eric Blake wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to William Pursell on 9/29/2007 11:14 AM:
I'm talking about those files named $cache_file in
my $CONFIG_SITE.  Since they hold lines of the form:
ac_cv_func_foo=${ac_cv_func_foo=yes}
the cache is invalid if I remove the package
containing libfoo.

One of the easiest ways to do this is use a site configuration to enforce
a global cache file.  Then, when removing a package, you merely delete the
global cache (since the state it cached is out of date), and any package
you then recompile will have to rerun tests for uncached data, but can
share information learned from other packages and saved in the global cache.
http://www.gnu.org/software/autoconf/manual/html_node/Site-Defaults.html#Site-Defaults



I'm not convinced of the practicality of a single global cache file.
In fact, I found it completely impractical, as invoking configure
with different settings of CFLAGS would report that the cache
was invalid and needed to be purged.  As a result, I included
the following snippet in my $CONFIG_SITE:

cache_file=/var/cache/ac_cache
for i in CC CFLAGS CXXFLAGS CPPFLAGS LDFLAGS; do
    eval val='$'$i
    if test -n "$val"; then
        cache_file=$cache_file`echo ":$i=$val" | sed 's,[ /],_,g'`
    fi
done

this gives a distinct cache file for each of the listed settings.
This has worked well for me for a few weeks, but I'd welcome
any criticism of the technique.

Back to the original question, though...my problem (well, one of
them anyway) is that I usually forget to delete the cache files
after I remove a package, and I'm hoping for something much
less destructive than:

function dpkg() { rm -f /var/cache/ac_cache'*'; dpkg $@;}

In particular, I'm thinking it might be practical to
embed time stamps in the cache file name, and have the
$CONFIG_SITE file run a script that would compare the
timestamp to the dpkg database and clear out those lines
that need cleaning.  But...I can easily see that becoming
far more complicated than its worth, since I have no idea
how one would use the package information to know which
lines in the cache files need to be modified/deleted.

I think my underlying question boild down to:
is there anyway to update a cache file, or is the
accepted technique to simply remove it and start over?




reply via email to

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