[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: |
Mon, 03 Oct 2022 20:41:22 +0300 |
[Full disclosure: evidently, none of what I write below matters, so
feel free to ignore.]
> From: Rob Browning <rlb@defaultvalue.org>
> Cc: larsi@gnus.org, yandros@gmail.com, tomas@tuxteam.de, emacs-devel@gnu.org
> Date: Sun, 02 Oct 2022 14:50:58 -0500
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Even if we are talking about two different users on the same system?
> > IOW, this is a system-wide restriction? Isn't that too harsh?
>
> The available Debian packages are a balance, intended to cover a broad
> set of common cases, i.e. Emacs without X, Emacs with the Lucid toolkit
> (because of, if nothing else, gtk issues), and Emacs with the GTK
> toolkit.
>
> You can only have one of them installed at a time, and you can
> (currently) only have one major version installed at a time.
>
> https://packages.debian.org/search?keywords=emacs
That's strange to hear. Even MS-Windows allows per-user variations of
PATH and per-use environment variables. It is strange to learn that
Debian doesn't.
> > And what about users who make changes to Emacs -- is that a legitimate
> > use case supported by Debian installations?
>
> I'd say that up to a point you can, and I have symlinked the relevant
> .el files into a ~/ directory, made sure that it's in my load-path, and
> then made adjustments, but past a certain point, I'd say that you'd want
> to switch to building Emacs yourself.
If you want to support even just installing a different minor version,
it will already require to recompile all of the *.eln files.
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.
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.
- 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), Lars Ingebrigtsen, 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/02
- Re: Suppressing native compilation (short and long term), Rob Browning, 2022/10/02
- Re: Suppressing native compilation (short and long term),
Eli Zaretskii <=
- 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, 2022/10/03
- 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