emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Óscar Fuentes
Subject: Re: [feature/native-comp] breakage on build
Date: Fri, 05 Feb 2021 23:56:15 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Phillip Lord <phillip.lord@russet.org.uk> writes:

> It's attractive in the first instance to conflate these three. We
> could install all the dependencies for Emacs and all the tools we want
> using pacman. But, I think this is wrong, because Emacs itself (i.e.
> emacs.exe) is a fixed point in time; it needs to have a fixed set of
> dependencies and they should not update for a given emacs.exe. This
> fits poorly with the msys2 rolling release. So, problem one requires
> us to extract dependencies from a given release of msys2 then freeze
> them.

Required rebuilds are relatively rare. For instance, AFAIR the only time
that the MSYS2 emacs package had trouble with updated dependencies was
when ImageMagick went to version 7, which was incompatible with Emacs.
And that was a problem with an optional dependency that affected all
platforms, it was not at all like emacs -Q crashed at startup.

Second, it is not mandatory to do `pacman -Suy' every morning. I mean,
if a user updates his packages, it is at his own risk.

Third, by delegating the updates to the MSYS2 folks you don't need to
worry about security and bug fixes on all those dependencies.

Agreed, MSYS2 is a fat beast to depend on, but it provides a truckload
of functionality and saves you from dealing with a tangled hell of
dependencies. It is reasonable to expect that those dependencies will
grow and become more complicated on the future (native-comp is a glaring
example.)

> At the moment, number one is working, number two I think needs to be
> solved as lots of people will want native comp on windows, and number
> three is (and may remain) aspirational.

The goal you are pursuing is difficult enough and, IMHO, you are
complicating it further by adding (somewhat fuzzy) requirements that lie
beyond the point that seems reasonable to me, speaking as an Emacs user.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]