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: Thu, 09 Feb 2023 12:11:11 +0200 Message-ID: <83cz6jm9mo.fsf@gnu.org> 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> <87mt5ncjuk.fsf@X570GP> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23917"; mail-complaints-to="usenet@ciao.gmane.io" Cc: spwhitton@spwhitton.name, monnier@iro.umontreal.ca, emacs-devel@gnu.org, akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org To: Aymeric Agon-Rambosson Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 09 11:11:46 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 1pQ3u6-000614-3n for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Feb 2023 11:11:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pQ3tI-00036b-IS; Thu, 09 Feb 2023 05:10:56 -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 1pQ3tH-00035u-AI for emacs-devel@gnu.org; Thu, 09 Feb 2023 05:10:55 -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 1pQ3tF-0004aq-Uu; Thu, 09 Feb 2023 05:10:53 -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=erC3VnIHa31MA/2MILnqxtC12yuDvLJ9mt0yXEWZUGU=; b=Qm93rFXwN9Qz DMLmc6Qwz/A29q4CjhYb+FSVaVJbVw5EWwyTErPuiTu8tQpqBY+4SDaL7vSpeBk9XkSHaxeKW82nA 5MydxBHJhAXut2oDLw37DAzgqxDRIQ1wYrYRRF0/j38p76za0bnEMJPAbBg+zZy0kC46+hiFKDgJr fIRsnLRRNBN7s5t6V4w35xfxRUNx/5h4nLkqkriDu5MlXMnW1SHfNeIfK3lmrHdtzUxTk01r1EwsD WRwMRPoooBTus20LOaGENXcE8vhh1dwjPDxkK+PV97G+FZySENtQplLlmBmLNanCfkdQBiqIE9R0E lbWHzq8tIxdBoglZTR2ufQ==; 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 1pQ3tE-0002qH-L4; Thu, 09 Feb 2023 05:10:52 -0500 In-Reply-To: <87mt5ncjuk.fsf@X570GP> (message from Aymeric Agon-Rambosson on Thu, 09 Feb 2023 09:40:35 +0100) 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:303069 Archived-At: > From: Aymeric Agon-Rambosson > Cc: spwhitton@spwhitton.name, monnier@iro.umontreal.ca, emacs-devel@gnu.org, > akrl@sdf.org, larsi@gnus.org, rlb@defaultvalue.org > Date: Thu, 09 Feb 2023 09:40:35 +0100 > > After the advice of `file-exists-p' so as to make it always return > t, implemented by this line : > > (spy-on 'file-exists-p :and-return-value t) > > Whenever we enter the function `comp-subr-trampoline-install', for > instance when we advise another primitive, we will enter the > function `comp-trampoline-search' if : > - we have trampoline compilation enabled > - AND the primitive has not been excluded from trampoline > compilation > - AND the trampoline is not already installed > > we will try to install the trampoline, by either finding it on the > filesystem, or if we don't find it, by compiling it. > > If `file-exists-p' has been advised as to always return t, > `comp-trampoline-search' will *always* return a filename of the > form : > > comp-eln-load-path-eff>/subr--trampoline-_ name>.eln (or something like this) > > *Regardless* of whether said file actually exists, and in > particular even when it should really return nil because the file > does not exist. > > So if this file that `comp-trampoline-search' assures us to exist > 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 > exist. > - AND for it to be in the first directory returned by > `comp-eln-load-path-eff'. So the problem happens because the advice uses the first directory returned by comp-eln-load-path-eff, for the value it returns, is that right? If so, could this then be fixed by changing the advice? > I hope this answers your first two questions. It does, thanks. > > Are you sure you interpret this correctly? what do you think being > > a "system one" means for the purposes of your situation, and why > > is that important in the first place? > > I just meant that maybe this assumption of the last directory in > the list being /usr/lib/emacs//native-lisp was used > somewhere else, and that we should not violate it. The main reason of having the system directory last is so that packages could override *.eln files installed in the 'system" eln directory, which came with Emacs. > > We intend to modify comp-enable-subr-trampolines so that it could > > accept a string value, which would be interpreted as the directory > > to place compiled trampolines. Would that be good enough? > > So if I follow, we would have these different possible values for > `comp-enable-subr-trampolines' : > - nil means not compiling trampolines (no change with now) > - t means compiling them, and outputting them in the location > either pointed by `native-compile-target-directory' if it > exists, the first valid directory returned by > `comp-eln-load-path-eff' if not (no changes with now) > - a string value means compiling them, and outputting them in the > location pointed by the string (error if unwritable, or fallback > to `native-compile-target-directory' or `comp-eln-load-path-eff' > possibly ?) (this is new) Yes. If the directory pointed to by the value of comp-enable-subr-trampolines is not writable, I think Emacs should signal an error. Andrea, WDYT? > Would it possible to add a constant value, like > 'compile-but-no-output, that would have exactly the second > behaviour I was mentioning before, that is compiling trampolines > but not even trying to output them anywhere, by passing nil as the > last argument of `comp--native-compile' ? Argh, the last argument to comp--native-compile is not documented. AFAIR, setting it to nil means the trampoline will be written to temporary-file-directory, right? Because I don't think we can compile a trampoline without writing it to some file, from which we will thereafter load it. (Andrea, please correct me if I'm wrong.) If so, we could assume Lisp programs will use temporary-file-directory if they need this, would that be good enough? > > 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 > looked for in various places in the user's home. We do not have an > existing home in our build environment. Emacs 29 has the --init-directory command-line argument, which you could use to tell it to look for early-init file in a non-default place.