From xemacs-m  Sun May 18 19:03:23 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 TAA14545
	for <xemacs-beta@xemacs.org>; Sun, 18 May 1997 19:03:22 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA19536 for <xemacs-beta@xemacs.org>; Sun, 18 May 1997 17:17:25 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id RAA23668; Sun, 18 May 1997 17:02:36 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA03136; Sun, 18 May 1997 17:02:39 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id RAA10029; Sun, 18 May 1997 17:02:35 -0700
Date: Sun, 18 May 1997 17:02:35 -0700
Message-Id: <199705190002.RAA10029@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: <kigwwowvrgq.fsf@jagor.srce.hr>
References: <kigiv0hw00j.fsf@jagor.srce.hr>
	<199705181302.GAA09835@xemacs.eng.sun.com>
	<kigzpttue0e.fsf@jagor.srce.hr>
	<199705181321.GAA09841@xemacs.eng.sun.com>
	<kigwwowvrgq.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:
>> I'm willing to let you implement this later, as long as it's not the
>> default.

Hrv> Hey, even I have better things to do with my time than implementing
Hrv> things only to be hidden under a configuration flag.

>> Gotcha: (...)

Hrv> How did GNU Emacs developers avoid the gotchas?

I don't think Autoconf, out of the box, can handle detection of
libraries that may have different supporting libraries on different
systems.  The workaround is to figure out the name of the cache
variable, and unset it before the call to AC_CHECK_LIB.  However, the
construct "unset VARNAME" is non-portable, and the Autoconf manual
explicitly forbids using it...

>> Caching results is always slower and more reliable than not.

Oops. ./write-article --time-of-day=5am  --with-caffeine=no

Hrv> I don't understand this sentence.  Have you meant ``less reliable''?

Yes.

>> I think GNU software configuration has become effectively a lot less
>> reliable for many people because of the introduction of caching.

Hrv> I don't see on what grounds you base this claim.  I've never had
Hrv> problems with configure caches, especially as `make distclean'
Hrv> typically removes config.cache.  Site-wide caches are installed by
Hrv> people who know what they are doing anyway.

But, in the typical case, ordinary users will shoot themselves in the
foot with the following rope:

gtar xzf foo-3.9.tar.gz

rlogin comix
cd foo-3.9
./configure --with-frob
make

rlogin mueslix
cd foo-3.9
./configure --with-knob
make clean
make

You can't trust "make distclean" with all gnu packages, as some remove 
too much, IIRC.

"Autoconf 2 gives you enough rope to shoot yourself in the foot."

I'm the local GNU software maintainer, and have developed enough
paranoia to actually re-untar the distribution for each new build, and 
run "configure --cache-file=/dev/null" just in case.

>> I've run configure hundreds of times over the last weeks, and I
>> personally do not want caching.

Hrv> Then you are either running it on very fast machines or are
Hrv> exceptionally patient.  For me checking might be important because of
Hrv> speed.  I was going to try to install a site-wide cache, too.  It
Hrv> would feel stupid that after all the fuss the program I use most
Hrv> doesn't facilitate it.

The percentage of time saved is much greater with small packages than 
with big ones, so there is less reason to implement the cache with
XEmacs.  And yes, I have had access to a very fast machine, which they 
are taking away from on Monday :-(

Martin

