From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Liliana Marie Prikler Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Sat, 04 Feb 2023 18:48:34 +0100 Message-ID: <440f4cbd46a2db3c9963bc32aba9abe6cbe108ea.camel@gmail.com> References: <837cx8cey0.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22159"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.46.0 Cc: Andrea Corallo , Lars Ingebrigtsen , Stefan Monnier , Rob Browning To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 04 19:06:01 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 1pOMvI-0005ce-NH for ged-emacs-devel@m.gmane-mx.org; Sat, 04 Feb 2023 19:06:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pOMul-0000td-Em; Sat, 04 Feb 2023 13:05:27 -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 1pOMeW-00031w-Ml for emacs-devel@gnu.org; Sat, 04 Feb 2023 12:48:40 -0500 Original-Received: from mail-ed1-x543.google.com ([2a00:1450:4864:20::543]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pOMeU-0006Vl-R2; Sat, 04 Feb 2023 12:48:40 -0500 Original-Received: by mail-ed1-x543.google.com with SMTP id v13so7945538eda.11; Sat, 04 Feb 2023 09:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=i9CJNwjQiwp2+AMmICEmmvla0AQDts8vec0qP7ewCyE=; b=k67Jb5G6HHD3f6Bfxy6D4NT13e73BRmAR8KKQheZQvDkqBSD2AC8hOIzFubxRY8XtX 5R9rH49K6HStJdvcuEkuB/tuLAUB8BXI6Jy3pNw/tj6GoIFDDsNxE8XztMPdQAuolVUF cpA8F8x7weuGM7/VDMpN+f42ShQHsOP4QK39A+UCH473jmlVb7BdM4iEOznN/L0qMQrw mWwEObs8eYuTkiGj6trgoUMHh9h3dtW2E+CktszfXFX9qogZOGzYzI0glTs2p8KCn5S6 WiEDncLVnHkk4OywpychMuT/fI0foHzRSiuJk8zrbYUaNRxLf/gBt0f8GfJtaTz/oN5i WStQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=i9CJNwjQiwp2+AMmICEmmvla0AQDts8vec0qP7ewCyE=; b=EvoBt9aXxSqLM1jRwCW1MkeJjPqrVa2DDixB9GeoEpEyJw5uIo7lkG/57ebxz0cb7v J/+o19PXbw428f3bTaeUTYX63iuyCQgEL1QzD48N+CWHYByvkCBLnbxJPE5g8wN2BnNH BDvjYO5HEbjiL1tPKDCknLEfY6Z/eHUGTEK5j3vVPrMWjmmuvtB9J73ZSLEOcqlLwwQR nO7DlRTKUTi/w6zzM3yw5KHc4rt3QsHChaQ0LIQXkQn+5U0mCXDSSyrcIpcOhE2R45NV crzMhSn+RBGTRnrAfiWGfMMC/Q9GmHSiPjjB0u6poaXeaTQpHjOVHr+tvNzyL157a3fD qVDg== X-Gm-Message-State: AO0yUKUvR2yEPslH5i9TgZvU6iN0t/BFEpzekfI6HQ1xE849CT0jRpt0 43/X9n8E6yf/xTJ74epZNeRZ1YpAENI= X-Google-Smtp-Source: AK7set/naF3cV80gCNeFbONNMMqBKY85Yy6U1jpRKwaHZGuQACrYwUFgVt27GuZ9PtfmhafaVbh3ug== X-Received: by 2002:a50:d6cc:0:b0:4aa:a06d:4ec8 with SMTP id l12-20020a50d6cc000000b004aaa06d4ec8mr2345409edj.10.1675532916228; Sat, 04 Feb 2023 09:48:36 -0800 (PST) Original-Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id fj15-20020a0564022b8f00b004a233e03afdsm2780181edb.46.2023.02.04.09.48.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Feb 2023 09:48:35 -0800 (PST) In-Reply-To: <837cx8cey0.fsf@gnu.org> Received-SPF: pass client-ip=2a00:1450:4864:20::543; envelope-from=liliana.prikler@gmail.com; helo=mail-ed1-x543.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sat, 04 Feb 2023 13:05:26 -0500 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:302970 Archived-At: Hi Eli, Am Freitag, dem 27.01.2023 um 14:57 +0200 schrieb Eli Zaretskii: > 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. >=20 > With the pretest of Emacs 29 just around the corner, I think now is > the time to make that final decision.=C2=A0 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. Since I am on the Guix team for Emacs packaging, I'll try to lay out some concerns both from the perspective of a user and a downstream packager. I hope I'm not too late to the party. > This variable was introduced (under the name > 'inhibit-native-compilation') in commit 5fec9182db.=C2=A0 In that commit: >=20 > =C2=A0 . comp-trampoline-compile was changed to avoid writing the > =C2=A0=C2=A0=C2=A0 trampolines to the eln-cache if this variable is non-n= il > (instead, > =C2=A0=C2=A0=C2=A0 it writes the trampolines to a temporary-file director= y, and > =C2=A0=C2=A0=C2=A0 attempts to delete them after that, which on Posix pla= tforms will > =C2=A0=C2=A0=C2=A0 cause their deletion when Emacs which produced them ex= its, and on > =C2=A0=C2=A0=C2=A0 Windows currently fails). > =C2=A0 . In normal-top-level, we set this variable if the environment > =C2=A0=C2=A0=C2=A0 variable EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION is= set. > =C2=A0 . In several places this variable either replaces > =C2=A0=C2=A0=C2=A0 native-comp-deferred-compilation or has the same effec= t as the > =C2=A0=C2=A0=C2=A0 latter (modulo the opposite meaning of nil/t value), t= herefore > =C2=A0=C2=A0=C2=A0 disabling async compilation of *.el files that Emacs l= oads for > =C2=A0=C2=A0=C2=A0 which there are no corresponding *.eln files. >=20 > Here are the questions I think we want to be answered to finalize the > implementation and effects of 'inhibit-automatic-native-compilation': >=20 > =C2=A0 . Do people actually use 'inhibit-automatic-native-compilation' or > =C2=A0=C2=A0=C2=A0 the corresponding environment variable?=C2=A0 If so, f= or what reasons, > =C2=A0=C2=A0=C2=A0 and why tweaking 'native-comp-eln-load-path' to direct= the *.eln > =C2=A0=C2=A0=C2=A0 files to some other place, including the temporary-fil= e > directory, > =C2=A0=C2=A0=C2=A0 was not enough? On Guix, I want my Emacs packages to either (1) already have been natively compiled when using `guix install some-emacs-package' or (2) to not natively compile anything and clutter my user-emacs-directory.=20 Now the concern about clutter is somewhat secondary to Emacs spending time that some other Emacs could have spent on CI. (We don't do native compilation on CI *yet*, but imho it would be worth doing for some packages) > =C2=A0 . What do we want to do about compiling trampolines when > =C2=A0=C2=A0=C2=A0 native-compilation is disabled? In my opinion, there should be a way to generate these trampolines ahead of time in a known location (e.g. $package-trampolines.so) for the emacs package $package. If no such trampoline is found and native- compilation is disabled, no compilation should take place. > =C2=A0=C2=A0=C2=A0 Currently, 'inhibit-automatic-native-compilation' does= n't really > =C2=A0=C2=A0=C2=A0 disable compilation of trampolines, it just causes the= m to be > =C2=A0=C2=A0=C2=A0 written to a temporary location, and hopefully deleted= when the > =C2=A0=C2=A0=C2=A0 session ends.=C2=A0 This means that, for example, if t= he user has a > =C2=A0=C2=A0=C2=A0 broken installation of GCC and Binutils, loading Lisp = code that > =C2=A0=C2=A0=C2=A0 uses advices will signal errors when Emacs compiles th= e > =C2=A0=C2=A0=C2=A0 trampolines (because the compilation fails). > =C2=A0=C2=A0=C2=A0 The alternative is to disable compilation of trampolin= es, but > that > =C2=A0=C2=A0=C2=A0 has a downside that advices for primitives will not ha= ve effect. > =C2=A0=C2=A0=C2=A0 It is not clear to me which alternative is better, as = they both > =C2=A0=C2=A0=C2=A0 have failure modes.=C2=A0 Note that the build process = was augmented so > =C2=A0=C2=A0=C2=A0 you can say, after building Emacs as usual >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 make trampolines >=20 > =C2=A0=C2=A0=C2=A0 and have all the trampolines for the built-in function= s > =C2=A0=C2=A0=C2=A0 (a.k.a. "primitives") compiled and written to the buil= d tree, > from > =C2=A0=C2=A0=C2=A0 where they will be installed by "make install", thus m= inimizing > =C2=A0=C2=A0=C2=A0 potential problems with the need to build trampolines = when > running > =C2=A0=C2=A0=C2=A0 the installed Emacs. >=20 > =C2=A0=C2=A0=C2=A0 If we leave the current build-trampolines-then-delete-= them > =C2=A0=C2=A0=C2=A0 machinery intact, is it a problem to have those trampo= lines not > =C2=A0=C2=A0=C2=A0 deleted on MS-Windows?=C2=A0 They will then be left in= the temporary > =C2=A0=C2=A0=C2=A0 directory, and are supposed to be removed by system cl= eanup > =C2=A0=C2=A0=C2=A0 processes, or maybe remain there forever.=C2=A0 Or do = we have to add a > =C2=A0=C2=A0=C2=A0 mechanism for deleting them at exit? In my opinion, the failure mode of not being able to advise native code is an acceptable one. If possible, I'd like to extend the "make trampolines" approach into one that can also be applied to packages installed via package.el/straight/... > =C2=A0 . Do we want to keep the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATIO= N > =C2=A0=C2=A0=C2=A0 environment variable? >=20 > =C2=A0=C2=A0=C2=A0 I dislike having environment variables that alter Emac= s behavior, > =C2=A0=C2=A0=C2=A0 because environment variables are inherited by sub-pro= cesses.=C2=A0 So > =C2=A0=C2=A0=C2=A0 having this variable set runs the risk of affecting al= l the > =C2=A0=C2=A0=C2=A0 sub-processes, something that could be unexpected and = is not easy > =C2=A0=C2=A0=C2=A0 to prevent.=C2=A0 We had similar problems with EMACSLO= ADPATH, for > =C2=A0=C2=A0=C2=A0 example, which is especially painful when building ano= ther > version > =C2=A0=C2=A0=C2=A0 of Emacs from a shell buffer inside Emacs.=C2=A0 This = causes some > =C2=A0=C2=A0=C2=A0 hard-to-debug problems. > =C2=A0=C2=A0=C2=A0 So if this environment variable is largely unused, may= be we > should > =C2=A0=C2=A0=C2=A0 remove it, even if we keep 'inhibit-automatic-native- > compilation'. I don't think a variable is needed necessarily. What is needed is a method of enabling it reliably on the command line (i.e. a switch like --no-native-compilation would work, but so would --eval '(setq inhibit- automatic-native-compilation t)'), and reliably as a user editing just Emacs configuration files (in particular, early-init.el seems like the place I would naturally place it in). Cheers