Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: David Bremner <david@tethera.net>,  emacs-devel@gnu.org,  akrl@sdf.org,
>   rlb@defaultvalue.org
> Date: Fri, 30 Sep 2022 07:55:08 -0700
> 
> We currently bytecompile during package installation, and would like
> also to do the native compilation at that time.
> 
> The main reason for bytecompiling at package installation is that we
> have logic to purge and recompile anything whose dependency versions
> have changed, which means that all bytecode installed on Debian systems
> was generated using known-correct macro definitions.  Historically
> ordinary Emacs processes running in non-batch mode have not guaranteed
> this; I recall that the Org-mode developers discouraged use of ELPA to
> install newer versions of Org because of these sorts of issues.

This problem doesn't exist with *.eln files, because Emacs will
regenerate new .eln files with different hashes in its name when the
source file or the Emacs binary changes.  So you do not have to
trigger native compilation for these reasons.

> A secondary reason is that it makes sense to compile once, system-wide,
> rather than repeatedly in each user's home directory.

I think this is misguided.  If the user never loads a package, there's
no reason to produce the *.eln files for it.  At best it litters the
disk with useless files.  At worst, compilation could cause warnings
or even errors, which are just an annoyance when the package is not
going to be used for a long time, or not at all.

These considerations are the reason why *.eln files are compiled JIT
and on-demand.  It is not a coincidence or lack of thought on our
part, it is the result of considering many factors.

I think you are trying to deal with *.eln files and with
native-compilation in general as if it were a slightly different kind
of byte-compilation.  That is a mistake: it's a qualitatively
different feature with different traits and different user-facing
and administrator-facing aspects.

> It is also nice that you can know everything is already in place
> once your package is installed, so that I can unplug my laptop once
> the package manager has exited, and I know that it isn't going to do
> any CPU-intensive compilation and drain my battery.

The *.eln files should not be part of "everything is in place",
because they will be produced when needed.  No user involvement or
interaction is necessary.