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: Finalizing 'inhibit-automatic-native-compilation' Date: Fri, 27 Jan 2023 14:57:59 +0200 Message-ID: <837cx8cey0.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19293"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , Lars Ingebrigtsen , Stefan Monnier , Rob Browning To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 27 13:59:26 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 1pLOKC-0004jN-1C for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Jan 2023 13:59:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLOJC-0000Ye-9I; Fri, 27 Jan 2023 07:58:22 -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 1pLOJA-0000X5-Gh for emacs-devel@gnu.org; Fri, 27 Jan 2023 07:58:20 -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 1pLOJ9-00064R-A3; Fri, 27 Jan 2023 07:58:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=L7ah0/S2cF4wKY6XVbwe1BOntbuM4EWcvZgRTcQUNQc=; b=L3uwFe6Br2RbQB s+MGJqN5rbeKCTDxibBHeToB++IwVQWIMDT9JM3V6f7uWzNhGvArQ4beLM4XNQrJYb/Djxw+lLpoI 01SVKfXGkur7RBg9z8G95afA0VWMawkujWaLK/zDcp42JfOVchihlX7lLJErx8HhD2DR3s5NNdo6k udHlbHE0YHws0nVFRGA/OF8TjwJ5/0ceNDlJZE0HCRA3UpdXLJvG/8v3/6HgL2TlmZ5rHB3ZY0Xsd /ck3NFYSloxJU73wrxC2nVBHp0i9U9Qjkvl3rKB+Kcvjon4ly0kv0SgbnAWn0ErRHpJUkmvQiSXGA aTNP77YQ8+iXY33Jlxmg==; 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 1pLOJ5-0003nt-Gp; Fri, 27 Jan 2023 07:58:17 -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:302682 Archived-At: 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'. Relevant discussions, for those who want to refresh their memories: https://lists.gnu.org/archive/html/emacs-devel/2022-09/msg01911.html https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-10/msg01126.html Please respond soon, so as not to delay the pretest of Emacs 29. TIA