[Earth to Martin's ISP, are you unfucked yet?]
Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes in
xemacs-beta(a)xemacs.org:
...
- it checks for /usr/X11 (because apparently autoconf doesn't
find
this on Linux, HP because of a broken install by the vendor) and
sets x_... if it finds it.
This is wrong, at least in the case of Linux. I am having great
difficulty finding access to a properly configured HP machine which
perhaps speaks for itself.
- run the AC macro. This macro doesn't bother doing anything if
x_... is set, most importantly it does *not* run xmkmf.
Unfortunately, xmkmf is delivered broken on many systems.
As Jan pointed out the (relatively) portable way of finding X is to
use xmkmf, which would have worked perfectly in my case, but is never
done because of the preemptive Linux/HP fix.
I guess running xmkmf should be The Right Thing in your situation as
well. You probably have $OPENWINHOME set but presumably have your
X11R6.3 xmkmf in your PATH.
Playing devil's advocate, the test has got to be more comprehensive
than that. *I* have $OPENWINHOME set in my Linux environment, but there
is nothing in $OPENWINHOME/lib that XEmacs needs to link to. On the
gripping hand, it would be potentially less destructive adding that
directory than something like /usr/local.
It's also somewhat dubious to poke too deeply into the builder's
environment on a multiuser system/network.
BTW: Didier you always make me feel stupid for running the Sun
supplied
stuff, but in many cases I really don't see the need (e.g. cc,
Openwin3.6, ...) and our sysadmins are capable of fskcing up even the
most simple installation of 'free' replacements :-)
There are many good reasons for wishing to link against the
vendor-supplied libraries.
And I think *you* would be surprised by the number of people who run
*only* the vendor supplied version of everything. :-)
I wouldn't be.