From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Building a release tarball generates trampoline files in eln-cache Date: Thu, 11 Nov 2021 15:08:16 +0000 Message-ID: References: <8335pay5j0.fsf@gnu.org> <83h7dkm8n4.fsf@gnu.org> <831r4lid0n.fsf@gnu.org> <83zgr9gvvp.fsf@gnu.org> <83y26tgupl.fsf@gnu.org> <83bl3ogpob.fsf@gnu.org> <83r1c6v36p.fsf@gnu.org> <837ddqjt16.fsf@gnu.org> <83wnlqibkx.fsf@gnu.org> <83bl30fa3m.fsf@gnu.org> <83bl2u7kke.fsf@gnu.org> <83h7cj3lha.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33666"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 11 16:09:23 2021 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 1mlBha-0008Yq-S3 for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Nov 2021 16:09:22 +0100 Original-Received: from localhost ([::1]:54922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mlBhV-00060G-Uv for ged-emacs-devel@m.gmane-mx.org; Thu, 11 Nov 2021 10:09:18 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:58794) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlBgg-0002BP-T4 for emacs-devel@gnu.org; Thu, 11 Nov 2021 10:08:26 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:64717) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlBgd-0007bL-WC; Thu, 11 Nov 2021 10:08:26 -0500 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 1ABF8GHh005260 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 11 Nov 2021 15:08:16 GMT In-Reply-To: <83h7cj3lha.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 10 Nov 2021 20:37:53 +0200") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:279261 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org >> Date: Tue, 09 Nov 2021 21:55:03 +0000 >> >> Option 2 would be to postpone the native compiler load (if needed) to a >> point were we are sure it can be loaded. > > You mean, bind no-native-compile to a non-nil value until after some > point in startup.el? I was thinking to something a little different like recording what we wanted to compile when it was not possible cause too early in the startup. When startup is finished if this list of pending files is not empty we should load comp.el (and its dependencies) and then consume the list of pending .el files to be compiled (possibly including comp.el as well). > That could work (I actually tried that, but > under the assumption that xterm.el was the problem, so it didn't > help). But why do you think this problem happens only early during > startup? Suppose we cross that bridge, and then Emacs needs to load > some Lisp file that wasn't natively-compiled -- won't we have the same > problem and for the same reason? The first gv-get in the backtrace is > called as part of compiling, so it sounds like every compilation is in > the danger of triggering this problem, because compiling needs > gv-setter again. Or what am I missing? The first `gv-get' is part of a byte compilation. With the proposed mechanism it should go through postponing the comp.el load to say when we return to `normal-top-level'. That's not a trivial problem, I might be missing something I don't see ATM. Andrea