>>>>> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Martin> To support the --extra-verbose option
Tom> Why is this important? Can't people just read config.h?
I introduced the option for myself years ago, and I continue to find
it useful.
Martin> XEmacs also modifies several of the other basic autoconf
Martin> macros, to disable the _evil_ cache.
Tom> The evil cache must be some XEmacs feature, because the cache I use is
Tom> distinctly good. :-)
Tom> Seriously, I don't know the status of this. There was some talk of
Tom> allowing people to disable the cache in configure.in, but I don't
Tom> recall whether it was in Akim's deluge.
I've ranted about config.cache before, but it's probably time again,
because of the turnover of the maintainership here.
The config cache is _the_ most evil thing in autoconf.
The only time it's really nice is in a nested configure, where you
know the cache is accurate, because it's running as part of the same
build process - no one is ambitious enough to make configure smart
enough to survive an OS upgrade while it's running.
The config,cache is friendly mostly to Cygnus employees, hostile to
everyone else. Let's optimize for the newbies, not the pros.
How many newbies do
ftp; get foo-1.9.tar.gz; gunzip; tar xf;
cd foo-1.9; configure; make; make install
login to other machine
cd foo-1.9; configure; make; make install
# Phew! That was easy!
The worst thing about this scenario is that it will often silently
appear to work, except that a few of the config variables will be
wrong. Or the newbie might get lucky and get an obscure compile or
link error. This is a _giant_ usability issue.
Your reaction might be, "Of course you're supposed to do `make
distclean' before re-configuring", But this is an advanced thing that
the newbie should not have to know. The newbie can rightfully expect
to be politely told (by configure or make) "Don't do that", at the
very least, instead of shooting himself in the foot this way.
Let's think about when you would ever want to reuse a cache within a
simple single GNU package. I claim you _never_ want to reuse that
config.cache file sitting in your foo-1.9 directory. Why are you
re-running configure, anyways, instead of just running `make'?
Because the system has changed? Because configure.in has changed? In
any of these cases we can't trust config.cache. Better to discard it
than suffer the horrible consequences of a wrong guess. I can't think
of any reason to re-run configure that doesn't leave the config.cache
from a previous build untrustworthy.
The time when config.cache is useful is when you are building 10
packages together at the same time, typically a Cygnus toolchain. But
only professionals ever do these kinds of builds. There are maybe 100
people in the world who have ever built such monsters, while there are
hundreds of thousands who have built and installed binaries from
simple gzipped tarballs. And you need special flags to configure here
anyways, so that the sub-configures share a common cache.
I'm not proposing that the config.cache feature be removed, only that
it not be made the _default_. Tom can keep his config.cache for his
giant nightly builds, so he can present the boss with freshly baked
binaries the next morning at 9am.
After I disabled the cache in XEmacs, the number of obscure configure
errors went down dramatically. __Lots__ of newbies shoot themselves in
the foot as described above.
Another problem with the cache was that it can become invalid _during_
a single run of configure. Why? Because the XEmacs configure script
would look for features in multiple places. Is foo() in libbar? No?
Try adding -L/usr/openwin/lib to the link path. How about now? Maybe
try -L/usr/X11R6/lib instead? Oh, but the cache simply remembers what
function we were trying to look up in what library - it ignores the
fact that the link path has changed. In principle, the cache gets
invalidated whenever a compile or link path is changed, or a
preprocessing symbol is defined.
(I don't remember anymore exactly which repeated test failed due to
caching, but I do remember that the infuriatingly frustrating
experience made me eradicate all traces of config.cache from my
configure script.)
Keep in mind that debugging configure scripts is often next to
impossible, because the error occurs on someone else's machine, behind
some firewall somewhere. We need all the robustness we can get.
Think of the newbie and free software package maintainer, not the
dedicated release engineer, who can fend for himself.
Martin
Disclaimer: I don't actually know what Tom does for a living...
