>>>> "sb" == SL Baur <steve(a)xemacs.org>
writes:
sb> [I'm still planning on moving the non-c tm executables out of the core
sb> prior to release, unless you've changed your mind.]
sb> Michael Sperber <sperber(a)informatik.uni-tuebingen.de> writes in
xemacs-beta(a)xemacs.org:
> For 21.2, I suggest that we:
> 1. Generate `exec-path' from $PATH, and don't change
anything.
> 2. See to it that packages use `exec-directory' for stuff from lib-src.
sb> A single directory is a lose. We have to deal with external Lisp
sb> packages that may wish to install executables into the search path
sb> too.
Ah! Forgot about that. Another path it must be, then. The argument
remains the same, though.
sb> At the moment the issue has been mostly ignored, but it shouldn't be.
> 3. Move movemail into the main bin directory, and search for it
> through `exec-path', as Martin suggests.
> Certainly, prepending architecture-specific stuff to
`exec-path' is
> bad juju.
sb> Why? Except for the movemail case, it would seem reasonable to me.
Because XEmacs presents a different view of what the system path is
from what the underlying system does. If XEmacs has its own ideas
about where it looks for executables, it should clearly distinguish
that view from the system's view. The movemail case demonstrates that
you're always going to lose in some cases if you throw them all in one
pot.
I have designs for a more general infrastructure to handle this kind
of problem, and intend to hack it into 21.2. It's obviously more
pressing for `load-path', but I think a general, more flexible
solution is possible for `exec-path' as well.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla