[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suppressing native compilation (short and long term)
From: |
Stefan Monnier |
Subject: |
Re: Suppressing native compilation (short and long term) |
Date: |
Sun, 02 Oct 2022 12:53:56 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
> I don't think you should try to second-guess the user who installs a
> package. They could just want to study the sources, for example.
I'm quite happy with the use of JIT as the default in Emacs.
But I think I agree with Rob that it makes a lot of sense in the context
of Debian to eagerly native-compile the packages when they're installed
via APT.
In APT there's a clearly distinction between installing the package
(which requires admin rights and has non-trivial effects on the whole
system) and looking at the source code of the package (this distinction
is natural in the context of Debian where many/most packages are written
in languages like C, but it naturally carries over to ELisp packages).
So if user "just want to study the sources" they wouldn't *install* the
package at all.
> All in all, I think JIT compilation strikes a good balance between
> resources and their actual usage.
Yes. But the balance is different in different contexts.
FWIW, I'm not convinced it's really useful in Debian's `emacs` package
to eagerly native compile all the bundled .elc files, but I think it
does make a lot of sense for ELisp packages installed separately.
In any case, I'd let Debian's maintainers make their own choices for
their own specific needs which are slightly different from ours (where
our release tarballs and default config are designed in large part for
users who'll compile Emacs themselves and who install third party
ELisp packages into their $HOME).
Stefan
- Re: Suppressing native compilation (short and long term), (continued)
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- Re: Suppressing native compilation (short and long term), tomas, 2022/10/02
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- Re: Suppressing native compilation (short and long term), tomas, 2022/10/02
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- Re: Suppressing native compilation (short and long term), chad, 2022/10/02
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- 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), Rob Browning, 2022/10/02
- Re: Suppressing native compilation (short and long term),
Stefan Monnier <=
- 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), Lars Ingebrigtsen, 2022/10/02
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 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), Lars Ingebrigtsen, 2022/10/02