Ville Skyttä writes:
./configure '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu'
'--program-prefix='
'--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec'
'--localstatedir=/var' '--sharedstatedir=/usr/com'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--with-system-packages=/usr/share/xemacs'
'--with-docdir=/usr/lib64/xemacs-21.5-b28/doc'
Wow, that's just asking for trouble.
Mike can tell you the rationale better, but basically, if you specify
anything other than --prefix, you had better specify everything. If
something is *not* specified, then XEmacs will try to compute a
position relative to the binary for it at runtime (it does not default
to looking in the GNU standard places, eg under ${datadir}). You need
to specify --with-lispdir=/usr/share/xemacs-21.5-b28/lisp and
--with-etcdir=/usr/share/xemacs-21.5-b28/etc (at least; also note the
"--with-", needed because these aren't in the standard autoconf
hierarchy).
Note also that for reasons I don't understand, the (unused) values for
those in src/paths.h are shown as /usr/lib/xemacs-21.5-b28/{etc,lisp}
(*not* /usr/share/...). That's a bug even under current spec.
Mike, I think we need to rethink this. People expect setting the
high-level directories like --datadir to force their "standard"
children (like lisp and etc) to be relative to the specified value,
unless otherwise specified. They do not expect them to be relative to
the binary if --datadir is given.
Something like using the standard hierarchy, but if --with-prefix=no,
then *all* specified directories must be descendents of ${prefix}, and
${prefix} is stripped off the front in the code in the binary.
Alternatively, if --with-prefix=no, then all directory specifications
must be relative paths, and they will be interpreted relative to
${prefix}. (I suspect autoconf will be a pain in the ass about
letting us do the latter, though.)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta