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

[Eli Zaretskii <eliz@gnu.org>]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Thu, 09 Feb 2023 14:05:35 -0700
> 
> > Other than that, I agree that this is mainly a question of convenience for
> > us. So much so that, as Sean said, we would probably patch it back should it
> > be removed. On top of that, the delta corresponding to the environment
> > variable specifically is negligible (1 line in normal-top-level) when compared
> > to the delta needed to implement the underlying
> > `inhibit-automatic-native-compilation'.
> 
> I think that the interpretation of this as a matter of convenience is
> wrong.  The *correct* solution for Debian, we think, is one that doesn't
> involve patching invocations deep inside third party Makefiles.
> Carrying all those patches is, I think, not technically correct design.

Design of what software that is whose responsibility?

The only Makefile's that the upstream Emacs project is responsible for
are our own Makefile's.  The design of how those work when building
Emacs or when running its own test suite is indeed our responsibility.
When, several months ago, we had issues with running tests using Emacs
with native-compilation, we modified our Makefile's to handle that;
the amount of changes to Emacs itself for that purpose was almost nil
(AFAIR, it involved some code to deal with unwritable HOME directory,
something that is also needed in other situations).

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.  And I object to
complicating Emacs when the only valid reason is that some test suite
of some 3rd-party package causes problems because its test harness was
evidently not adapted to Emacs with native-compilation.  If Debian
wants to solve these problems by patching Emacs, that is fine by me;
here we discuss what should and shouldn't be in the upstream Emacs
sources, available and exposed to more than just Debian and more than
just running those particular 3rd-party test suites.

Once again, please try looking at this from my POV, the POV of an
Emacs maintainer.  From my POV, adding features that cause non-trivial
complexity and processing on behalf of a few corner use cases makes
little sense.