[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suppressing native compilation (short and long term)
From: |
Rob Browning |
Subject: |
Re: Suppressing native compilation (short and long term) |
Date: |
Fri, 14 Oct 2022 12:53:48 -0500 |
Eli Zaretskii <eliz@gnu.org> writes:
> I'm still discussing with Rob his needs. I hope to eventually
> understand their needs. For now my only conclusion is that they need
> to tweak native-comp-eln-load-path in some situations, to control
> where the *.eln files are deposited. Which is easy and supported
> already, AFAIU.
Eli, Lars, Andrea, and others, I think I'm mostly caught back up with
this thread, and hope to summarize a few things here:
- I made a mistake in emphasizing (via the thread subject) a
particular "solution" (suppressing native compilation). In the end,
from the Debian perspective, for the most immedate issue, we don't
need that particular solution (and I wasn't actually set on it at
the time). I'd mostly started there because it's *a* possible
solution, and one I'd imagined might be easyish to implement
(clearly that was naive). But other solutions would be fine too.
- For example, redirecting all incidental writes away from HOME would
be fine too.
- We'd prefer to still be able to set HOME=/does-not-exist, which I
assume would mean that we'd need some other way to redirect *all* of
the eln file writes (including trampolines).
Our practice of setting HOME to a nonexistent directory during some
packaging operations allows us to detect unexpected, and erroneous
attempts to write to HOME during those processes.
- If we are going to have "some other way" to redirect the eln files,
then for us an environment variable might be easier, so that we can
just export it before we start the relevant build/test/etc. and then
it'll affect all invocations of emacs in that environment. I
suspect an environment variable might also make it easier to
establish the setting "early enough" in the emacs startup process,
but don't know that.
- If just setting HOME will do the job, and there's no interest here
in anything further, then we can probably just do that, or if we
ended up needing to, we could likely add our own
DEBIAN_... environment variable, and carry a patch, but of course
that's less desirable.
- As an aside, I suspect Emacs may eventually want to have some way to
restore the ability to tolerate an unwritable filesystem. I have
more than once in the past launched emacs from an emergency shell to
fix a broken host where the filesystem was read-only and /home might
not be mounted (and if it were on NFS and there's no network yet,
could not be).
I'd much rather use emacs there, than /usr/bin/sensible-editor. Of
course now I know that I could just set HOME=/tmp and proceed, but
will others? Might at least be worth making sure any error messages
would lead people to that option.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
- Re: Suppressing native compilation (short and long term), (continued)
- Re: Suppressing native compilation (short and long term), Lars Ingebrigtsen, 2022/10/05
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/06
- Re: Suppressing native compilation (short and long term), Andrea Corallo, 2022/10/05
- Re: Suppressing native compilation (short and long term), Lars Ingebrigtsen, 2022/10/05
- Re: Suppressing native compilation (short and long term), Andrea Corallo, 2022/10/05
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/05
- Re: Suppressing native compilation (short and long term), Po Lu, 2022/10/05
- Re: Suppressing native compilation (short and long term), Lars Ingebrigtsen, 2022/10/05
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/06
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/06
- Re: Suppressing native compilation (short and long term),
Rob Browning <=
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/10/14
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/14
- Re: Suppressing native compilation (short and long term), Rob Browning, 2022/10/14
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/10/14
- Re: Suppressing native compilation (short and long term), Rob Browning, 2022/10/15
- Re: Suppressing native compilation (short and long term), Stefan Monnier, 2022/10/15
- Re: Suppressing native compilation (short and long term), Eli Zaretskii, 2022/10/15
- Re: Suppressing native compilation (short and long term), Rob Browning, 2022/10/15
- Re: Suppressing native compilation (short and long term), Lars Ingebrigtsen, 2022/10/15
- Re: Suppressing native compilation (short and long term), Sean Whitton, 2022/10/15