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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I suggest to put as.exe on PATH.
>> 
>> 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, 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)).

> In general, as.exe is part of Binutils, and as such, is installed in
> $exec_prefix/bin.  It is not an auxiliary program installed in
> $exec_prefix/libexec.  So IMO putting it on PATH is exactly TRT.
>
> 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.