>>>>> "Martin" == Martin Buchholz <martin(a)xemacs.org> writes:
>>>>> "Kyle" == Kyle Jones <kyle_jones(a)wonderworks.com> writes:
Kyle> Martin Buchholz writes:
>>> They used to live in the same directory, and the old code worked. I
>>> veto changing PATH, since this is a user-controlled variable that we
>>> should avoid changing if at all possible.
Kyle> I don't see how we're going to avoid changing it and still have
Kyle> packaged executables be able to execute other packaged executables.
Kyle> We're talking about modifying PATH for subprocesses of XEmacs.
Kyle> Adding package lib-src directories to PATH makes sense in this
Kyle> context, just as modifying TERM makes sense in the content of M-x
Kyle> shell and M-x terminal-emulator. I can't see how a package
Kyle> author would solve the configuration problem that will
Kyle> result if PATH isn't modified.
Martin> Sure we could have another way. For example, we could adopt another
Martin> environment variable EMACSPACKAGEBINPATH, and our scripts can invoke
Martin> other executables using the careful idiom
Martin> PATH="${PATH:-/usr/bin:/bin}${EMACSPACKAGEBINPATH:+:$EMACSPACKAGEBINPATH}" other_executable
Martin> Do we actually have a documented standard about where in the package
Martin> hierarchy executables should go?
Martin is absolutely right. In fact, there was a thread on this very
same question quite a while ago which sort of died.
In fact, the package binaries should not even be appended to
EXEC-PATH. If a package wants a binary, it should know what directory
to look in, rather than looking in a semi-random global path which
might actually include another binary with the same name in front of
it. mmencode is a prominent example, where we've avoided problems in
the past merely by virtue of the fact that Metamail hasn't changed
recently.
I intend to hack this in the next Great Path Overhaul which I'll get
to once 21.0 is out.
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla