Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 2 Oct 2022 07:58:33 +0200
> From: <tomas@tuxteam.de>
> 
> I see there two views: the distributor's (represented here by David's)
> and the jit's (Eli). For Eli, the file system objects are just a long
> term cache of the jit's work (longer than one Emacs session), for
> David, since the package's .el (and possibly .elc) are immutable (and
> of course, the whole Emacs runtime), the corresponding .eln can well
> be built at package install time. That would avoid each user to have
> an identical copy of them

As explained in my other message, I see no reason to make such
assumptions.  There's no reason to believe that a user who installs a
package will immediately start using it.  And even it they do, why
should we care about some extra disk space or identical files being
present? disk space is cheap, while the flexibility this allows (like
each user can have a slightly differently-configured Emacs) is
non-negligible.

> (and of course, the initial wait).

There's no wait: a package can be used immediately after loading or
requiring it.  The replacement of a byte-compiled by natively-compiled
code happens transparently and doesn't affect usage nor causes any
waits.

The advantage of using JIT compilation is that this is how the
upstream project meant it to be used, and this is how the defaults are
set.  Any deviation from the defaults should have a good reason, and I
submit that such good reasons can only be based on actual usage, not
on theoretical presumptions.  My recommendation is to use the default
JIT manner until and unless actual problems are reported by users.

> That does make a lot of sense in a multi-user system

Not to me, it doesn't.  It makes _some_ sense, but there are other
considerations.

> > The other part of what I asked is that if for some reason installation
> > does need to compile files (something that I still need to understand
> > why it happens), there's nothing that hard-codes HOME in the directory
> > list used for that.  You can set native-comp-eln-load-path to anything
> > you want, and only the directories in that list will be used.
> 
> Yes, but. It's not about HOME, but about a user-writable space. A shared
> space for .eln would have to be writable by all users if the compilation
> is to succeed when invoked on behalf of each one. This is a no-no under
> a multiuser system.

??? What "user-writable space"?  If we are talking about install-time
compilation, then the *.eln files should be deposited in some
centralized place to which the installation process can write.  And if
we are talking about JIT compilation when the user runs Emacs, then
the home directory is perfectly appropriate, and is writable.  No one
suggested that JIT compilations from "normal" user session should
write to shared directories (and if someone did suggest that, IMO this
suggestion makes no sense).

So I think you confused these two possibilities, because the problem
you raise doesn't exist.

> Install is invoked as root, so it can put the results of its compilation
> to a place readable by /all/ users (typically some /usr/share or /usr/lib,
> depending on whether the results are architecture-independent).

Exactly.  So what is the problem with directories writable by all
users?

> > Emacs doesn't require a writable HOME, it requires a writable
> > directory to store *.eln files.  It doesn't have to be HOME.  And once
> > again, I still don't understand why *.eln files are produced at
> > installation time in the first place.
> 
> That's all fine, but then users wouldn't profit from the pre-compiled
> .eln.

There's no profit, IME.  There are only disadvantages: you are in
effect fighting against the Emacs defaults, for reasons that are
purely theoretical.

> In a Debian-distributed Emacs (caveat: I'm compiling my own one!)
> there are .elc in /usr/share for all to use; due to the search path,
> a user still can install her own in a directory writable by that
> user and it will take precedence.
> 
> Can you do the same for .elc?

I guess you meant "with .eln files"?  Yes, see
native-comp-eln-load-path, which was already mentioned here several
times.