From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Whitton Newsgroups: gmane.linux.debian.devel.emacsen,gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Wed, 01 Feb 2023 22:40:48 -0700 Message-ID: <87k01039r3.fsf@melete.silentflame.com> References: <837cx8cey0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32303"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org, Andrea Corallo , Lars Ingebrigtsen , Stefan Monnier , Rob Browning , debian-emacsen@lists.debian.org To: Eli Zaretskii Original-X-From: bounce-debian-emacsen=debian-emacsen=m.gmane-mx.org@lists.debian.org Thu Feb 02 06:41:18 2023 Return-path: Envelope-to: debian-emacsen@m.gmane-mx.org Original-Received: from bendel.debian.org ([82.195.75.100]) by ciao.gmane.io with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pNSLV-0008CZ-77 for debian-emacsen@m.gmane-mx.org; Thu, 02 Feb 2023 06:41:17 +0100 Original-Received: from localhost (localhost [127.0.0.1]) by bendel.debian.org (Postfix) with QMQP id B392720DC3; Thu, 2 Feb 2023 05:41:15 +0000 (UTC) X-Mailbox-Line: From debian-emacsen-request@lists.debian.org Thu Feb 2 05:41:15 2023 Old-Return-Path: Original-Received: from localhost (localhost [127.0.0.1]) by bendel.debian.org (Postfix) with ESMTP id 7A3E120FEE for ; Thu, 2 Feb 2023 05:41:04 +0000 (UTC) X-Virus-Scanned: at lists.debian.org with policy bank en-lt X-Amavis-Spam-Status: No, score=-12.881 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LDO_WHITELIST=-5, MURPHY_DRUGS_REL8=0.02, PGPSIGNATURE=-5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Original-Received: from bendel.debian.org ([127.0.0.1]) by localhost (lists.debian.org [127.0.0.1]) (amavisd-new, port 2525) with ESMTP id iXFewY0crjwl for ; Thu, 2 Feb 2023 05:40:56 +0000 (UTC) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .spwhitton. - helo: .out3-smtp.messagingengine. - helo-domain: .messagingengine.) FROM/MX_MATCHES_HELO(DOMAIN)=-2; rate: -5.5 Original-Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by bendel.debian.org (Postfix) with ESMTPS id DA52720FAA for ; Thu, 2 Feb 2023 05:40:55 +0000 (UTC) Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AFCF85C0192; Thu, 2 Feb 2023 00:40:50 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 02 Feb 2023 00:40:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spwhitton.name; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1675316450; x=1675402850; bh=uX eJXHnZieB7Aas+y6PRTf/bMnz8z4bmTKU1oGidMAI=; b=S0WbFhLz+SEB4cirHn xl0kMSjp0ImgVJ6W0Nl39rWSxPZWV/nvpJQai+m9tFFwqCqPwg+VjgpSl8ZHPd0f MGDYOqyGBPEwQvIQqkBkxAHi6rnVY0II9DeB+HI1p8kmYgLpFQE4nEE7sqQ/Stsa y4nl4Nq/p3qS6DcEHpcHxex5BVKGCbF++2r5zEMyl9WHgbl/B2NacavJoMd5EH8R lPxf4Lk1bw2Fx3VdFewtycHXTcevf6LhECOzmdK4FfUzrYoSLW+k3eBHMhSgLLbH 6W5pzJP4l2TPaj+AJGNjlavQ5EklnznDo9T0eUIyNAYvJrV25cgDTkKJezLHTK6o ZVyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1675316450; x=1675402850; bh=uXeJXHnZieB7Aas+y6PRTf/bMnz8 z4bmTKU1oGidMAI=; b=dbmaYojaf7yeaTH4wo0MXDxkVUtFzYQMZdB5ecWFgOhC PPB2voQ5WMP2O7QdfpbzLnnLMd3KYzLQlO/WTbFnsSLvH8WIxanUpn5SHAywXqEn 5+al34o4hdvMDGYYeRW8c8VnEakcXAREKA2p5846fPM2jozAyckN+sSC871pxDcE YJWoptZk7ZLevwBeXNbVHa0ry9VfIxTe8lPbToK2+coyAD+BKiVKQrc3AmC/SJOW O79aEfdagbVo0Q6ZgxUi/OKjnPbSlnf7Vh4nlcWfkcOJuSb6zwUTc2A9qXBrEj+2 6GWx/YvK0Z3XyHkvyCsokxgDc6ROyu6hsRlwzGmi3A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudefjedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefujghffffkfgggtgesghdttdertdertdenucfhrhhomhepufgvrghn ucghhhhithhtohhnuceoshhpfihhihhtthhonhesshhpfihhihhtthhonhdrnhgrmhgvqe enucggtffrrghtthgvrhhnpeetfeevtdeftdeigfeghfekveeuvefgfeduhfetgeekjeeu keehvdegvdetgedvleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehsphifhhhithhtohhnsehsphifhhhithhtohhnrdhnrghmvg X-ME-Proxy: Feedback-ID: i23c04076:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Feb 2023 00:40:50 -0500 (EST) Original-Received: by melete.silentflame.com (Postfix, from userid 1000) id 7BA577E0412; Wed, 1 Feb 2023 22:40:49 -0700 (MST) In-Reply-To: <837cx8cey0.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 27 Jan 2023 14:57:59 +0200") X-Rc-Virus: 2007-09-13_01 X-Rc-Spam: 2008-11-04_01 Resent-Message-ID: Resent-From: debian-emacsen@lists.debian.org X-Mailing-List: archive/latest/9434 X-Loop: debian-emacsen@lists.debian.org List-Id: List-URL: List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: debian-emacsen-request@lists.debian.org List-Archive: https://lists.debian.org/msgid-search/87k01039r3.fsf@melete.silentflame.com Resent-Date: Thu, 2 Feb 2023 05:41:15 +0000 (UTC) Xref: news.gmane.io gmane.linux.debian.devel.emacsen:8837 gmane.emacs.devel:302888 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, [quoting whole message for the benefit of debian-emacsen] On Fri 27 Jan 2023 at 02:57PM +02, Eli Zaretskii wrote: > The variable 'inhibit-automatic-native-compilation' was introduced in > last October, as result of various discussions on this list regarding > the need to disable async native-compilation in some situations. > Since its introduction was met with some opposition, in particular > from Andrea, the final decision about whether this variable should > stay in Emacs was deferred, with the purpose of collecting more data > points and user experience. > > With the pretest of Emacs 29 just around the corner, I think now is > the time to make that final decision. With that in mind, I will first > summarize the changes which this variable introduced into Emacs, and > then ask for opinions regarding some of its aspects. > > This variable was introduced (under the name > 'inhibit-native-compilation') in commit 5fec9182db. In that commit: > > . comp-trampoline-compile was changed to avoid writing the > trampolines to the eln-cache if this variable is non-nil (instead, > it writes the trampolines to a temporary-file directory, and > attempts to delete them after that, which on Posix platforms will > cause their deletion when Emacs which produced them exits, and on > Windows currently fails). > . In normal-top-level, we set this variable if the environment > variable EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION is set. > . In several places this variable either replaces > native-comp-deferred-compilation or has the same effect as the > latter (modulo the opposite meaning of nil/t value), therefore > disabling async compilation of *.el files that Emacs loads for > which there are no corresponding *.eln files. > > Here are the questions I think we want to be answered to finalize the > implementation and effects of 'inhibit-automatic-native-compilation': > > . Do people actually use 'inhibit-automatic-native-compilation' or > the corresponding environment variable? If so, for what reasons, > and why tweaking 'native-comp-eln-load-path' to direct the *.eln > files to some other place, including the temporary-file directory, > was not enough? > > . What do we want to do about compiling trampolines when > native-compilation is disabled? > > Currently, 'inhibit-automatic-native-compilation' doesn't really > disable compilation of trampolines, it just causes them to be > written to a temporary location, and hopefully deleted when the > session ends. This means that, for example, if the user has a > broken installation of GCC and Binutils, loading Lisp code that > uses advices will signal errors when Emacs compiles the > trampolines (because the compilation fails). > The alternative is to disable compilation of trampolines, but that > has a downside that advices for primitives will not have effect. > It is not clear to me which alternative is better, as they both > have failure modes. Note that the build process was augmented so > you can say, after building Emacs as usual > > make trampolines > > and have all the trampolines for the built-in functions > (a.k.a. "primitives") compiled and written to the build tree, from > where they will be installed by "make install", thus minimizing > potential problems with the need to build trampolines when running > the installed Emacs. > > If we leave the current build-trampolines-then-delete-them > machinery intact, is it a problem to have those trampolines not > deleted on MS-Windows? They will then be left in the temporary > directory, and are supposed to be removed by system cleanup > processes, or maybe remain there forever. Or do we have to add a > mechanism for deleting them at exit? > > . Do we want to keep the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION > environment variable? > > I dislike having environment variables that alter Emacs behavior, > because environment variables are inherited by sub-processes. So > having this variable set runs the risk of affecting all the > sub-processes, something that could be unexpected and is not easy > to prevent. We had similar problems with EMACSLOADPATH, for > example, which is especially painful when building another version > of Emacs from a shell buffer inside Emacs. This causes some > hard-to-debug problems. > So if this environment variable is largely unused, maybe we should > remove it, even if we keep 'inhibit-automatic-native-compilation'. Debian is now relying on this environment variable. It is going into our next stable release, which is already partially frozen, and it has already propagated to many (probably most) of our derivatives. We took the decision to start using the variable after Lars said it was going to stick around and, specifically, that it was therefore okay to backport it to Emacs 28. Over in our own channels, we had actually been planning to add our own version of this environment variable, before it got added upstream. In other words, we independently came to the conclusion that a mechanism of this nature was what we needed; as Stefan says, one reason is that we need to handle invocations of Emacs deep within third party Makefiles. In the shorter term, were it to be removed, we'd probably patch it back in with a DEBIAN_something name, rather than break all our packages again, or, rather than delaying uploading Emacs 29 to Debian. But in the longer term, I'm sure that we would be open to alternatives, if you really do want to remove the variable. (Just fyi, I am now co-maintaining Emacs in Debian alongside Rob.) =2D-=20 Sean Whitton --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJNBAEBCgA3FiEEm5FwB64DDjbk/CSLaVt65L8GYkAFAmPbTOAZHHNwd2hpdHRv bkBzcHdoaXR0b24ubmFtZQAKCRBpW3rkvwZiQF8MD/9aUWxb2G9VSIsiSKM3QUgj 1as4K8qFW3LnLz47PihYtTy72KPA2M5gqMMAPkTJix7xxRKiUJppYRz2ZeYXzo0t 5cbWGxBRNzrO2dov4bCUejjbJSIQ0/JP4pbCEJ8/yPXCxKrlpkyreS+q/P41Yb+v BGstHRIX18y6oUrrk1FrMh8oKjRQ2yleCt6MbDHoL7vVA+V568KfHCehAiWlrCyd GteHcW4ifwrZtKoVabnp8rR9B1VaBsbcJ2MdzyPLcDFh97pTvZldZrWXTxKi70ng rh7vmhQKZZguJElzAepfpL7lxv2VA/w/f85RVnFPo0odMmuIc1fwVhTViVRIw1Ig +IPTzMKVjo73H7ctUghfsyaVvd5wWFwTshxd4YjRFxHTBdFyjOHLNaStxDDC2LMH QIeAoDVzFgj8hKa7rmHiQoSQMv55JyCV6ppgBlUIDYfyrWWL8OuaKdZEw9c/QFkV XitE1n5oJeSkFA37h808iMnIZiV7PUsOU0okBhWh9AUwJL4Xd2XnMhFS8yV3KPaP xcSmDr2Y8g0Vriyu3pclPaBw9OaFRnEWbDTDOD94gbHwnKmzfqPqmOaq6kKl8YOe lbEgfZzAW4IXUUTfwNVAphByzGfJW7K1ZBsBUvukoOKMq9iXPckV6L93F+geSS1D EWK01sk2kPMZOvOb3RFL/Q== =rvv6 -----END PGP SIGNATURE----- --=-=-=--