Re: Add a configure option for NATIVE_FULL_AOT?

[tomas@tuxteam.de]

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

On Wed, Aug 18, 2021 at 04:45:42PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 18 Aug 2021 15:32:33 +0200
> > From: tomas@tuxteam.de

[...]

> > Then what would prevent a distribution from distributing their .eln
> > files to go somewhere in /usr/lib/emacs.../<version>/..., to be
> > overriden by the user when needed?
> 
> I don't think I understand.  load-path is used for only one purpose:
> finding Lisp files you want to load.  It is not used to decide where
> to _write_ *.elc files.  The same with native-comp-eln-load-path (but
> see below).  So how can this variable solve the problem at hand, which
> is where to store *.eln files produced by compilation?

Then all would be well: the idea is not for the user to replace the
distribution's .eln files, just to override them in case she wants
to change the corresponding .el files.

(at least not to change them unwittingly).

The distribution provides an Emacs (say somewhere in /usr/bin), the
.el and .elc files (somewhere in /usr/share/lib), and the .eln files,
possibly in an architecture-specific subdir in /usr/lib. 

When the user wants to change a distribution-specific .el, the default
way to do it would be to make a user-writable copy somewhere in a
user-controlled directory (ISTR there was a mechanism doing this
semi-transparently, but I may be confused). If `load-path' is set up
correctly, the user's variant takes precedence. Same would go for
.eln files resp. native-comp-eln-load-path, right?

> We actually do use native-comp-eln-load-path to also decide where to
> store the *.eln files, but that uses a simplistic heuristic that
> treats the last element of the list specially.  The heuristic is
> hard-coded in several places, so not easily overridden.

Oh, the /last/ element, i.e. the one with the least precedence is the
one where .eln files are stored? There goes my house of cards.
Interesting ;-)

For my (most probably incomplete) distro scenario, the first would be
the more natural candidate (assuming the first takes precedence in
the search, as with `load-path'). Or a separate knob, but then you'd
have another "interesting" problem: keeping those two consistent, for
some value of "consistent". Interesting, again.

> > I've been following the native compilation threads with quite some
> > excitement, but I'm sure I haven't digested many "interesting"
> > details :)
> 
> "Interesting" as in the infamous Chinese curse?

See above ;-)

> It's those "interesting" details that bother me: I needed to think
> about them and discuss them with Andrea many times over the last
> months, and in many cases the issue was put to rest by considering the
> JIT scenario.  I don't know what would have happened if we considered
> the AOT scenario as seriously as people want us to do now.

Don't get me wrong. I don't "want" anything. Besides saying "thank
you for your outstanding work". I'll be happy however it comes out.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]