On 02/06/2011 11:11 PM, Ralf Wildenhues wrote:
Apparently, a lot of users do not even know about configure -C aka.
--config-cache which of course doesn't help Autoconf's reputation about
producing configure scripts which are slow even for development.
So one question would be what about making -C the default?
I am opposed to it.
We could have --force or --no-cache to turn it off.
This behavior actually used to be the default. It was reverted around
commit 5ae14bc8c048ed9a2dda6b67794ba (and also see
commit 4abad4e9bfbcedd018302059844f8), 10 years ago.
Here's some discussion from back then, listed in the order in which I
traced back things, that is, the last thread has the most info:
http://sourceware.org/ml/autoconf-patches/2000-04/msg00000.html
http://sourceware.org/ml/autoconf-patches/2000-03/msg00274.html
http://sourceware.org/ml/autoconf/2000-02/msg00271.html
Back then, the consensus was to not make it the default because that was
deemed too dangerous for users.
IMO, all what had been said 10+ years ago still applies.
Besides that, config.caches only provide real advantages to "complex
packages", but do not provide many advantages to "occasional autoconf
users".
Various reports are cited, and also the
problem is mentioned that such kinds of failures tend to be quiet very
often and are hard to debug.
Correct.
Even experienced people, who believe have understood config.caches and
who actively take them into account during their works (Most users
don't), often make mistakes related to them.
Comments are appreciated.
Please don't go this road. Config.caches should remain optional.
Provided how HW has developed since the discussions from 10 years ago,
you cited about, I am actually leaning towards proposing the converse of
your proposal: Autoconf to consider to abandoning config.cache.
Ralf
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
