From xemacs-m  Sun May 18 08:21:59 1997
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id IAA03051
	for <xemacs-beta@xemacs.org>; Sun, 18 May 1997 08:21:59 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA07302 for <xemacs-beta@xemacs.org>; Sun, 18 May 1997 06:35:59 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id GAA13363; Sun, 18 May 1997 06:21:21 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id GAA18702; Sun, 18 May 1997 06:21:25 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id GAA09841; Sun, 18 May 1997 06:21:22 -0700
Date: Sun, 18 May 1997 06:21:22 -0700
Message-Id: <199705181321.GAA09841@xemacs.eng.sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: Martin Buchholz <mrb@Eng.Sun.COM>
To: Hrvoje Niksic <hniksic@srce.hr>
Cc: XEmacs Developers <xemacs-beta@xemacs.org>
Subject: Re: config.cache missing?
In-Reply-To: <kigzpttue0e.fsf@jagor.srce.hr>
References: <kigiv0hw00j.fsf@jagor.srce.hr>
	<199705181302.GAA09835@xemacs.eng.sun.com>
	<kigzpttue0e.fsf@jagor.srce.hr>
X-Mailer: VM 6.31 under 20.2 XEmacs Lucid
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:

Hrv> Martin Buchholz <mrb@Eng.Sun.COM> writes:
>> >>>>> "Hrv" == Hrvoje Niksic <hniksic@srce.hr> writes:
>> 
Hrv> 20.3-b1 doesn't seem to have created the config.cache file.  Where is
Hrv> it?
>> 
>> config.cache is evil.  I have disabled configure caching.  I actually
>> think we shouldn't implement it, or if we do, that we don't make it
>> the default.

Hrv> ??

Hrv> config.cache was one of the reasons I looked forward to supporting
Hrv> Autoconf2.  Then, there are the site caches.  I think it'd be mighty
Hrv> fine if I could specify on my site: yes, I have string.h, yes, I have
Hrv> unistd.h, yes, I have.................   Instead of having free
Hrv> utilities checking for them over and over again, ad nauseam.

I'm willing to let you implement this later, as long as it's not the
default.

Gotcha: There are cases where we get wrong answers by caching test
results EVEN DURING ONE CONFIGURE RUN.  For example, at one point in
my configure hacking the following code would fail because the first
AC_CHECK_LIB would cache results used by subsequent ones, which you
very much do not want.  

if test "$with_png" != "no"; then
  for extra_libs in "" "-lz" "-lgz"; do
    AC_CHECK_LIB(png, png_read_image,
      png_libs="-lpng $extra_libs" with_png=yes; break,[:],$extra_libs)
  done
fi

Caching results is always slower and more reliable than not.  I think
GNU software configuration has become effectively a lot less reliable
for many people because of the introduction of caching.  Caching
should be reserved only for developers who know what they're doing.
I've run configure hundreds of times over the last weeks, and I
personally do not want caching.

Martin

