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: Suppressing native compilation (short and long term) Date: Wed, 28 Sep 2022 14:35:17 +0300 Message-ID: <83o7uzivey.fsf@gnu.org> References: <87ill8paw7.fsf@trouble.defaultvalue.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19280"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Rob Browning Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 28 16:53:03 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 1odYQp-0004p3-11 for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Sep 2022 16:53:03 +0200 Original-Received: from localhost ([::1]:41268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1odYQn-0003XS-EN for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Sep 2022 10:53:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50298) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odVLY-0005cY-TG for emacs-devel@gnu.org; Wed, 28 Sep 2022 07:35:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:46362) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1odVLX-0006Dp-78; Wed, 28 Sep 2022 07:35:23 -0400 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=NmsvsFUcaMH+8Fw3qRPKMtcUJz8XNf8eSoN6iaFWhyQ=; b=DlaxR6RRxOEc djzU4RUZN1VFRtK1Wz3mybKt10SdEjAIRpJ+D9RIujTVGn30j3+xtVFVG5hR9adPA4QrJZUfgcDxp m+OUWQR3DNWArRmVo0Yy1XVfUm1WI/r8RNJoLYEwYlLHCFO9vZNGCQLH5WDqh8Z+pWi1GgzPmTc8/ k82i2zZeJP4VjcUJp68NYc1klyDRnr1Vgxt4w4DH6Yn+X+qYZlF3H9/99vopfNRYDEpMyEm9tiJ1X 5i2WSTspqHpO3FD0jj6R8yO3Zzm7172SyCU51XoHSM3j52V0gr2x32ubWadSTseeGxfvmmY9CXjlr uHDDqOjAk2DS+K3xfbBflg==; Original-Received: from [87.69.77.57] (port=1182 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 1odVLW-0003RB-Hq; Wed, 28 Sep 2022 07:35:23 -0400 In-Reply-To: <87ill8paw7.fsf@trouble.defaultvalue.org> (message from Rob Browning on Tue, 27 Sep 2022 20:04:24 -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" Xref: news.gmane.io gmane.emacs.devel:296402 Archived-At: > From: Rob Browning > Date: Tue, 27 Sep 2022 20:04:24 -0500 > > > 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? I admit that I lost you somewhere near the beginning of your post. I think what's missing here is some more detailed explanation of the problems you are trying to solve. Without them, it is hard to give you intelligent answers. Here are some inline questions I'd like to be answered: > 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]). What do you mean by "writes to HOME"? Native-compilation doesn't write to HOME, it writes to directories in native-comp-eln-load-path. So basically, you already have a way to redirect stuff to wherever you want it. > 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/. By "package installs" do you mean when end-users install a prebuilt Emacs? If so, how come that should ever need to write something outside of the installation tree? The Emacs "make install" procedure doesn't, so why do your "package installs" somehow do? Also, AFAIR installing an ELPA package doesn't produce any *.eln files until the first time Emacs 'load's their *.elc files. So why is this a problem? OTOH, installing a package from ELPA does write stuff to the user's directories, so how is the behavior of native-compilation different here? > 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. What do you mean by "disable native compilation" here, and what exactly are the use cases for this? Are we talking about users who installed Emacs with some *.eln files, and from time to time load *.elc files that have no corresponding *.eln files? Or are we talking about something else? If the former, why do these users install Emacs with native-compilation to begin with? More generally, we never expected people who have Emacs with native compilation available to want to disable it. It made no sense to us during development of Emacs 28, and frankly, it still doesn't, at least to me. It is so easy to install Emacs without these capabilities and never look back that we thought providing a build-time option should be enough. (Well, except for MS-Windows users, where more is needed, but that's not your worry.) Therefore, if we need to discuss introduction of run-time features for disabling native-compilation, we need to have a broader view of the relevant use cases and user needs. This includes at least the following aspects that need to be discussed and clarified: . What does "disable native-compilation" mean, exactly? There are several possible interpretations of that. Do people want to prevent Emacs from looking for and loading the *.eln files, and use the *.elc files instead? Or do people only want to prevent Emacs from compiling new *.eln files? Or do people want that *.eln files be produced only by an explicit user command, not transparently and asynchronously? Or something else? . When and why would people want any of the above to be possible? . How and why would downstream distros want to support such capabilities? Armed with this information, we could then see which use cases are something we'd like to support in the core and how. Thanks.