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: Finalizing 'inhibit-automatic-native-compilation' Date: Sat, 28 Jan 2023 11:17:42 +0200 Message-ID: <83357vauh5.fsf@gnu.org> References: <837cx8cey0.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39085"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 28 10:18:54 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 1pLhMM-0009y7-NP for ged-emacs-devel@m.gmane-mx.org; Sat, 28 Jan 2023 10:18:54 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pLhLV-0007AB-5X; Sat, 28 Jan 2023 04:18:01 -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 1pLhLS-00079r-IT for emacs-devel@gnu.org; Sat, 28 Jan 2023 04:17:58 -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 1pLhLR-0000yO-5m; Sat, 28 Jan 2023 04:17:57 -0500 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=7BjwUpJmfq0WTe5BxaZjO19cDeNL1P8aBOc4OWJkRoI=; b=T7n1MggQOfX0 wvSmoN0cTX8U++zTUYZeYsvFUdAPXqPdV9sDovhcTGli/H9trR9qcAlYoS2nXqvPT1BUQt8CISbCm d7+xwZbvw6CWdGRv1DwTYokP8oRqqBd3M2CdP9n5pxqCl1KnbFJS2bWWl6DeaoQEk02O9lsuVYkQa tMWEbBmY1nbYOwulk9lJLfpkJ+jGq7oTHcos/s6FtwYgLK5xuU3fU2VjFGw3rI9Uwy9oed9VeKFH2 rOOQFteKrhSHbe7B1ypK8vKdJlA14d5SbtsIX8aFioBjIyuSOh9zDvEEnHI6LFqsElJxKEOfs8aCE WngI25tsgnJRtGMGBjDtIA==; 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 1pLhLQ-0003fM-7z; Sat, 28 Jan 2023 04:17:56 -0500 In-Reply-To: (message from Stefan Monnier on Fri, 27 Jan 2023 18:57:20 -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:302709 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org, Andrea Corallo , Lars Ingebrigtsen > , Rob Browning > Date: Fri, 27 Jan 2023 18:57:20 -0500 > > AFAICT the main issue is how to handle the case where the home directory > is not writable (or doesn't exist). I think the Debian packaging needs > mostly stem from this. The Debian use case has other solutions, which don't require disabling native-compilation. I never understood why they insisted on disabling, instead of, say, redirecting the eln-cache to some suitable place, whether a throwaway directory like /tmp or some other directory. I hope maybe Rob will respond now and we could finally understand why they want to disable the compilation, or they will understand why disabling is not needed. Or maybe they do use the redirect-eln-cache solution after all, and we just don't know? In any case, inhibit-automatic-native-compilation, as implemented now, doesn't actually disable compiling the trampolines, it just writes them to /tmp. So if that is okay with Debian, why isn't it okay to tweak native-comp-eln-load-path to do the same to begin with, I wonder? > For "normal" compilation, we should just make sure that in the absence > of a writable eln cache Emacs still behaves correctly, i.e. it should > just load the `.elc` file and move on (without native-compiling it). That is already happening, and either native-comp-deferred-compilation or inhibit-automatic-native-compilation will disable the following async compilation. We had this through the entire Emacs 28 release cycle, and the only new issue that came up was with the trampolines that are still being compiled and written to the eln-cache. > For trampolines, in the short term we should probably add a fallback to > use an eln-cache in the `temporary-file-directory` (i.e. use the code > we currently use when `inhibit-automatic-native-compilation` is non-nil). This have two problems: . it cleans up only on Posix platforms . it is fundamentally broken, since it doesn't actually prevent native-compilation, so if the system cannot natively compile at all (e.g., if Binutils are not available), this will still signal errors The only solution we could come up with for the latter part is not to compile trampolines at all, and it has another adverse effect: advices for primitives will not work. I don't see any way around these two problems, we could only make comp-enable-subr-trampolines a variable that has more than just 2 boolean values, so that people could tweak the behavior to whatever problems they have with trampolines. > I think together this should let Debian get the behavior they want, by > setting HOME to /doesntexist. And that should make both > `inhibit-automatic-native-compilation` and > `EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION` unnecessary. Such a solution was proposed, but for some reason Debian didn't like it, or at least that was my impression. And again, why should we only consider the Debian use case? > - There's of course the problem of needing to compile trampolines when > GCC is absent. The current `make trampolines` kind of solves that, > but it's ridiculously inefficient (the code for the trampolines is > trivially small, compared to the size of the generated `.eln` > trampoline files). Why is that a problem? if we leave the compilation of trampolines to run time, we will produce those same small files, right? And if you think about having a single .eln file with all the trampolines, that is inefficient in another sense: we'd be wasting memory by loading trampolines which are not actually needed. So I'm not sure I see a significant problem here or a significantly better solution for it.