[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suppressing native compilation (short and long term)
From: |
Rob Browning |
Subject: |
Re: Suppressing native compilation (short and long term) |
Date: |
Sat, 01 Oct 2022 15:42:06 -0500 |
Eli Zaretskii <eliz@gnu.org> writes:
> You should know that the problems you needed to address with the *.elc
> files don't exist with the *.eln files. The *.eln files have version
> information of the Emacs to which they "belong" hard-coded into their
> names.
Right, I'd noticed that, and while I haven't fully understood the
expectations/semantics yet, I'd started to assume much of what you've
described. I also assumed we'd need to understand things even better
before the Debian support is completely "ready" (right now we're working
all this out in unstable).
My current expectation is that if it ends up being feasible, we'll
probably want to treat the package-related .eln files like the .elc
files, and build them during the package install. For example,
elpa-magit (the current magit add-on package) will want to generate both
the .elc and .eln files for all of its .el files when its turn comes
around during installs/upgrades.
I say that because if it's a single-user machine and the user invokes
"apt install elpa-magit", I'd imagine they're doing that because they
want to use magit, in which case it doesn't hurt to get the work out of
the way up-front, and it might help in that all the work will be
finished at once, so they won't incur costs (battery-consumption, etc.)
later, when they might not expect or want it. (Not a critical issue,
possibly, but perhaps friendlier.)
And if it's a multi-user machine, with a lot of emacs users, at the
moment I don't see any reason to want to compile the same file 50 times
for 50 users (or even more than just once), incurring the attendant
power and storage costs.
> Yes, by changing native-comp-eln-load-path you should be able to avoid
> writing to the home directory of the user under whose credentials the
> installation runs. If you need that.
OK, thanks much.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
- Re: Suppressing native compilation (short and long term), Rob Browning, 2022/10/01
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/01
- Re: Suppressing native compilation (short and long term),
Rob Browning <=
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- Re: Suppressing native compilation (short and long term), tomas, 2022/10/02
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- Re: Suppressing native compilation (short and long term), tomas, 2022/10/02
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- Re: Suppressing native compilation (short and long term), chad, 2022/10/02
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/10/02
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- Re: Suppressing native compilation (short and long term), Rob Browning, 2022/10/02