Re: MSYS2 PATH problems with native compilation

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> Duplicating executables here and there just to appease Emacs is a not
>> very appealing, to say the least.
>
> But above you say that placing these executables in the same directory
> as Emacs solves the problem,

No, I didn't said that.

> so you are going to duplicate them
> anyway, right?  Because the "normal" GCC installation doesn't
> necessarily put them in the same directory, right?

gcc.exe, ld.exe, as.exe etc are on the same directory as emacs.exe. This
is no coincidence, is how packages are installed on MSYS2/Mingw-w64,
which follows a similar approach to GNU/Linux.

> And if they _are_
> installed in the same directory, then what is again the problem of
> adding that single directory to the system-wide PATH?

You say that adding PATH automatically from emacs is a no-no, but you
are fine with forcing the user to set PATH globally (thus affecting the
whole system) ??

>> > I don't know what kind of GNU/Linux installations you have in mind,
>> > but I don't know about any reliable installation technique that causes
>> > all the installed tools to seamlessly work together, except by either
>> > modifying PATH or installing all the tools in the same common tree.
>> 
>> Precisely, MSYS2/Mingw-w64 installs everything in the same tree.
>
> So why on Earth not tell your users to add that single bin/ directory
> to system-wide PATH, and be done with that?

I have no method for telling the users, apart from patching Emacs to
show a prominent message. Anyways, a package that requires further
action after installation (and changing the global environment, no less)
is anything but user-friendly.

>> Well, that's something for the user to care about. Our job is to provide
>> an Emacs that works as installed, and right now native-comp is broken
>> unless the user sets PATH globally.
>
> Then I suggest to tell the users to set PATH globally.  That's the
> correct solution, on any system, because it makes the MinGW64 programs
> accessible from anywhere and by any program running on the system.

The correct solution is to make native-comp work out of the box.
Transiently setting PATH while generating .eln is a fix. What do you
have against it?