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

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

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

Yes, that's because I suggest adding emacs.exe's directory to exec-path
(on Windows).

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

I'm not sure what's your objection here, but, as you very well known,
messing with PATH has a very real potential of subtly breaking things
when different applications depends on it, so this approach doesn't look
very appealing to me (speaking rhetorically, many years ago I learned
the hard way that keeping the contents of PATH to a bare minimum saves a
lot of teeth gnashing and hair pulling and even head banging.)

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

IIUC one of the problems Phillip has is to include certain tools on the
Emacs distribution (either on the binary package he uploads or on
auxiliary ones that can be installed on request, i.e. MSYS2/MinGW-w64)
on such a way that Things Work (TM). Setting exec-path would solve this.

Furthermore, if the MSYS2/MinGW-w64 way of providing tools ends winning,
Phillip could just simply build an MSYS2 package which current MSYS2
users would download and install while non-MSYS2 users would download an
"installer" that installs MSYS2/MinGW-w64 (from their servers) and then
the Emacs MSYS2 package on top. This has the advantage that all
dependencies can be listed on the package and `pacman' (MSYS2 package
manager) will install them automatically. With this and the mentioned
modification to exec-path, everything works, no PATH meddling required.

Sure enough, there are people that prefer the traditional tarball with
just Emacs binaries, but IMHO it is fair to say that those users must
deal with the dependencies themselves.