Re: Suppressing native compilation (short and long term)

[Rob Browning]

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.

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

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

> Thanks again for your comments and perseverance.

Certainly, appreciate the help.
-- 
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