Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

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

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