Re: [21.4,21.5] configure.in (have_dl): Add modules to MAKE_SUBDIR ...
>>>> "SJ" == Simon Josefsson
<simon(a)josefsson.org> writes:
SJ> Martin Buchholz <martin(a)xemacs.org> writes:
> 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> 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.