Greg> In fact I would go so far as to suggest that "config.cache" is
Greg> only truly safe in its current form when it is used for nested
Greg> configure scripts, and then only when the nested scripts are all
Greg> directly realted in heritage to each other.
If by "heritage" you mean its direct ancestry, then I disagree. In my
experience you can mix relatively diverse configure scripts with few
bugs. I've only run into one problem along these lines in the Cygnus
tree in five years. (Yes, our sample is skewed. Still, it isn't that
hard to recognize these bugs for what they are.)
Greg> Until version information (including much more platform details
Greg> than just what config.guess reveals) is included in the cache
Greg> file, and carefully checked by every consumer, "config.cache"
Greg> shouldn't even be allowed to be turned on.
I disagree. We should always assume that expert users know what they
are doing. If I say --cache=file=foo, then I want configure to
listen. Requiring extra hoops is bogus.
Greg> Even when version information is included in "config.cache" I
Greg> think that "autoconf" should remove it unconditionally, as
Greg> should any makefile rule which is about to run "configure" but
Greg> detects that the script is newer than the cache file.
This would be painful in my daily programming practice. I don't mind
disabling the cache by default. But if it is enabled, I want it to
continue to work as it does now. Anyway, autoconf usually doesn't
know where my config.cache might be found. Only configure does.
Tom
