[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suppressing native compilation (short and long term)
From: |
Lars Ingebrigtsen |
Subject: |
Re: Suppressing native compilation (short and long term) |
Date: |
Sun, 02 Oct 2022 21:08:15 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Rob Browning <rlb@defaultvalue.org> writes:
> At the top level, we wanted a way to avoid writing to HOME during
> packaging, testing, installs (in this case, it's the .eln files, now
> that we've enabled native compilation).
>
> That could be handled by some way to turn off native compilation, or by
> some way to comprehensively divert those writes to another location
> (e.g. temp dir). Either is fine, though we'd originally thought the
> former might make things a bit easier.
Yeah, I think the former is both easier to implement and easier for
users.
So I'm thinking of introducing a user option like
`native-compile-inhibit', which will make Emacs skip the native-comp
machinery when loading .elc files. It will default to nil, of course,
but perhaps it would be convenient to make it depend on an environment
variable like "NATIVE_COMPILE_INHIBIT"? Then users (and the Debian
build system) could say "NATIVE_COMPILE_INHIBIT=true emacs ..." when
doing testing etc? Would that fit your use case?
(This will be for Emacs 29, but you can cherry-pick this for Debian, if
that's something you want to do, and it will probably not affect
trampolines, since those are necessary for redefining functions.)
> Whether or not we can (or should) try to build system-level (root owned)
> .eln files along with the .elc files during package installs (as we
> already do for .elc files) is a separate question, and I think the more
> controversial one?
Not controversial from where I'm, er, sitting -- sounds both useful and
convenient to me.
- Re: Suppressing native compilation (short and long term), (continued)
- 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), 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 <=
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/02
- Re: Suppressing native compilation (short and long term), Lars Ingebrigtsen, 2022/10/03
- Re: Suppressing native compilation (short and long term), Lars Ingebrigtsen, 2022/10/03
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/10/03
- Re: Suppressing native compilation (short and long term), Lars Ingebrigtsen, 2022/10/03
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/10/03
- Re: Suppressing native compilation (short and long term), Lars Ingebrigtsen, 2022/10/03
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/10/03
- Re: Suppressing native compilation (short and long term), Lars Ingebrigtsen, 2022/10/03
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/10/03