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: Thu, 09 Feb 2023 09:40:35 +0100 Message-ID: <87mt5ncjuk.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> <87ttzy2lgi.fsf@X570GP> <83a61pprm8.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="11658"; 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 Thu Feb 09 09:51:42 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 1pQ2ec-0002qa-2g for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Feb 2023 09:51:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQ2eM-00005v-NA; Thu, 09 Feb 2023 03:51:27 -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 1pQ2U1-0003Z1-Fr for emacs-devel@gnu.org; Thu, 09 Feb 2023 03:40:45 -0500 Original-Received: from forward500c.mail.yandex.net ([178.154.239.208]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pQ2Tx-0006N9-PT; Thu, 09 Feb 2023 03:40:45 -0500 Original-Received: from iva2-656890eaceb5.qloud-c.yandex.net (iva2-656890eaceb5.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:6902:0:640:6568:90ea]) by forward500c.mail.yandex.net (Yandex) with ESMTP id 235825F488; Thu, 9 Feb 2023 11:40:38 +0300 (MSK) Original-Received: by iva2-656890eaceb5.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id ZeZ0fu0ZcGk1-JjtV3MfR; Thu, 09 Feb 2023 11:40:37 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1675932037; bh=Rq4a080uovys2JV5ERxNZGh4JUSJLZMIrGhhkjJOsek=; h=Cc:Message-ID:References:Date:Subject:In-reply-to:To:From; b=NaozIQ50qPBD7nVQxCYMhlyDo7rpNzpMrLsXq5TepL6IDIMoRrXMEr+GafwWNBtp0 YPeZlkVotFKkmS9d/6rMElSyRC0LllYnAkvd3rAhzR4fsUY8AvPKZMXoG5i+di1qXt uaAS1+0tuLskkeTmzNtcdKzdWf1YpBup3k/ogLDo= Authentication-Results: iva2-656890eaceb5.qloud-c.yandex.net; dkim=pass header.i=@yandex.com In-reply-to: <83a61pprm8.fsf@gnu.org> Received-SPF: pass client-ip=178.154.239.208; envelope-from=aymeric.agon@yandex.com; helo=forward500c.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: Thu, 09 Feb 2023 03:51:22 -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:303068 Archived-At: Le mardi 7 f=C3=A9vrier 2023 =C3=A0 14:49, Eli Zaretskii a=20 =C3=A9crit : > I don't think I follow: why not? > Why do you need it to be the first directory? What I am going to describe is true only in the specific setting I=20 am presenting, projectile. After the advice of `file-exists-p' so as to make it always return=20 t, implemented by this line : (spy-on 'file-exists-p :and-return-value t) Whenever we enter the function `comp-subr-trampoline-install', for=20 instance when we advise another primitive, we will enter the=20 function `comp-trampoline-search' if : - we have trampoline compilation enabled - AND the primitive has not been excluded from trampoline=20 compilation - AND the trampoline is not already installed we will try to install the trampoline, by either finding it on the=20 filesystem, or if we don't find it, by compiling it. If `file-exists-p' has been advised as to always return t,=20 `comp-trampoline-search' will *always* return a filename of the=20 form : /subr--trampoline-_.eln (or something like this) *Regardless* of whether said file actually exists, and in=20 particular even when it should really return nil because the file=20 does not exist. So if this file that `comp-trampoline-search' assures us to exist=20 does not, we reach the error. So the point was, in order not to reach the error, we need : - the file subr--trampoline-_.eln to already=20 exist. - AND for it to be in the first directory returned by=20 `comp-eln-load-path-eff'. This was just to show that avoiding the problem without resorting=20 to deactivating trampoline compilation for this specific primitive=20 is too complicated to bother with. I hope this answers your first two questions. > Are you sure you interpret this correctly? what do you think=20 > being a > "system one" means for the purposes of your situation, and why=20 > is that > important in the first place? I just meant that maybe this assumption of the last directory in=20 the list being /usr/lib/emacs//native-lisp was used=20 somewhere else, and that we should not violate it. In fact, I seem to remember that a function to prune eln cache=20 directories from stale eln files was discussed on emacs-devel and=20 even implemented. This function was later patched as to exclude=20 the system eln cache from such pruning, for some reason I do not=20 remember. The "system" eln cache was identified by its being the=20 last in the list. So there is in fact at least one place in emacs=20 where this assumption is used, and maybe Andrea or Lars or Stefan=20 could find others. But again, this was just part of the hypothetical thinking of=20 "what should we do if we want to avoid this specific problem=20 without resorting to disabling primitive trampoline=20 compilation". That was confusing rather than clarifying, my=20 mistake. All the more since we agree on the necessity to be able to disable=20 trampoline compilation. > We intend to modify comp-enable-subr-trampolines so that it=20 > could > accept a string value, which would be interpreted as the=20 > directory to > place compiled trampolines. Would that be good enough? So if I follow, we would have these different possible values for=20 `comp-enable-subr-trampolines' : - nil means not compiling trampolines (no change with now) - t means compiling them, and outputting them in the location=20 either pointed by `native-compile-target-directory' if it=20 exists, the first valid directory returned by=20 `comp-eln-load-path-eff' if not (no changes with now) - a string value means compiling them, and outputting them in the=20 location pointed by the string (error if unwritable, or fallback=20 to `native-compile-target-directory' or `comp-eln-load-path-eff'=20 possibly ?) (this is new) Would it possible to add a constant value, like=20 'compile-but-no-output, that would have exactly the second=20 behaviour I was mentioning before, that is compiling trampolines=20 but not even trying to output them anywhere, by passing nil as the=20 last argument of `comp--native-compile' ? > The problem I'm trying to solve is that a boolean variable, > inhibit-automatic-native-compilation, has a two effects that=20 > cannot be > separated. I'd like to have two variables instead That's perfectly reasonable. We would just like to be able to=20 replicate with these two variables exactly what=20 `inhibit-automatic-native-compilation' did. > You could do this in the early-init file, which is processed > approximately at the same place in normal-top-level. If I am not mistaken, the early init file's name is fixed, and is=20 looked for in various places in the user's home. We do not have an=20 existing home in our build environment. Best, Aymeric