Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Cc: luangruo@yahoo.com, larsi@gnus.org, akrl@sdf.org,
>  monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org
> Date: Fri, 14 Oct 2022 16:17:56 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Rob Browning <rlb@defaultvalue.org>
> 
> >>   - 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.
> 
> Hmm, which "this" did you mean?  If you meant HOME=/does-not-exist, I
> thought people had already said that wouldn't work because the attempt
> to build trampolines would still cause a crash.  But I may well have
> misunderstood.

I meant HOME=/does-not-exist, yes.  If that doesn't work (but please
test), we should fix that, I think.  Please report your findings if
that doesn't work.  We use that in our own test suite.

> > 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.
> 
> For what it's worth, the reason we'd been at least a bit inclined that
> direction is because if you have hundreds of emacs add-on packages
> (which I believe we do in Debian), and they all have build and or test
> suites that vary in any way they like, it could be much more difficult
> to track down all of the emacs invocations in each project's source to
> add some argument than it would be to just export an environment
> variable before running the suite.

I understand, but don't you have some kind of centralized script or
group of scripts that runs the testing?  In that case, you could make
the Emacs command, or its template, be part of those few scripts, and
then the change will be less painful.

Please understand my POV: adding an environment variable affects all
Emacs users, not just distros that have testing suites.  There's much
more at stake than your particular testing needs, and many Emacs users
know much less about the potential effects of such environment
variables than you and me.

> I suppose we could just shadow emacs in the path with a wrapper that
> includes the argument(s), assuming few of the projects have their own
> interfering options, and that they always use the same (or a handful of
> predictable) relative invocation of emacs, e.g. "emacs" not
> "/usr/bin/emacs" or...

Yes, something like that.  At least that's what we do in the Emacs's
own test suite (which, of course, is much smaller than yours).

> > 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.
> 
> Right, though we also have to make sure we can do that sufficiently
> early in *every* case.

Yes, ideally from the same/similar wrapper script that actually
invokes Emacs, via the --eval option.