Re: config.cache considered harmful

[Harlan Stenn]

The biggest problem I've found with config.cache is with my "development
flock".

Sometimes I store cached values to speed up the configure process (the whole
point of config.cache, eh?).

Sometimes I change the logic in configure.in and discover that my cached
values are overriding my new logic.

This also bites both other developers as well as users who track
distributions via CVS instead of tarballs.

I'd almost like to see a "version" number in the cache, which I can "bump"
whenever I make a "significant" change to the logic which has the effect
of...

Just had an idea.  If the version number controls what sourcing in
config.cache does, we could write the config.cache using something like:

case "foo_cache_version" in:
 1)
   # foo_cache_version 1 variables get set below
   ...
   ;;
esac

(I generally use "case" instead of "if" because I remember the old days when
"test" was not always a shell builtin).

This might also solve the problem folks mentioned about the lack of "state"
information when doing subdir configures.

H