[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suppressing native compilation (short and long term)

From: Eli Zaretskii
Subject: Re: Suppressing native compilation (short and long term)
Date: Tue, 04 Oct 2022 12:30:03 +0300

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: larsi@gnus.org, yandros@gmail.com, tomas@tuxteam.de, emacs-devel@gnu.org
> 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 :)

I didn't mean you, FWIW.

> > 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.

The above means (AFAIU) that disabling is not the right solution,
because you want the *.eln files to go to the shared location where
users could have them loaded when needed.  Is that correct, or am I
again missing something?

reply via email to

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