Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Sun, 02 Oct 2022 12:57:54 -0500
> 
> Though note that for reasons we can elaborate on if desired, it might be
> easier for us if the default for that variable could also be set via a
> corresponding environment variable, but that's a separate question.
> 
> (For example, we have relevant emacs-related packages where the upstream
>  build process runs emacs a level or two "down" (subprocess-wise), and
>  so it'd be a lot less invasive if we could just set an environment
>  variable to change the .eln destination, instead of having to figure
>  out how to change each invocation of emacs in that package (and
>  maintain those changes across future upstream versions).

We could introduce such a variable, similarly to EMACSLOADPATH.  But
note several important considerations:

  . unlike with EMACSLOADPATH, the actual place where *.eln files will
    live is in a subdirectory of any directory in the list, due to the
    need of having them separately for different Emacs binaries and
    versions
  . EMACSLOADPATH is a mixed blessing: if you set it incorrectly, or
    forget that its value is inherited by subprocesses, you can
    completely hose an Emacs session, which is why we generally
    recommend against its use

> A second, and a separable question, is whether Debian should try to
> maintain system-level (root owned) .eln files the same way it does for
> .elc files.
> 
> I consider that an open question, and it could well be that the answer
> ends up being "no".  That's what we're trying to find out, and of course
> we have to begin by trying to communicate why that might be desirable.

Given the much more strict requirements for *.eln files wrt the target
architecture, certain crucial aspects of the Emacs binary, and the
contents and file name of the corresponding source file, my suggestion
is to start from "no" and only consider "yes" if you discover good
reasons through experience.  E.g., my eln-cache directory has no less
than 20 subdirectories, each one for a slightly different Emacs
version and configuration.  That might be somewhat extreme, given that
I work on development of and use several versions in parallel, but I
wouldn't be surprised to see several subdirectories for each of your
users, and even less surprised to see different subdirectories for
different users.  So I think the case for common compiled Lisp files
is much weaker for *.eln files than it is for *.elc files/

> It's certainly the case that if the consensus here (among the upstream
> developers) is that we shouldn't do that, and that future
> choices/changes aren't likely to take that use case into consideration,
> then we have our answer.

I only know that I didn't yet hear any good reason for rushing to
natively-compile optional Lisp packages.  That doesn't mean I'm dead
certain there could be no such good reasons, of course, just that I'd
like to see them described in enough detail to consider something
different from what was envisioned during Emacs 28 development.