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: Fri, 10 Feb 2023 10:08:03 +0200 Message-ID: <83bkm2kknw.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6334"; 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 Fri Feb 10 09:09:21 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 1pQOTA-0001Qh-Ja for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Feb 2023 09:09:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQOSX-0000Hf-Ty; Fri, 10 Feb 2023 03:08:42 -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 1pQOSU-0000HT-TA for emacs-devel@gnu.org; Fri, 10 Feb 2023 03:08:38 -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 1pQOST-000829-QZ; Fri, 10 Feb 2023 03:08:37 -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=OC9Uk3qd0UUphtkO1V7rKU70+/KpY9SgqWilwo77Uzc=; b=XrVcQ6RIAtYC OnWHqRi0kZaLyAjEjxHi1hDzTuIuubn+V2Fm3flf0G13KDhguFtTPormwZo44CokCeoHCShtQV7HB X7yfXqn97S+340S8cstGMdRi3VlDxVPEg+r8XXrX+PD1IHnA82+URngE3TleX+8D5RnRbt+OaWswl 0P0Zee1MmwGS+QHJICqUhje0bP1CtqMQ80YxB1Hze8fFIfTbE32pQSTmuDko6csON+x/zmmLyQ42B Z46xRb4yo9xnpqihBZcQ/Ss+OGsatOBwOdG930bCJS5s7Kng/uQUXsDMEQ15euUzobwkvNGD6TwVy pzRdZXV7/Z5wYXQqO/WTcw==; 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 1pQOST-0002Rt-0m; Fri, 10 Feb 2023 03:08:37 -0500 In-Reply-To: <874jruft28.fsf@athena.silentflame.com> (message from Sean Whitton on Thu, 09 Feb 2023 14:05:35 -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:303098 Archived-At: > From: Sean Whitton > 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.