From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.emacs.devel Subject: Suppressing native compilation (short and long term) Date: Tue, 27 Sep 2022 20:04:24 -0500 Message-ID: <87ill8paw7.fsf@trouble.defaultvalue.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25913"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 28 03:07:05 2022 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 1odLXV-0006Zf-Be for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Sep 2022 03:07:05 +0200 Original-Received: from localhost ([::1]:56638 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odLXU-0007ea-2w for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Sep 2022 21:07:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38196) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odLVT-0005o3-UQ for emacs-devel@gnu.org; Tue, 27 Sep 2022 21:05:01 -0400 Original-Received: from defaultvalue.org ([45.33.119.55]:37440) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odLVS-0001zo-1O for emacs-devel@gnu.org; Tue, 27 Sep 2022 21:04:59 -0400 Original-Received: from trouble.defaultvalue.org (localhost [127.0.0.1]) (Authenticated sender: rlb@defaultvalue.org) by defaultvalue.org (Postfix) with ESMTPSA id 63928200FF for ; Tue, 27 Sep 2022 20:04:25 -0500 (CDT) Original-Received: by trouble.defaultvalue.org (Postfix, from userid 1000) id C849314E081; Tue, 27 Sep 2022 20:04:24 -0500 (CDT) Received-SPF: pass client-ip=45.33.119.55; envelope-from=rlb@defaultvalue.org; helo=defaultvalue.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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" Xref: news.gmane.io gmane.emacs.devel:296377 Archived-At: Perhaps relevant in other contexts, but at least in the context of Debian work, we'd like to be able to suppress all native compilation in some contexts, or more specifically all writes to HOME (or really, to avoid any implicit file manipulations[1]). One key case is package builds and package installs (whether the emacs packages themselves, or any of the various emacs add-on packages (e.g. elpa-*)). For package builds, HOME is typically set to /nonexistent (or similar), and for package installs we don't want the install commands (preinst, postinst, etc.), which are running as root, to write anything to /root/. It's also been suggested by some users that they might like to have a supported way to disable native compilation (even when it's the system default), in order to avoid the unpredictable cpu and/or battery cost sometimes. Of course, assuming we eventually augment debian's current emacs infrastructure to generate system-level .eln files during (add-on) package installs, in addition to the .elc files it currently produces, much of that concern for debian and its derivatives might recede. In any case, I noticed that there is a no-native-compile variable, and wondered if (in the short term), I might be able to craft a (possibly debian-specific for now) way to disable native compilation across the board. Just to see, I changed no-native-compile to default to (getenv "DEBIAN_EMACS_DISABLE_NATIVE_COMPILATION") instead of nil, and then set that in the environment, but the ebib package tests (which set HOME=/nonexistent) still crashed (as had been originally reported here https://bugs.debian.org/1020191). The crash was in comp-trampoline-compile, and after a bit of investigation I wondered if it might be possible to fix the problem (at least approximately) by adding a no-native-compile clause to the comp-subr-trampoline-install guard like this: (defun comp-subr-trampoline-install (subr-name) "Make SUBR-NAME effectively advice-able when called from native code." (unless (or no-native-compilation ; this is new (null comp-enable-subr-trampolines) (memq subr-name native-comp-never-optimize-functions) (gethash subr-name comp-installed-trampolines-h)) ...)) That did allow the package tests to run successfully. So two questions: - As possibly just a short term, debian-specific fix, do those changes sound plausible, or are there other things we're missing (I might guess yes)? - Longer term, might it make sense to have some emacs-proper way to completely disable native compilation from the outside, either via environment variable, argument, or something else, for situations like this? [1] For add-on packages (e.g. elpa-*, etc.), we want to explicitly build the local .elc files (at least) during the install, but we don't want to write to any other unexpected locations. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4