Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 5 Oct 2022 19:59:38 +0200
> From: <tomas@tuxteam.de>
> 
> > 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?

> Perhaps because in the "normal case", the N+1st won't even happen?

Why disable something that will never happen?

> The idea of a Debian package is to provide

I think the Debian case is not relevant, because they provide all the
*.eln files with the package you install (or so I understand).  So
either the user will only use those packages where *.eln are already
provided (in which case there's no reason to disable anything), or
they will want to use packages outside of the Debian distribution, in
which case I'm asking why they would like to give up on compiling
those additional ones.

> 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?  And what does the 2000 number counts
here? are you talking about 2000 Emacs Lisp packages that are not
bundled with the Emacs distribution and need to be installed
separately?  Or are you counting some other kind of "packages"?

> As far as I understand, the wishes are:
> 
>  (a) deliver a package with (all? as many as possible? most? .eln
>   pre-compiled
>  (b) build Emacs in a way that is idempotent (and doesn't change
>   overall system state
>  (c) perhaps run tests (possibly, ideally part of b)

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.