Re: Suppressing native compilation (short and long term)

[tomas@tuxteam.de]

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

On Wed, Oct 05, 2022 at 10:04:17PM +0300, Eli Zaretskii wrote:
> > 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?

I think nobody is proposing to prevent the user from doing that.

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

See above. This must be (part of) the misunderstanding. See above
my text, perhaps it was unclear:

  "Additional .el [...] (jit) compiled go to somewhere writable
   by the user"

We are in violent agreement here, I think.

> > > > I actually install a few packages from source, those I "personally"
> > > > care about [...]

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

Just trying to explain how the Debian packaging works and what it is
good for. Your questions seem to suggest that this is somewhat alien
to you (but my impression might be wrong, too).

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

[...]

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

As I understant, this might work well if it's possible to redirect/
restrict those target directories to specific places, yes. But Rob
will know much better than I could.

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

Perhaps we can get away with it, yes.

Cheers
-- 
t

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