Hrvoje> I wouldn't like to deal with these surprises in a program like Hrvoje> XEmacs. Autoconf caching is a serious pain even in a small program Hrvoje> like Wget where I sometimes had to break its legs just so that some Hrvoje> tests in a loop work. A> Humm... Could you describe the nature of the problems? I just don't A> understand how it turns out that almost no other program except XEmacs A> disables autoconf caching... Autoconf caching is a really really bad idea, except when you're sharing a single set of configuration information among several programs, as is the case, for example, of the "Cygnus toolchain". Even then, it's only for people who know what they're doing. I disabled caching in XEmacs years ago. It was one of the biggest maintainability improvements in the XEmacs configure process. Perhaps my single biggest contribution to free software is convincing the Autoconf people to disable caching in autoconf by default. It took me a couple of tries, and a changing of the guard in the autoconf maintainership. Look for posts by me to the autoconf mailing list for details. This change is in autoconf 2.50, I believe. Short answer: if nothing has changed in the configuration, there's no need to run configure. And if something has changed, you need to re-run every test anyways, because configure can't know what has changed. Alternatively, show me a test that doesn't need to be run again, because you "know" it must give the same result.

SJ> Martin Buchholz <martin(a)xemacs.org&gt; writes: SJ> In general I agree, but it's really a PITA when it takes ~1h to run SJ> configure and you only wanted to make a minor change (so you edited SJ> config.cache to make it redo that test). Also, developing SJ> configure.in stuff (as I've been doing a couple of times with xemacs SJ> for the past days) is slowed down. One HOUR??? The worst I've seen is 5 minutes or so. Seems like there's a serious performance problem with your system. How long does compiling xemacs take? I've done by far the most configure.in hacking on xemacs, and I've never particularly missed the speedup of config.cache. If it's the compiler that's slow, do your configure hacking using configure --cflags= Then revert to optimized builds once you've debugged that. Also, when hacking configure.in, you have to THINK REALLY HARD, because you have to get it right the first time, because the code has to work on many different machines. If you're having an edit-compile-debug cycle, you're code probably isn't going to work anyways. Use your brain, not the computer, to find the bugs.

Alexey Mahotkin <alexm(a)hsys.msk.ru&gt; writes: XEmacs replaces many of the Autoconf checks with its own versions. It does not do this out of perversion, but because these checks would not work for XEmacs as written. Take a look at configure.in, it has a lot of such examples. The effect of cache on such mixture between "native" Autoconf and XEmacs-brewed macros is unknown, and I wouldn't want to test it. Even outside the context of XEmacs, the cache feature trips you if you attempt to do anything that was not envisioned by Autoconf authors. As I said, even in tiny ``Wget'' I had to disable caching of variables when performing an Autoconf test in a loop. And it was *very* non-obvious that I had to do this, it took me hours to figure out that cache was causing the failures.

Alexey Mahotkin <alexm(a)hsys.msk.ru&gt; wrote: Most programs actually don't disable caching because they usually don't have the complexity of XEmacs checkings, or they don't have enough Autoconf expertise to do so. However, it is now so commonly agreed that caching is evil that the newest version of Autoconf itself disables caching by default. You have to pass an option explicitely to configure if you want caching. -- Didier Verna, didier(a)lrde.epita.fr, http://www.lrde.epita.fr/~didier EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 53 14 59 47 94276 Le Kremlin-Bicêtre, France Fax.+33 (1) 44 08 01 99 didier(a)xemacs.org