From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Sat, 11 Feb 2023 11:16:16 +0200 Message-ID: <83k00ok1en.fsf@gnu.org> References: <837cx8cey0.fsf@gnu.org> <83357vauh5.fsf@gnu.org> <837cx6a8me.fsf@gnu.org> <83357ua6ja.fsf@gnu.org> <83zga28ra8.fsf@gnu.org> <83r0vd97s0.fsf@gnu.org> <83lell73yv.fsf@gnu.org> <87sffo3as7.fsf@melete.silentflame.com> <83v8kkxzzx.fsf@gnu.org> <87r0v811pm.fsf@melete.silentflame.com> <87cz6nxdqy.fsf@X570GP> <83357irhnv.fsf@gnu.org> <87ttzy2lgi.fsf@X570GP> <874jruft28.fsf@athena.silentflame.com> <83bkm2kknw.fsf@gnu.org> <87r0ux9nk5.fsf@athena.silentflame.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9335"; mail-complaints-to="usenet@ciao.gmane.io" Cc: aymeric.agon@yandex.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org To: Sean Whitton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 11 10:17:39 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pQm0p-0002CB-Kl for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Feb 2023 10:17:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQm02-0000Mj-SG; Sat, 11 Feb 2023 04:16:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQm00-0000MK-Ms for emacs-devel@gnu.org; Sat, 11 Feb 2023 04:16:48 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQlzz-0006HN-BN; Sat, 11 Feb 2023 04:16:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=qcKqUk0byVkUqPrrcIOdSUTgTSt+oonMGyLQ2xolSjE=; b=pEY8vaq/N1hW xO9Z2nJcB7dOwPKURIFSV4uFqtREtX4H+JQ1e8og2HmnTcIoI7a8V9W1j5a89tORwxXFZLCzhdY1B 7/HPMtg9ZeDC7oWZVkv0Mv8DTtLmtWvsW0C8FwkisLBn99OLPYHf/iWsSTigCTRvLxrsyVx9I4Zxp zJhH2qxkunF/HpF3Bvj+FNervygX0SK8AePNcPnmgdUOjBjb4UkshO1dig6gz3RV4KTOf0ttnO3Zc 7glAn62Athqnyxq+NISECwb/Vq9cp3fPHeET3TCABGqpl1539gGq+rRj9RQmIcKnTwLeNVZ55aiwJ R26/SecsTlKxmc92uJxuRQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQlzy-0003Kj-QQ; Sat, 11 Feb 2023 04:16:47 -0500 In-Reply-To: <87r0ux9nk5.fsf@athena.silentflame.com> (message from Sean Whitton on Fri, 10 Feb 2023 15:13:14 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303131 Archived-At: > From: Sean Whitton > 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.