emacs-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]