Martin> The config,cache is friendly mostly to Cygnus employees,
Martin> hostile to everyone else. Let's optimize for the newbies, not
Martin> the pros.
I don't disagree. I like Alexandre's idea of enabling it only when a
cache file is specified on the command line. I don't like other ideas
I've heard in the past, which involve editing configure.in; that leads
to random, meaningless divergence in gcc-like trees.
Martin> ftp; get foo-1.9.tar.gz; gunzip; tar xf;
Martin> cd foo-1.9; configure; make; make install
Martin> login to other machine
Martin> cd foo-1.9; configure; make; make install
Martin> # Phew! That was easy!
This only really works if you generate a config.h and you are lucky.
If an intermediate object is lying around which needs to be rebuilt,
but whose ancestors are not touched by configure, you are screwed.
Martin> The worst thing about this scenario is that it will often
Martin> silently appear to work, except that a few of the config
Martin> variables will be wrong. Or the newbie might get lucky and
Martin> get an obscure compile or link error. This is a _giant_
Martin> usability issue.
But the cache, or something like it, is the way to solve this problem.
If you record system info in the cache, and notice when it is wrong,
you prevent the strange errors.
Or are you talking about machines where, say, config.guess prints the
same thing but where libraries and other things are installed in
different places? I don't see how removing a config.cache helps here,
really. You can still have incorrect intermediate objects in the
build tree, screwing the naive user. At some point they have to read
the directions.
Tom
