Re: How do you modify PATH on Windows XEmacs 21.4.3
module-load-path works for finding the dll that load-module() loads, but
doesn't handle any dependent DLL libraries that are linked into the dll.
Basically, our project has an XEmacs DLL external module which is
dependent on a few DLLs that we provide; but we need to put these DLLs
into the PATH so that the dlopen() of the external module DLL succeeds.
Otherwise you get a nice dialog box from Windows stating that it
couldn't find such-and-such.dll in the PATH.
We could modify setenv to take an optional boolean arg that would
indicate whether this change affects the Xemacs process, or just
subprocesses. Default would be false, and just affect the subprocesses
(the current behavior). True would cause a change to the XEmacs process
as well as causing XEmacs to reload that environment variable into the
lisp variable for the environment.
Thoughts?
Andrew
On Tuesday, October 23, 2001, at 09:51 PM, Ben Wing wrote:
"Stephen J. Turnbull" wrote:
>
>>>>>> "Andrew" == Andrew Begel
<abegel(a)eecs.berkeley.edu> writes:
>
> Andrew> Unfortunately, setenv only affects subprocesses, not the
> Andrew> XEmacs process itself. And since XEmacs is the process
> Andrew> loading my DLL, Windows looks at its PATH, not PATHs for
> Andrew> subprocesses.
>
> In general Emacs prefers to handle these things itself. Doesn't
> `module-load-path' have the documented semantics under Windows?
yes, i agree, we should do it ourselves if possible to avoid
unpredictable
library semantics.
>
> We don't have a function that actually changes the environment. I
> don't know why.
it's basically a matter of principle. we don't [didn't?] need it, so
it makes
for fewer surprises to always do things in process-environment and
never the
actual environment.
e.g. in my mule ws i actually replaced all calls to getenv[] with
egetenv[],
which checks process-environment, for encoding reasons.
I don't see why that would be dangerous, but I'm not
> an expert on hairy process stuff. It's plausible that it just got
> omitted because it's a noop in an Emacs without dl capability.
>
> I do know that Ben is rewriting the process stuff, see comments in
> src/callproc.c, so you should coordinate with him on any addition.
>
> --
> Institute of Policy and Planning Sciences
> http://turnbull.sk.tsukuba.ac.jp
> University of Tsukuba Tennodai 1-1-1 Tsukuba
> 305-8573 JAPAN
> Don't ask how you can "do" free software business;
> ask what your business can "do for" free software.
>
-----------
Andrew Begel
Computer Science Division
UC Berkeley