[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: |
Mon, 03 Oct 2022 19:16:29 -0500 |
Eli Zaretskii <eliz@gnu.org> writes:
> [Full disclosure: evidently, none of what I write below matters, so
> feel free to ignore.]
Well, I can't speak for others, but it matters to me (your opinion and
the other upstream developers'), or I wouldn't be here, and I'm very
glad there's a "here for me to be" because I'm quite fond of Emacs :)
> But okay, yes, if Debian users live under such severe restrictions,
> then the case for having user-specific *.eln directories becomes
> weaker. But I still don't see that it is weaker than disallowing
> native compilation at run time.
To be clear, I've never been talking about disallowing it for normal
user use, and apologies if I made it sound that way.
For normal users, if we pursued this, the idea would be that after "apt
install emacs" finishes, they'd have a full set of .elc and .eln files
corresponding to their version of Emacs, and the .el files they have.
Then if anything changes in a way that warrants it, Emacs would
(re)compile to their ~/.emacs.d/eln-cache/ as "normal". But for those
who don't ever change their .el files (or shadow them), that would never
happen, or would only happen for the files that they change/shadow.
> And I guess now I'm confused what is it exactly that you'd want to
> achieve. Do you want to disable native compilation, or do you want to
> have all *.eln files in a shared location? Because it seems to me you
> said you wanted both, and I don't see how both could be reconciled.
The ability to disable .eln compilation entirely is only for some
Debian-specific (though maybe useful for others) special cases, not
anything we're proposing for "normal use".
And it doesn't have to be "disabling" -- being able to redirect the .eln
files to another (temp) dir would be fine too, as long as it wasn't too
awkward to arrange for the entire (sub)process tree.
Those special cases are (at least):
- When building the relevant Debian packages -- for Emacs itself, for
add-ons like elpa-magit, etc. Debian forbids package builds from
writing outside of the package build directory /tmp, and another
tree or two, e.g. HOME is not allowed. Note that this is normally
handled by the Debian autobuilders, it's not something users
typically do.
- During package installs, i.e. whenever Emacs is run during an "apt
install emacs" or "apt upgrade emacs", etc., and it may be run many
times there, both directly, and indirectly as it rebuilds whichever
packages need rebuilding (e.g. add-on packages).
- During some autmated Debian tests.
Hope this helps
--
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), (continued)
- Re: Suppressing native compilation (short and long term), Rob Browning, 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
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/03
- Re: Suppressing native compilation (short and long term), tomas, 2022/10/03
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/03
- Re: Suppressing native compilation (short and long term), tomas, 2022/10/03
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/03
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/10/03
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/03
- Re: Suppressing native compilation (short and long term),
Rob Browning <=
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/04
- Re: Suppressing native compilation (short and long term), Rob Browning, 2022/10/04
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/05
- Re: Suppressing native compilation (short and long term), Michael Welsh Duggan, 2022/10/08
- Re: Suppressing native compilation (short and long term), Rob Browning, 2022/10/15
- 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), Lars Ingebrigtsen, 2022/10/02
- Re: Suppressing native compilation (short and long term), Rob Browning, 2022/10/02
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02