Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: larsi@gnus.org, yandros@gmail.com, tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Tue, 04 Oct 2022 19:48:01 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > The above means (AFAIU) that disabling is not the right solution,
> > because you want the *.eln files to go to the shared location where
> > users could have them loaded when needed.  Is that correct, or am I
> > again missing something?
> 
> If I understand you, I think the answer may be no?
> 
> The test and package build cases are (often) isolated, automated,
> debien-specific processes that happen on debian build machines (as root
> and chrooted), and the entire workspace is then thrown away.  It's never
> relevant to a "normal" user.

If the workspace is thrown away, you shouldn't care about the *.eln
files it produces, right?  They will be thrown away together with the
workspace.  So why bother disabling their production in this case?

> The package install/upgrade process is system-wide, runs as root, and is
> specifically and quite intentionally not per-user.  It's intended to
> establish the static, common baseline for *all* users on the machine
> until the next package upgrade.

When this package install/upgrade process runs, doesn't it include
installing the *.eln files that come with the package, and need to be
used when the users use the package after the installation?  AFAIU,
you want to install those *.eln files in a shared location, which is
fine and supported: just put them in the same place under
/usr/lib/emacs/VERSION/native-lisp/ directory where Emacs installs its
precompiled *.eln files.  Or, if you want to have the *.eln files from
add-on packages to live in a separate place, define where that
directory will be, install the package's *.eln files there, and tweak
native-comp-eln-load-path to include that additional directory.

Again, in this case as well, I see no problem with generation of *.eln
files that you'd like to prevent.  And yet you are still saying that
disabling *.eln generation might be needed.  Could you please describe
in enough detail when are those unwanted *.eln produced in the two
situations you described (test and package build case, and package
install/upgrade case), and why are those *.eln files unwanted in that
case?

Thanks.

P.S. I'm sorry to keep this thread alive for so long, but I really
don't have a clear idea why you'd want to disable generation of *.eln
files, and I think it's important for us to understand your reasons.