bug#67260: [PATCH emacs-team v11 0/7] You thought it was term/internal.el, but it was me, Dio!

[Liliana Marie Prikler]

Am Freitag, dem 01.03.2024 um 17:35 +0000 schrieb Suhail:
> Is my expectation that reordering entries in the load-path shouldn't
> affect the natively-compiled status misplaced?
Yes.  We take the first prefix match and compute the file names from
there.  This is consistent with emacs matching the first file it finds
on the load-path.  You can't do much better, because your load path may
only be partially specified at compile time and later expanded with
normal-top-level-add-to-load-path.

> Where in v10 it failed because 3 features previously reported as
> being byte-compiled became natively-compiled, now it fails because
> the same 3 features go from being natively-compiled to byte-compiled
> after reordering load-path.
The expectation that load-path order does not matter is imho quite
unfounded.  Note that we do ship the actually important test cases with
v11.

> A separate bug issue can be created to track the peculiar dependence
> of the native-compilation status on the ordering of entries in load-
> path.
Well, to me it's not peculiar as I wrote the code, but I'm not sure how
familiar you are with Emacs' internals.  If you feel up for it, go for
it, but I'd rather tackle other problems related to our emacs
ecosystem.

Anyway, as you said, I'm pushing this now so that we can do a double
merge dance (i.e. master → emacs-team, then request the other way)
starting early tomorrow.

Cheers