From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: tomas@tuxteam.de Newsgroups: gmane.emacs.devel Subject: Re: Add a configure option for NATIVE_FULL_AOT? Date: Wed, 18 Aug 2021 18:56:53 +0200 Message-ID: <20210818165652.GD9542@tuxteam.de> References: <83fsv75w43.fsf@gnu.org> <20210818073349.GC18126@tuxteam.de> <835yw354rb.fsf@gnu.org> <20210818133233.GA3470@tuxteam.de> <83pmua50jd.fsf@gnu.org> <20210818162216.GB9542@tuxteam.de> <83eeaq4t2m.fsf@gnu.org> <20210818163455.GC9542@tuxteam.de> <83czqa4sb8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7DO5AaGCk89r4vaK" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26410"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 18 18:58:37 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 1mGOth-0006dp-4S for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Aug 2021 18:58:37 +0200 Original-Received: from localhost ([::1]:45230 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGOtf-00079A-2Z for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Aug 2021 12:58:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44730) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGOs5-0004Md-Bj for emacs-devel@gnu.org; Wed, 18 Aug 2021 12:56:57 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:48696) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1mGOs3-0001dB-H6; Wed, 18 Aug 2021 12:56:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=Y902pznf0Tb0LlsGFvQAhGg0CEpmmSRAg/yXBF6uwgI=; b=Z4yluGs+NVmOJHyA2EPzGUM4zQBsT2ck3coT25bWI9sJUeDMXq++UOH42BeD7TQvR+hHRvhOfabnfhSyer5kRPngsx9o3leP/NGcEh4fwd030GjjfPdZ6zCRGBBSDmQ628DfjTRV49dzbxLQ4eBYLI4bZjR4njmdnuTz28EcZjBOU1aEfEKL8MKCvbqbfgppXzwrFamgdgfMaRP/hc4pgE0C8OQbezOy81H2ySEWOAPZZT8yCGqGBlcgQrcyntnHnLG5hjDuSzZY+GKLUEFO8zV/V3C2Oz7AaewvwGjcA8fx1AFMEXMShDifc17jSM49+nTsaCgDVlFht9GcLbVTiQ==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1mGOs1-0003ZE-0N; Wed, 18 Aug 2021 18:56:53 +0200 Content-Disposition: inline In-Reply-To: <83czqa4sb8.fsf@gnu.org> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de 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, SPF_HELO_NONE=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.23 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:272593 Archived-At: --7DO5AaGCk89r4vaK Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I feel sorry for wasting your time in this way. On Wed, Aug 18, 2021 at 07:43:23PM +0300, Eli Zaretskii wrote: > > Date: Wed, 18 Aug 2021 18:34:55 +0200 > > From: tomas@tuxteam.de > > Cc: emacs-devel@gnu.org > >=20 > > > > When the user wants to change a distribution-specific .el, the defa= ult > > > > way to do it would be to make a user-writable copy somewhere in a > > > > user-controlled directory (ISTR there was a mechanism doing this > > > > semi-transparently, but I may be confused). If `load-path' is set up > > > > correctly, the user's variant takes precedence. Same would go for > > > > .eln files resp. native-comp-eln-load-path, right? > > >=20 > > > Nominally, yes. But then you have 2 copies of the same .eln file, in > > > 2 different places. > >=20 > > They would be different, one of them from an .el with user changes. >=20 > Sure, that's my point. And we want the user's .el and the corresponding .eln to override the system-provided ones. So those (more precisely: their directories should go first in their corresponding paths, right? > How would that precedence work, except by relying on the order of the > directories in the list? I must have expressed my thoughts too clumsily. I do agree with you that the several paths are in order of descending preferences. What I'm implying from that is that the place for the user's .eln files should be more at the front of this path, so the .jit mechanism should put them there, if they have to override the system-provided ones. > > [1] provided our "them" refers to the same thing: "the .eln files > > freshly compiled in the user's behalf, because Emacs has seen > > an .el(c) file it had not seen before" >=20 > I don't understand this part. The *.elc files add yet another > "interesting" aspect to the issue, but that's a story for another day. Let's forget about those for now :-) Cheers - t --7DO5AaGCk89r4vaK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAmEdO9QACgkQBcgs9XrR2kYwxwCfTkcYhlb3szZWlClDQyLFgTED isQAniBCkBEEJdkxVtXxO3JKJsAM8PF8 =QstW -----END PGP SIGNATURE----- --7DO5AaGCk89r4vaK--