Re: Suppressing native compilation (short and long term)

[tomas@tuxteam.de]

[-- Attachment #1: Type: text/plain, Size: 3893 bytes --]

On Wed, Oct 05, 2022 at 09:28:55PM +0300, Eli Zaretskii wrote:
> > 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?

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

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

It seems we are in violent agreement, then. Whatever the user installs
"outside" the Debian packaging system is the user's business. It is
desirable that it works well together with the Debian-provided baseline
(and Debian tries to make that possible).

> > 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 :-)

>  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"?

No, Debian 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.

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

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]