From xemacs-m  Thu Apr 24 02:58:54 1997
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5])
	by xemacs.org (8.8.5/8.8.5) with SMTP id CAA21666
	for <xemacs-beta@xemacs.org>; Thu, 24 Apr 1997 02:58:53 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA00525 for <xemacs-beta@xemacs.org>; Thu, 24 Apr 1997 00:58:25 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id AAA26993; Thu, 24 Apr 1997 00:58:19 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA01178; Thu, 24 Apr 1997 00:58:19 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id AAA13280; Thu, 24 Apr 1997 00:58:17 -0700
Date: Thu, 24 Apr 1997 00:58:17 -0700
Message-Id: <199704240758.AAA13280@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: XEmacs 20.2b1 config problems.
In-Reply-To: <kiglo69kopw.fsf@jagor.srce.hr>
References: <199704231357.PAA08293@rubens.esat.kuleuven.ac.be>
	<kigyba9x1wj.fsf@jagor.srce.hr>
	<199704231513.RAA08958@rubens.esat.kuleuven.ac.be>
	<kig7mhthio8.fsf@jagor.srce.hr>
	<m267xdws83.fsf@altair.xemacs.org>
	<199704232140.OAA11580@xemacs.eng.sun.com>
	<kiglo69kopw.fsf@jagor.srce.hr>
X-Mailer: VM 6.24 under 20.1 XEmacs Lucid (beta15)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

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

Hrv> Martin Buchholz <mrb@Eng.Sun.COM> writes:
>> Yes, this is completely rewritten for 20.3.  Unfortunately, although
>> autoconf2's basic approach is very good, there are a number of
>> deficiencies with existing tests.  In particular, autoconf2 knows
>> about /usr/openwin, but doesn't know about $OPENWINHOME.  I just added 
>> a test for that particular case to configure.in.

Hrv> The right thing would be to add a particular test to aclocal.m4,
Hrv> wouldn't it?  The current XEmacs configure.in is really terrible.  I
Hrv> think we should avoid repetition of something like that.

We don't have an aclocal.m4 yet, and I'm not sure that creating a new
file is worth it - those macros can be placed just as well into
configure.in. 

What I am sure of is that configure-time detection of most features is
the way to go.  The inflexibility of CPP makes the current system of
s&m files a real mess.  It will be less of a mess when my changes are
integrated.  It still won't be pretty.

Martin

