From xemacs-m  Fri Jun  6 15:00:31 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 PAA13638
	for <xemacs-beta@xemacs.org>; Fri, 6 Jun 1997 15:00:30 -0500 (CDT)
Received: from Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA16208; Fri, 6 Jun 1997 13:18:59 -0700
Received: from kindra.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
	id MAA17857; Fri, 6 Jun 1997 12:59:05 -0700
Received: from xemacs.eng.sun.com by kindra.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA14052; Fri, 6 Jun 1997 12:59:03 -0700
Received: by xemacs.eng.sun.com (SMI-8.6/SMI-SVR4)
	id MAA11040; Fri, 6 Jun 1997 12:59:02 -0700
Date: Fri, 6 Jun 1997 12:59:02 -0700
Message-Id: <199706061959.MAA11040@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: bwarsaw@python.org
Cc: xemacs-beta@xemacs.org
Subject: Re: XEmacs 20.3-beta4 ("Warsaw") is released
In-Reply-To: <199706061852.OAA11579@anthem.CNRI.Reston.Va.US>
References: <m2u3jc762w.fsf@altair.xemacs.org>
	<199706061852.OAA11579@anthem.CNRI.Reston.Va.US>
X-Mailer: VM 6.31 under 20.3 XEmacs Lucid (beta3)
Reply-To: Martin Buchholz <mrb@Eng.Sun.COM>

>>>>> "BAW" == Barry A Warsaw <bwarsaw@CNRI.Reston.VA.US> writes:

BAW> 2. Had to hack src/Makefile to add -R/usr/dt/lib:/usr/openwin/lib to
BAW>    the temacs built line otherwise temacs would have unlocatable
BAW>    dynamic lib dependencies.  I think this was thrashed out a while
BAW>    back, but I don't remember the outcome.  In any case, having
BAW>    -L/usr/dt/lib without -R/usr/dt/lib (and similar for
BAW>    /usr/openwin/lib) is broken because it forces me to set
BAW>    LD_RUN_PATH.  Blech.

The semantics of --site-runtime-libraries is that you have to specify
*all* of them, not just additional ones, as with site-libraries.
Perhaps this is a DOCU-bug, but it certainly gives control to the
configure-er.  Please verify that
--site-runtime-librarries=/depot/gnu/plat/lib:/depot/sundry/plaies:/usr/dt/lib:/usr/openwin/lib'
works for you.

Please flame me, but with constructive suggestions, please.
My proposal:
- Rename --site-runtime-libraries to --runtime-libraries, and document 
  the current behavior better.
- Currently specifying --site-runtime-libraries is equivalent to
  setting LD_RUN_PATH, so there is a precedent with standard ld.
- On some systems (SGI) specifying multiple -R flags doesn't work, so
  gluing together the configurer's path with the system path may be
  slightly difficult to implement.
- With the current scheme, specifying the complete runtime search path
  explicitly is easy.  With a scheme where the site runpath is added
  to the system runpath, specifying this precisely is *much* more
  difficult.  Given that folks who use --site-runtime-libraries are
  already likely to be experts, this is not too great a hardship.  
- With the build-time lib and include search paths, people have
  complained about the opposite problem - configure adds in
  -L/usr/dt/lib -I/usr/dt/include, and the configurer has no way out, 
  other than overriding these directories with --site-* directories.

Another idea:

We could try to have the best of both worlds and have options like:

--site-libraries
--libraries
--site-includes
--includes
--site-runtime-libraries
--runtime-libraries

where the --site-* options are additive and override the default
paths, and the non-site options are absolute, i.e. configure.in is not 
allowed to tinker with or add to them.  I don't feel like implementing 
this, though.

BAW> 3. $EMACS/site-lisp wasn't empty.  It had a .precious file in it.
BAW>    Okay, okay minor nit, but my build procedure rmdirs site-lisp and
BAW>    symlinks it to my shared location.

I think Steve has given birth to this baby.

BAW> Other than that, it seems to work great.

Martin

