emacs-devel
[Top][All Lists]
Advanced

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

Re: Suppressing native compilation (short and long term)


From: Eli Zaretskii
Subject: Re: Suppressing native compilation (short and long term)
Date: Sun, 02 Oct 2022 21:51:27 +0300

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 02 Oct 2022 13:32:02 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > My recommendation is to use the default JIT manner until and unless
> > actual problems are reported by users.
> 
> [...]
> 
> > There's no profit, IME.  There are only disadvantages: you are in
> > effect fighting against the Emacs defaults, for reasons that are
> > purely theoretical.
> 
> If I understand your meaning in both of these cases, I'll just note that
> for the things we've been discussing here, I believe we've already had
> complaints/requests from Debian users.  Whether that's significant
> enough to warrant accommodation is another question, but that may not
> leave the concerns theoretical, strictly speaking.

Please try to understand the nature of the complaints.  It is quite
possible that users simply use the (broken) analogy with the *.elc
files, because they misunderstand the quantitatively new aspects of
native-compilation.  There's more here than meets the eye, as has been
demonstrated even in this discussion.

Please don't hesitate to involve us in these discussions with your
complaining users, if you think we could help.

> And for what it's worth, I can see both sides of the argument(s), i.e. I
> can understand why upstream, it could be that on balance, those concerns
> won't (and maybe shouldn't) be considered sufficient when balanced
> against other considerations.

One other aspect that should be kept in mind is complexity.  The
introduction of the pdumper file in Emacs 27 and of native compilation
in Emacs 28 made Emacs deployment and startup code significantly more
complex, and as a side effect invalidated some of the deployment
methods people used to use, like some "clever" symlinking of the
binaries or the directories.  We are still learning these consequences
(although some of them already caused fixes in the code).  In this
situation, adding even more possible deployment method that upstream
should support risks making the startup code a maintenance burden.



reply via email to

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