From xemacs-m  Mon Mar 24 00:42:47 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 AAA16851
	for <xemacs-beta@xemacs.org>; Mon, 24 Mar 1997 00:42:47 -0600 (CST)
Received: from infodock.com (wave.infodock.com [206.13.40.192]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id WAA00135 for <xemacs-beta@xemacs.org>; Sun, 23 Mar 1997 22:42:18 -0800
Received: (from weiner@localhost) by infodock.com (8.7.4/8.7.3) id WAA29139; Sun, 23 Mar 1997 22:47:22 -0800
Date: Sun, 23 Mar 1997 22:47:22 -0800
From: Bob Weiner <weiner@infodock.com>
Message-Id: <199703240647.WAA29139@infodock.com>
To: xemacs-beta@xemacs.org
In-reply-to: <199703240635.WAA00442@wmperry.in.aventail.com>
Subject: Re: Suggestion on how configure should work.

>>>>> "WMP" == William M Perry <wmperry@aventail.com> writes:

   WMP>    I think you should have the configure stuff at least try to 'do the
   WMP> right thing' when a user tries to build from source.  Someone should be
   WMP> able to just type 'configure' and have XEmacs come up with all the bells
   WMP> and whistles available, sound under linux included.  If the person doing
   WMP> linux builds for the distribution doesn't get it autodetected, then that is
   WMP> there problem, and they should tweak the configure command, which they
   WMP> already have to do anyway.

I believe a much better configuration technique for the future would be for
configure to first do its probing for the features that your machine can
support and then produce an easily readable and editable file that explains
how to switch the available configuration options on or off.  (Options that
were not detected could appear in comments with an explanation of where
certain files have to be before such a feature can be enabled.  Then if the
user knows he wants to build that feature in, he can.)  After an edit of this
file, the builder then executes one additional command that scans the
file and generates the Makefiles.

Bob

