bug#21687: Proposed patch to nt/runemacs.c: a way to augment environment variables prior to starting Em

[Eli Zaretskii]

> Date: Wed, 14 Oct 2015 18:59:26 -0700
> From: Evgeny Roubinchtein <zhenya1007@gmail.com>
> 
> My "use case" is that I compiled 64-bit Emacs under Windows following
> instructions at
> http://sourceforge.net/p/emacsbinw64/wiki/Build%20guideline%20for%20MSYS2-MinGW-w64%20system/,
> but I want to avoid copying libraries from ${msys2_root}/mingw64/bin
> to the Emacs installation directory, and I also don't want to add
> ${msys2_root}/mingw64/bin to the PATH for my user account (let alone
> system-wide).

Can you explain why you don't want to do any of these 2 things?  I'm
not sure I understand the use case.  Doing one or the other is the
standard way of installing programs and their dependency libraries,
and the former of the 2 is the platform recommended method, so it
sounds strange that you don't want that.

> The attached patch gives me a way to augment system environment
> variables before runemacs starts the actual emacs executable.

> With this patch applied, I can set the environment variable EMACS_ENV
> to ">PATH>${msys2_root}/mingw64/bin", and have that directory appended
> to the PATH but only in the environment of the runemacs process.  That
> environment is inherited by the emacs process, so I can allow Emacs to
> find the libraries it needs in order to run without copying them to
> the Emacs installation directory and without altering the PATH for my
> user account.

Thanks, but I think this solution will do more harm than help, even
for you.  Setting PATH of the Emacs process affects much more than
just the places where Emacs looks for DLLs.  It also affects where it
will look for programs it invokes, such as Grep and Diff, that have
nothing to do with optional libraries.

Moreover, from the user perspective, runemacs.exe and emacs.exe are
the same program, so having each one run with a different value of
PATH will confuse and might even annoy.

If you want to affect just the place where the DLLs are loaded from,
you can instead redefine dynamic-library-alist (see w32-win.el for its
default value) in your init files to include full absolute file names
of each DLL; then Emacs will load only that DLL from its specified
directory.  I think this will solve your use case without affecting
others.  This solution can be used with the current Emacs code.

If your use case is important enough, we could consider adding a
facility that would allow the user to customize the directory or
directories where Emacs looks for DLLs, using methods that don't
affect PATH (e.g., the SetDllDirectory opr SetDefaultDllDirectories
APIs).  That'd be somewhat hairy, because we'd need to hook those into
Posix-style environment variables like LD_LIBRARY_PATH, but it will be
still cleaner than your suggestion.  So please describe your use case
in more detail for us to understand whether it needs any changes in
existing code.

Thanks.