From xemacs-m  Sat May 17 22:49:07 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 WAA25523
	for <xemacs-beta@xemacs.org>; Sat, 17 May 1997 22:49:06 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA00331 for <xemacs-beta@xemacs.org>; Sat, 17 May 1997 21:02:57 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id UAA10177; Sat, 17 May 1997 20:48:13 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA03047; Sat, 17 May 1997 20:48:12 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id UAA06891; Sat, 17 May 1997 20:48:25 -0700
Date: Sat, 17 May 1997 20:48:25 -0700
Message-Id: <199705180348.UAA06891@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: xemacs-beta@xemacs.org
Subject: New configure
In-Reply-To: <m2g1vlikds.fsf@altair.xemacs.org>
References: <m2g1vlikds.fsf@altair.xemacs.org>
X-Mailer: VM 6.31 under 20.2 XEmacs Lucid
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "sb" == Steven L Baur <steve@xemacs.org> writes:

I should have been able to find the missing backquote myself, by using 
bash to do the configure.  Sorry.

Overall, I'm quite happy at how smoothly it's gone.  Offix and Canna
worked despite my not having tested them.

sb> Here is a miscellaneous list of problems.

sb> 1.  Motif is relentless detected :-(.  Configuring with MULE that
sb>     means you must configure --with-xim=xlib or --with-xim=no in order
sb>     not to get it(s 100% braindamaged focus code).  I thought the
sb>     default for XIM was supposed to be `no' since this code is highly
sb>     broken on so many systems.

--with-xim=motif is problem-free on Solaris.  I'm quite sure I want it
to be the default there.  We know --with-xim is buggy on Linux.  What
are other systems like?  I get the impression that this is one area
where the commercial Unix vendors have done a better job than the
freeware community.  In any case, we want the default for --with-xim
to be system-dependent, as well as Motif-dependent.

Is there any way to autodetect a broken XIM implementation?

sb> 2.  The order of include directories is messed up in src/Makefile.in.in.
sb>     The site-includes get placed at the very first.  This is O.K. with 
sb>     one exception which loses terribly with current code.  I've fixed
sb>     this and See 3.

Correct diagnosis.  The proper order is XEmacs dirs, site dirs, system 
dirs. Change

cppflags = $(c_switch_all) $(src_cppflags) 

to

cppflags = $(src_cppflags) $(c_switch_all)



sb> 3.  Wnn is not successfully autodetected.  If you specify --with-wnn=yes,
sb>     no attempt is made to add the directory /usr/X11R6/include/wnn to
sb>     the include search path.  When this directory is added to the
sb>     site-includes all hell breaks loose since Wnn4 has a file called
sb>     config.h in it.  XEmacs gets pretty huffy when it #includes
sb>     that file instead of its own.  Therefore -I. has to be placed very 
sb>     early in the CFLAGS.  (I've changed this).

I think it's a mistake for configure.in to search explicitly for
/usr/X11R6/include/wnn, so I deliberately removed it.  We should choose one of:
- mule-wnnfns should #include <wnn/jllib.h> instead of #include <jllib.h>
- We should autodetect whether the wnn/ prefix is needed, in the same
  way that we do for tt_c.h.  

Wnn experts, please provide some expertise.  The Wnn detection code
was written by me, but completely untested.  It tries to autodetect
whether you have WNN4 or WNN6, and that code is unlikely to work, but
should be very close to working.

Here's the configure.in snippet:

  dnl Autodetect WNN
  test "$with_wnn6" = "yes" && with_wnn=yes # wnn6 implies wnn support
  test -z "$with_wnn" && { AC_CHECK_HEADER(wnn/wnnerror.h, ,with_wnn=no) }
  test -z "$with_wnn" && { AC_CHECK_LIB(wnn,jl_dic_list,[:],with_wnn=no) }
  test -z "$with_wnn" && with_wnn=yes
  if test "$with_wnn" = "yes"; then
    AC_DEFINE(HAVE_WNN)
    libs_x="-lwnn $libs_x"
    extra_objs="$extra_objs mule-wnnfns.o"
    AC_CHECK_LIB(wnn, jl_fi_dic_list, with_wnn6=yes)
    test "$with_wnn6" = "yes" && AC_DEFINE(HAVE_WNN6)
  fi


sb> 4.  As promised, it's a good deal slower than the previous version.  I
sb>     don't care, but I thought I'd point it out.

Dynamic autodetection will always be slower than hard-coding.  Much of 
the new code is a lot more careful, which requires it to run more tests.

sb> There is (a lot) more stuff I wanted to put in 20.3-beta1, but if
sb> there are those who are delighted at the prospect of getting 20.5MB of
sb> `gzip -9'/slightly broken code and fixing it, I'll put out beta1 tonight.

I strongly favor a beta1 with just my patch.

Re: sound support: Native sound detection should not ever check local
hardware (even if it could), only libs and header files to link with,
since the resulting binary will in general be run on other systems.  I
build all my official binaries on machines hidden away in some room I
may not even have access to, and don't care about the installed
hardware.

Martin

