Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 5 Oct 2022 20:56:00 +0200
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> > > > Why would people want to have N files compiled, but not the N+1st
> > > > file?  How are the first N files different from the N+1st?
> > > 
> > > Perhaps because 1500 <= N <= 2000 (or so) and the N+1st ist just one?
> > 
> > Then it isn't the same N, is it?
> 
> - Base .el(c)s pre-compiled. N.
> - Additional .el (perhaps written by the user, perhaps
>  downloaded from Emacswiki or what not) (jit) compiled,
>  go to somewhere writable by the user (perhaps somewhere
>  under ~/.emacs.d). 1. Or 2.

Then I ask again: why wouldn't the user want to have the addition .el
compiled to .eln?

> > > Perhaps because in the "normal case", the N+1st won't even happen?
> > 
> > Why disable something that will never happen?
> 
> ...in the normal case. The user should be still capable of tackling
> the not-that-normal case.

The not-that-normal case being user's own *.el files?  Why wouldn't
the user want to compile them into *.eln in that user's own eln-cache?
Why would that user want to disable native-compilation instead?

> > > I actually install a few packages from source, those I "personally"
> > > care about (Emacs is among them), But I couldn't possibly do it for
> > > the > 2000 currently installed on my system.
> > 
> > What is "it" in "do it" above?
> 
> Installing software from source.
> 
> >   And what does the 2000 number counts
> > here?
> 
> Debian packages: The Gnu compiler toolchain. The mail reader (mutt in my
> case). A mail transfer agent (Exim). A Web browser. A web server. Lots
> of different scripting languages. Networking stuff. SSH, rsync, git.
> Qemu. Cross build tools. X and all those little helpers. R, Octave, I
> don't know, all that stuff one needs to be happy :-)

How is this relevant to the issue at hand?  Only Emacs comes with
*.eln files and can use them.  Why are we talking about all the other
packages?

> > I don't see how disabling JIT compilation is needed for these 3
> > purposes.  In particular, if all the *.eln files are already present,
> > there will be no need to recompile them.
> 
> I don't know exactly how the Debian packaging for Emacs proceeds, but
> I think we are talking about two distinct situations here:
> 
> (a) the binary install for the end user (for which the target is to
>    end up with (some, most) .eln files pre-compiled and typically
>    in /usr/lib or /usr/share, depending on whether those files are
>    architecture-dependent (I think they are) or not
> 
> (b) the package build, which happens at the Debian developer's
>    box to build the Debian package to be installed to achieve
>    (a).
> 
> The question is whether the pre-compiling of the .eln happens at
> (a) (i.e. package install time) or at (b). It seems Rob has opted
> for the first (perhaps because there are dependencies which have
> to be resolved "late"?).
> 
> Anyway, this "disabling of JIT" would be relevant for (b), if
> at all (assuming I've been paying attention).

For case (b) Rob said that the workspace is thrown away after the
build, so whether the *.eln files are or aren't built there makes no
difference.  (And if the package build is done in batch mode, the
async compilation is disabled there by default.)

So, once again, I see no reason to disable JIT compilation for these
use cases.