Re: Add a configure option for NATIVE_FULL_AOT?

[tomas]

I feel sorry for wasting your time in this way.

On Wed, Aug 18, 2021 at 07:43:23PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 18 Aug 2021 18:34:55 +0200
> > From: tomas@tuxteam.de
> > Cc: emacs-devel@gnu.org
> > 
> > > > 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?
> > > 
> > > Nominally, yes.  But then you have 2 copies of the same .eln file, in
> > > 2 different places.
> > 
> > They would be different, one of them from an .el with user changes.
> 
> Sure, that's my point.

And we want the user's .el and the corresponding .eln to override
the system-provided ones. So those (more precisely: their directories
should go first in their corresponding paths, right?

> How would that precedence work, except by relying on the order of the
> directories in the list?

I must have expressed my thoughts too clumsily. I do agree with you
that the several paths are in order of descending preferences.

What I'm implying from that is that the place for the user's .eln
files should be more at the front of this path, so the .jit mechanism
should put them there, if they have to override the system-provided
ones.

> > [1] provided our "them" refers to the same thing: "the .eln files
> >    freshly compiled in the user's behalf, because Emacs has seen
> >    an .el(c) file it had not seen before"
> 
> I don't understand this part.  The *.elc files add yet another
> "interesting" aspect to the issue, but that's a story for another day.

Let's forget about those for now :-)

Cheers
 - t

signature.asc
Description: Digital signature