>>>>> "AD" == Akim Demaille <[EMAIL PROTECTED]> writes:
>>>>> "Martin" == Martin Buchholz <[EMAIL PROTECTED]> writes:
Martin> I've ranted about config.cache before, but it's probably time
Martin> again, because of the turnover of the maintainership here.
AD> Don't be afraid, we've been around for a few years too, and we know
AD> what you are talking about. We also know we agree on the problem, but
AD> not on the fix :)
Martin> The config cache is _the_ most evil thing in autoconf.
AD> Oh no, there are plenty of others which are much worse :)
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.
AD> This is a sound I like :) But conversely I am extremely attached to
AD> provide the users of Autoconf (i.e., the maintainers), a good service:
AD> because there are the guys who most run ./configure, they deserve some
AD> comfort, such as caches.
I am one of them too, remember. XEmacs' configure script takes 2min
46sec on my machine with gcc-2.95.2 -O3.
Martin> Your reaction might be, "Of course you're supposed to do `make
Martin> distclean' before re-configuring", But this is an advanced
Martin> thing that the newbie should not have to know.
AD> I agree on the problem, not on the solution. What Alexandre refers to
AD> seems a better approach to me. It should be on by default though.
I support Alexandre's idea.
Martin> Let's think about when you would ever want to reuse a cache
Martin> within a simple single GNU package. I claim you _never_ want
Martin> to reuse that config.cache file sitting in your foo-1.9
Martin> directory. Why are you re-running configure, anyways, instead
Martin> of just running `make'? Because the system has changed?
Martin> Because configure.in has changed? In any of these cases we
Martin> can't trust config.cache. Better to discard it than suffer
Martin> the horrible consequences of a wrong guess. I can't think of
Martin> any reason to re-run configure that doesn't leave the
Martin> config.cache from a previous build untrustworthy.
AD> OK, I understand your reasoning. Let's push it to its end point, and
AD> forget about separate compilation too. Actually, dependencies are so
AD> often wrong in Makefiles, we've suffered so many times of slight
AD> inconsistencies due to a missing dependency, that I think we should
AD> have the target all depend on `clean' in all our Makefiles.
Yes, I remember doing many times
rm *.o; make
until I decided that reliable dependencies was worth it.
Hmmm. I think I'm getting motivated to fix _all_ the dependencies in
the XEmacs build environment.
AD> :)
AD> Sorry, but I often rerun configure.
Martin> I'm not proposing that the config.cache feature be removed,
Martin> only that it not be made the _default_.
AD> If we can't reach an automatic solution which protects everybody from
AD> such failures, then I am all with you. For the time being I still
AD> hope we can make it without. I am not committed to death to cache
AD> files being the defaults. If they can safely be, let them be,
AD> otherwise, I know too well how some users suffer from this trap to
AD> require this behavior to be maintained.
Martin> Another problem with the cache was that it can become invalid
Martin> _during_ a single run of configure.
AD> Hm, obviously... But how come so few people ever complained about
AD> this? (Real question, not ironic).
Few configure scripts try hard to find things in multiple places.
Most people will either give up after encountering difficulties, or
deal with them heroically and stoically. I can still remember how
surprised I was when I diagnosed the behavior, since it came after I
had effectively forced cache-file=/dev/null.
Martin
