From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aymeric Agon-Rambosson Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Tue, 07 Feb 2023 04:39:09 +0100 Message-ID: <87ttzy2lgi.fsf@X570GP> References: <837cx8cey0.fsf@gnu.org> <83357vauh5.fsf@gnu.org> <837cx6a8me.fsf@gnu.org> <83357ua6ja.fsf@gnu.org> <83zga28ra8.fsf@gnu.org> <83r0vd97s0.fsf@gnu.org> <83lell73yv.fsf@gnu.org> <87sffo3as7.fsf@melete.silentflame.com> <83v8kkxzzx.fsf@gnu.org> <87r0v811pm.fsf@melete.silentflame.com> <87cz6nxdqy.fsf@X570GP> <83357irhnv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5467"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.6.10; emacs 28.1 Cc: spwhitton@spwhitton.name, monnier@iro.umontreal.ca, emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 07 13:01:47 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 1pPMfR-0001CO-F3 for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Feb 2023 13:01:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPMen-0002AE-V1; Tue, 07 Feb 2023 07:01:06 -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 1pPEpF-0004h4-06 for emacs-devel@gnu.org; Mon, 06 Feb 2023 22:39:21 -0500 Original-Received: from forward501a.mail.yandex.net ([178.154.239.81]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pPEp9-0006FB-Hk; Mon, 06 Feb 2023 22:39:20 -0500 Original-Received: from vla1-19b50e1e87d6.qloud-c.yandex.net (vla1-19b50e1e87d6.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:3e8b:0:640:19b5:e1e]) by forward501a.mail.yandex.net (Yandex) with ESMTP id 50DE15EAA4; Tue, 7 Feb 2023 06:39:12 +0300 (MSK) Original-Received: by vla1-19b50e1e87d6.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id 9dSvpb4VceA1-9GhjdFjC; Tue, 07 Feb 2023 06:39:11 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1675741151; bh=6P1EnkGclDre9jUOcDyctEQvbWxDVtQO2QKNwGAMSq4=; h=Cc:Message-ID:References:Date:Subject:In-reply-to:To:From; b=C9WgK3nelBKFCHkXJeczPWgKmjEzUQahojcXgzRJ3gaOgPSker16bPKckQW7Xj470 +Jhr2cS80sHe/rk2aIO9S2CADhmx/roXQuVP60U3HZfI6XnBuqK1lLljAnqSIa6LQU sk0TKYpGQ4xFEmRZqzraiGBe6HkUeiUvCJOl8OgM= Authentication-Results: vla1-19b50e1e87d6.qloud-c.yandex.net; dkim=pass header.i=@yandex.com In-reply-to: <83357irhnv.fsf@gnu.org> Received-SPF: pass client-ip=178.154.239.81; envelope-from=aymeric.agon@yandex.com; helo=forward501a.mail.yandex.net 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Tue, 07 Feb 2023 07:01:01 -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:303032 Archived-At: Le lundi 6 f=C3=A9vrier 2023 =C3=A0 16:29, Eli Zaretskii a=20 =C3=A9crit : > I don't think I understand: the output of that function depends=20 > on > native-comp-eln-load-path, so why tweaking that is not enough? For this specific problem, if the trampoline has not already been=20 compiled, and can therefore be found in none of the directories in=20 the `native-comp-eln-load-path' list, being able to tweak the=20 variable does us no good. If we assume that all trampolines have been compiled beforehand by=20 a mechanism similar to "make trampolines", then we can find the=20 trampolines in the system eln cache directory, but we still need=20 to ensure that this system eln cache directory is the first in the=20 variable `native-comp-eln-load-path'. However, the docstring says=20 "The last directory of this list is assumed to be the system=20 one.". So for the variable `native-comp-eln-load-path', in order to=20 respect that assumption and solve our projectile problem, we can=20 either have : ("/usr/lib/emacs//native-lisp") or ("/usr/lib/emacs//native-lisp" "/usr/lib/emacs//native-lisp") The first solution works only if we are sure not to have to load=20 any native-compiled elisp from user cache directories, and we=20 don't have to native-compile any elisp (if we assume emacs running=20 as unpriviledged user). The second solution could work, I'm not sure whether the same=20 value being present twice would create problems. This projectile case is very specific, I admit, but just to give=20 you an idea of why we might want to avoid all of this and simply=20 disable trampoline compilation, either globally (which we did not=20 have to do until now) or a specific number of primitives (see the=20 list of my last message). > If those can help you solve your problem, I think that's "good=20 > enough" > for something that needs to be done in a test suite. My primary > target audience, in contrast, is Emacs users. I agree. For this specific case, disabling trampoline compilation=20 on the relevant primitives by modifying=20 `native-comp-never-optimize-functions' works (see=20 https://github.com/bbatsov/projectile/commit/e18ad4d6111eb9e975ccce028baf5e= 4bb786bfcf),=20 and is also the least intrusive way. And since it is not specific=20 to our build system, we can reproduce with the upstream sources=20 under specific circumstances, those can eventually be patched. > A similar solution could have solved your problem even if > inhibit-automatic-native-compilation didn't exist at all,and we=20 > only > had comp-enable-subr-trampolines and=20 > native-comp-deferred-compilation, > right? `inhibit-automatic-native-compilation' is not exactly the negation=20 of=20 `native-comp-deferred-compilation'. `inhibit-automatic-native-compilation'= =20 also disables the outputting of the result of trampoline=20 compilation to the file system, which solves the other problems=20 related to unwritable $HOME mentioned earlier. This new variable=20 allows for three behaviours : - Not compiling trampolines (`comp-enable-subr-trampolines' set to=20 nil) - Compiling them, but not outputting them to the filesystem=20 (`comp-enable-subr-trampolines' set to non-nil, and=20 `inhibit-automatic-native-compilation' set to non-nil) - Compiling them and outputting them to the filesystem=20 (`comp-enable-subr-trampolines' set to non-nil, and=20 `inhibit-automatic-native-compilation' set to nil) By contrast, `native-comp-deferred-compilation' and=20 `comp-enable-subr-trampolines' only allowed for the first and the=20 third behaviour. This second behaviour is the one we use by=20 default now. The trampolines are used in the test (except in the=20 pathological cases where they make emacs error or make the test=20 fail), but we do not worry about where to output them, because we=20 don't. > Why do you need this to be done together with disabling native > compilation? why not do it with two separate settings? We could do it with two separate settings, but if it is decided=20 not to get rid of environment variables, that would mean two of=20 them. > I understand the convenience, but once again, my primary=20 > audience is > the Emacs users, and they rarely need to handle such convoluted > situations. Some relative inconvenience aside, I see no reason=20 > why > you couldn't make do without the environment variable, but via=20 > some > automatically-loaded init files or somesuch. I think there was some worry about whether an extra eval would=20 arrive "soon enough", that is before any native compilation would=20 have been attempted. In contrast, the value of the environment=20 variable is obtained at very beginning of `normal-top-level', that=20 is before any native compilation could possibly happen. Other than that, I agree that this is mainly a question of=20 convenience for us. So much so that, as Sean said, we would=20 probably patch it back should it be removed. On top of that, the=20 delta corresponding to the environment variable specifically is=20 negligible (1 line in normal-top-level) when compared to the delta=20 needed to implement the underlying=20 `inhibit-automatic-native-compilation'. Thanks !