all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Evgeny Roubinchtein <zhenya1007@gmail.com>
Cc: 21687@debbugs.gnu.org
Subject: 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	[thread overview]
Message-ID: <83twps87zo.fsf@gnu.org> (raw)
In-Reply-To: <CAGYXaSY=yU1ESNhrkOP2SQHCixzi58vDwwmC+Nxya8SAiVeQOw@mail.gmail.com>

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





  reply	other threads:[~2015-10-15 15:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-15  1:59 bug#21687: Proposed patch to nt/runemacs.c: a way to augment environment variables prior to starting Em Evgeny Roubinchtein
2015-10-15 15:30 ` Eli Zaretskii [this message]
2016-02-23  8:37   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83twps87zo.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=21687@debbugs.gnu.org \
    --cc=zhenya1007@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.