-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Dave Hart on 5/1/2009 5:37 AM:
> I added -Winit-self unwisely to NTP's configure.ac without a test,
> resulting in spectacular failure for those with old-enough gcc [1].
> For those users, invalid results were cached left and right if they
> enabled config.cache. At the time I repaired my mistake, I wanted a
> version number to bump that would cause configure to ignore
> config.cache results from prior versions.
>
> I came up with a macro to be used immediately after AC_INIT has loaded
> any config.cache which takes a version number and persists it in a
> cache variable, clearing all other cache variables to flush the cache
> if an incompatible cache is detected. It seems to be working as
> intended for me in NTP's main configure.ac as well as two child
> configure.ac files.
Interesting concept. However, I'm worried about one thing - it is also
possible to invalidate the cache by updating external software (installing
a newer library used by your package, or even upgrading the OS without
corrupting the directory layout). Thus, in addition to anything your
package does, it is also possible that the cache can be wrong even without
a change in your package. I think it is a bit misleading to add
auto-clearing if we can't reliably auto-clear in all situations.
One other thing to remember: invalidating the cache most often affects
those who are tracking incremental development (snapshots), and not those
tracking released tarballs (where each tarball expands to a new directory
name, and thus does not share the cache with the previous version). In
other words, since the people most likely to be bit by invalid caches are
already those who are brave enough to track bleeding edge, you can expect
them to be able to understand and do more about the situation.
What's wrong with telling your users that if they track incremental
development, that they must run 'rm config.cache; ./config.status
- --recheck' any time you commit a change that invalidates the cache from
your end? Or put another way, I'm not sure you've convinced me that
autoconf needs to add this feature (although I have not outright rejected
it either, so more discussion may still sway my opinion). At any rate,
thank you for an example macro that uses a different namespace than AC_; I
wish more developers would do that. And if it works for you, you can
certainly continue to use it.
Some comments on your macro:
> case "$cache_file" in
> ../*)
> # Parent configure will have cleared cache once already.
> # This will misfire if a top-level configure is invoked
> # with --config-cache= value beginning with '../', is
> # there a better way to detect this configure was
> # invoked by a parent directory configure?
> ntp_cache_flush=0
Not off the top of my head. But remember, the only point of a cache is to
speed things up; not using a cache will still get correct results although
with more time. So although it takes longer, it doesn't hurt to guess
conservatively and get a wrong answer.
> case "$ntp_cache_flush" in
Since this variable is under your complete control, I would have written
if test $ntp_cache_flush = 1; then
...
fi
rather than a case statement.
> c_varname_list=`set |
> sed 's/=.*$//g' |
Why the g modifier? If you are deleting all characters starting at the
first =, then there aren't any other matches for = left in the line, so
the g will never match twice.
> fgrep _cv_ |
fgrep is not portable (on some platforms, it MUST be spelled 'grep -F';
see also how autoconf computes $FGREP, although it will dirty the cache if
you call AC_PROG_FGREP this early). Also, since you already used sed in
this pipeline, you may want to consider rewriting this to do the entire
filtering through a single sed script (sed can do pretty much anything
that grep can; it is more expensive to fire up sed than grep, but once you
already have to pay the cost of sed, it is cheaper to use one sed process
than a sed|grep pipeline).
> grep -v 'ntp_cv_.*_cache_version'
> `
> for c_varname in $c_varname_list
> do
> dnl use AS_UNSET([$c_varname]) eventually
> eval ${c_varname}=;
> $as_unset $c_varname
Why not use AS_UNSET right now?
- --
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@xxxxxxx
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkn66YAACgkQ84KuGfSFAYBbTQCfdU0qiM4HGUCpFoSfC5IJH0lh
+MYAoLcsmDoyPbpcB0MHkjhrIxuB6bxR
=r26G
-----END PGP SIGNATURE-----
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
