[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sean Whitton
Subject: Re: Finalizing 'inhibit-automatic-native-compilation'
Date: Fri, 10 Feb 2023 15:13:14 -0700
User-agent: Gnus/5.13 (Gnus v5.13)


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.

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

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

Currently, the only thing that satisfies both (i) and (ii) is the
environment variable.  We would be very happy to use something else, and
can help with testing it etc..

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

Sean Whitton

reply via email to

[Prev in Thread] Current Thread [Next in Thread]