Re: [feature/native-comp] breakage on build

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Thu, 04 Feb 2021 23:08:15 +0100
> 
> >> This would be problematic. In general, applications that put things on
> >> PATH (or modify PATH in general) are frowned upon by many power users,
> >> for good reasons.
> >
> > Do you have any alternative suggestion that won't be frowned upon?
> > Then please describe it.
> 
> Put all binaries on the same directory as emacs.exe/runemacs.exe

That won't work, not in general: searching executables doesn't
consider the directory from which the program was invoked, it only
considers the current working directory.

> except
> probably those which are executed by a driver and that driver expects
> them to be on certain path relative to the driver's path (AFAIK gcc.exe
> does that, dunno about libgccjit.dll (or whatever its name is)).

All of GCC does that.  Which means people who have a full development
environment installed will now need to have two copies of it, at least
potentially, unless they configure their directories in a very
specific manner.  I don't see how this is better in general than
telling people to put stuff on PATH.

> > And if you think Emacs shouldn't put things on PATH, then what should
> > we do with what we already put there (runemacs.exe, emacsclient.exe,
> > addpm.exe, etags.exe, and a few others)?
> 
> My Emacs installs on Windows never required to touch PATH. Now that I
> use Emacs from the MSYS2/MinGW-w64 environment (which means that
> runemacs.exe is executed from the mingw64/bin directory) PATH and
> exec-path are modified by my emacs.el but, outside of Emacs, PATH is
> unaltered (it contains nothing related to MSYS2/MinGW-w64).
> 
> It is true that currently the user must modify exec-path to run
> executables that exist on the same directory as emacs.exe (when executed
> from a Windows shortcut, not from a MSYS2/Mingw-w64 shell), but that is
> a burden that we can solve.

This arrangement evidently works for you, but it doesn't mean it is
the best one.  For example, AFAIU it generally doesn't allow invoking
the commands outside of Emacs.  I don't think it's a good idea to have
all those useful programs ghettoized to work only from Emacs, because
Emacs is just one tool in the user's tool-chest.