Re: Finalizing 'inhibit-automatic-native-compilation'

[Eli Zaretskii <eliz@gnu.org>]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: aymeric.agon@yandex.com,  monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org,  akrl@sdf.org,  larsi@gnus.org,
>   rlb@defaultvalue.org
> Date: Fri, 10 Feb 2023 15:13:14 -0700
> 
> On Fri 10 Feb 2023 at 10:08AM +02, Eli Zaretskii wrote:
> 
> > But here we are talking about test suites provided by 3rd-party
> > packages (not even Debian's code, AFAIU), and Makefile's they use.
> > How is the correctness and/or elegance of that design is of any
> > concern to us?  Or for Debian, for that matter?  I understand very
> > well that it is convenient for Debian to be able to run those test
> > suites without changing them too much, but I see no design issues
> > here, nothing except for the convenience.  I definitely see no design
> > issues that should bother us, the upstream project.
> 
> Well, let me try to put it in more general terms.
> 
> Using Emacs as part of Debian's package build toolchain is, I think, as
> valid a use of Emacs as using it to write this e-mail message.  And for
> that use case, what we need, in the most general terms, is some
> mechanism which (i) doesn't require patching lots of third party
> Makefiles to activate, and which (ii) avoids Emacs crashing in ways that
> it didn't crash before we turned on native compilation.

I understand all that, and I'm nowhere near saying this is not a
legitimate use of Emacs: of course it is!  But Emacs cannot possibly
solve every legitimate problem OOTB which it could solve; solving some
problems does require some coding on the part of whoever must solve
the problem, and it is also legitimate for the upstream project to
expect that someone to write such code, instead of requesting Emacs to
solve the problem for them.

The bug report you posted, https://bugs.debian.org/1021842, is not a
crash, it is a failure which happens when a 3rd-party package is used.
I see no detailed analysis of the error in the bug report, so I can
only speculate what could be the reasons for the error:

  . buttercup was not updated to work with native-compilation (was
    this failure reported to the buttercup developers?)
  . Debian test harness uses buttercup incorrectly when
    native-compilation is enabled (e.g., it doesn't set up
    native-comp-eln-load-path to allow the trampolines to be produced)
  . the test that failed should only be run if Emacs was built without
    native-compilation

> Lars accepted these criteria and so he added the environment variable.

With all due respect to Lars, I disagree with that.  The record shows
that I disagreed from the start, back when Lars added the variable,
based on bitter experience we had with similar environment variables
in the past.  Since the variable was introduced and until now,
including this discussion, I've seen no new evidence indicating that
the variable is important enough to have, and nothing to make me
change my mind.  IMO, the dangers from using an environment variable
for these purposes still outweigh its usefulness.

> (i) is about design, not a matter of convenience, because a tool that
> works as part of Debian's package build toolchain must not require piles
> of patching of third party Makefiles.  Otherwise, it's a bug in that
> element of our toolchain.  This is a point of view developed from our
> years of experience of working on Debian, and I'm sure developers of
> other distributions would agree.  Distribution toolchains are
> fundamentally different to things like, say, GNU ELPA.  We have a
> different relationship with the third party code than you do.

That is understood and agreed upon, but then it is the job of Debian
to develop better tools.

> I understand that you don't want features in upstream Emacs for corner
> cases.  I share this design goal with you.  I think, though, that there
> are good reasons to think this is not a corner case, with Lars.
> The majority of users of Emacs on GNU systems are probably using our
> packages, and that requires a feature satisfying (i) and (ii).

We will have to agree to disagree on that, and this is final.