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: 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]