[Top][All Lists]

[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: Fri, 14 Oct 2022 22:06:25 +0300

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: larsi@gnus.org, akrl@sdf.org, monnier@iro.umontreal.ca,
>  david@tethera.net, emacs-devel@gnu.org
> 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:

Thank you for your summary.

>   - 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.

This should work for preventing the native-compilation from storing
the *.eln files.  If it doesn't work for you, please tell the details,
and we will investigate.

>   - 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.

One other way is to change the value of native-comp-eln-load-path.  I
hesitate to add an environment variable for that, because environment
variables are inherited to subprocesses, and so setting a variable for
some Emacs process will affect all of its Emacs subprocesses.  This
was found to be a reason of tricky and hard-to-debug problems when
users set EMACSLOADPATH like that, and I presume the same can easily
happen with the equivalent variable for *.eln files.  So I'd rather
not add such a variable unless we find a very good reason.

>   - As an aside, I suspect Emacs may eventually want to have some way to
>     restore the ability to tolerate an unwritable filesystem.

With respect to writing the *.eln files, Emacs will look along
native-comp-eln-load-path for the first directory that is writable,
and use that.  So you could at least partially handle this case by
making sure native-comp-eln-load-path includes at least one writable

>     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?

I've now documented this method in the ELisp reference manual, in the
hope that it will make this more discoverable.

Thanks again for your comments and perseverance.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]