[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Add a configure option for NATIVE_FULL_AOT?
From: |
Eli Zaretskii |
Subject: |
Re: Add a configure option for NATIVE_FULL_AOT? |
Date: |
Wed, 18 Aug 2021 19:43:23 +0300 |
> 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.
> > The preloaded *.eln files are stored there, yes.
>
> But why on the "least precedence" slot, i.e. in the place at the
> list's tail? I'd have expected them to be stored in the place
> at the list's head.
>
> > How else would you
> > arrange for them to be of the least precedence, when lists are
> > generally searched head to tail?
>
> Why would I want to arrange "them" [1] to be of the least precedence?
> A freshly user-compiled file should have the highest precedence, IMO.
How would that precedence work, except by relying on the order of the
directories in the list?
> [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.
- Re: Add a configure option for NATIVE_FULL_AOT?, (continued)
- Re: Add a configure option for NATIVE_FULL_AOT?, tomas, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, Eli Zaretskii, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, tomas, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, Eli Zaretskii, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, tomas, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, Eli Zaretskii, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, tomas, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?,
Eli Zaretskii <=
- Re: Add a configure option for NATIVE_FULL_AOT?, tomas, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, Eli Zaretskii, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, Stefan Monnier, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, tomas, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, Eli Zaretskii, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, tomas, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, Andrea Corallo, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, Stefan Monnier, 2021/08/18
- Re: Add a configure option for NATIVE_FULL_AOT?, Eli Zaretskii, 2021/08/19
- Re: Add a configure option for NATIVE_FULL_AOT?, Andrea Corallo, 2021/08/19