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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21687 in the body.
You can then email your comments to 21687 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Evgeny Roubinchtein <zhenya1007 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Proposed patch to nt/runemacs.c: a way to augment environment
 variables prior to starting Em
Date: Wed, 14 Oct 2015 18:59:26 -0700

[Message part 1 (text/plain, inline)]

Dear Emacs developers,

Would you consider applying the attached patch to nt/runemacs.c?

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).  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.

Please let me know if it would be possible to get this patch applied
to the Emacs sources.

Thank you in advance!

[0001-Allow-the-environment-of-the-runemacs-process-to-be-.patch (application/octet-stream, attachment)]

Message #8 received at 21687 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Evgeny Roubinchtein <zhenya1007 <at> gmail.com>
Cc: 21687 <at> debbugs.gnu.org
Subject: Re: bug#21687: Proposed patch to nt/runemacs.c: a way to
 augment	environment variables prior to starting Em
Date: Thu, 15 Oct 2015 18:30:19 +0300

> Date: Wed, 14 Oct 2015 18:59:26 -0700
> From: Evgeny Roubinchtein <zhenya1007 <at> 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.

Message #11 received at 21687 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 21687 <at> debbugs.gnu.org, Evgeny Roubinchtein <zhenya1007 <at> gmail.com>
Subject: Re: bug#21687: Proposed patch to nt/runemacs.c: a way to
 augment	environment variables prior to starting Em
Date: Tue, 23 Feb 2016 19:37:48 +1100

Eli Zaretskii <eliz <at> gnu.org> writes:

> So please describe your use case in more detail for us to understand
> whether it needs any changes in existing code.

More information was requested, but no response was given within a few
months, so I'm closing this bug report.  If the problem still exists,
please reopen this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.