Re: Suppressing native compilation (short and long term)

[Rob Browning]

Eli Zaretskii <eliz@gnu.org> writes:

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

I've been told that it doesn't because (the person thought) of
trampolines.  i.e. Emacs can be reliably crashed that way.  Though if
that's changed since 28.[12], they wouldn't have seen it yet, and there
may be patches we should cherry-pick.

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

For us, this is about hundreds of upstream trees we don't directly
control.  How and where does magit invoke emacs during its build or
during its tests?  Or buttercup, or org, or bbdb, or emacspeak, or ivy,
or lsp, or...

How do we make sure we affect *all* of the invocations of emacs in all
of those?  Note here is just a subset things that Debian has packaged
that might be affected (i.e. only the ones whose maintainers have
decided to keep the Debian tree on salsa in the emacsen-team project):

  https://salsa.debian.org/emacsen-team

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

...as long as "most" invocations are either "emacs" or respect say
EMACS, this could work.  I have no idea if that's true, but we do
already know there are likely to be any number of places we'll have to
fix.  i.e. someone has told me that this approach will result in "a lot
of bugs" (in the debian packages).  They already know of places where
"some of them try to choose which emacs to use, rather than just
'emacs'".

We can handle that, but if we have to patch a lot of the upstream trees,
that could be a good bit of work.  That's certainly possible, but
hopefully that helps give more context about why we were interested in
some solution, among the possibilities, that's less potentially
invasive.

For what it's worth, we're also under a (not too close yet) deadline on
the Debian side.  We'd really like to have at least emacs 28 in the next
stable release, and the first stage of the freeze is currently scheduled
for I think January (though Emacs would I think be affected by a
slightly later stage).

For that to be possible, whatever we end up choosing here will need to
be something we can finish accommodating across both the emacs package
and all the add-ons by then.

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