--- Begin Message ---
|
Subject: |
[PATCH emacs-team 0/2] Think ahead when compiling |
|
Date: |
Sat, 18 Nov 2023 14:42:06 +0100 |
Hi Guix,
this series (hopefully) makes it so that everything we need to be natively
compiled in Emacs a) is natively compiled, and b) is found in the right
location. Please check that you no longer get gratuitous writes to your
local eln-cache when trying this out.
Cheers
Fixes: emacs-build-system … mismatching hashes <https://bugs.gnu.org/66864>
Liliana Marie Prikler (2):
gnu: emacs: Build trampolines.
gnu: emacs: Don't hash file names in native compilation.
gnu/local.mk | 1 +
gnu/packages/emacs.scm | 6 +-
.../emacs-native-comp-fix-filenames.patch | 93 +++++++++++++++++++
3 files changed, 99 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/emacs-native-comp-fix-filenames.patch
base-commit: 60c97924e9519361494aaf0686e28eb831a42315
--
2.41.0
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: [bug#67260] [PATCH emacs-team v11 0/7] You thought it was term/internal.el, but it was me, Dio! |
|
Date: |
Fri, 01 Mar 2024 20:40:38 +0100 |
|
User-agent: |
Evolution 3.46.4 |
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
--- End Message ---