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:34:55 +0200 Message-ID: <20210818163455.GC9542@tuxteam.de> References: <87r1er3oqr.fsf@igel.home> <83lf4z6hh0.fsf@gnu.org> <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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bAmEntskrkuBymla" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32781"; 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:36:11 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 1mGOXz-0008Dy-7e for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Aug 2021 18:36:11 +0200 Original-Received: from localhost ([::1]:39150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGOXx-0007mi-P6 for ged-emacs-devel@m.gmane-mx.org; Wed, 18 Aug 2021 12:36:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGOWq-0006yi-1c for emacs-devel@gnu.org; Wed, 18 Aug 2021 12:35:00 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:48650) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1mGOWo-0000IY-0p; Wed, 18 Aug 2021 12:34:59 -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=i4ApGgko6nX7izgRkNfjDOMn4sQ1gI9VqIuaVK5H584=; b=FI0HCbk59jAaLEPwyqqSENEYXVVPap/jMLcko4IS+4QaGDqLngGjCrcgQYjQ4et2iSEGAUldCSw63HaQTb9vJzLfevik6GrravE8E34Kfwuw3qe/SDbz9tJmFT8FrjwrkRBp/3pgSMyqDCyrF3VhUQRq8K5YVAlPSC63K2tRlzuDC/e6/QKwiPN2nx6f9HgRKrp9MJqFLeYIMGZiyHt/Q/jeQel/vM6/JeJA4Knhk4RBtpN2C3cAepB6ZToB/Lstqk+TC91ep+v/k833k+e+OFBSyrmmjGk3JtE3a/1f71QjSmfIz9duIYBCN7wqSpr4v+yE5VS0yI8fjvmP1ZkEhg==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1mGOWl-0003FU-PV; Wed, 18 Aug 2021 18:34:55 +0200 Content-Disposition: inline In-Reply-To: <83eeaq4t2m.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:272587 Archived-At: --bAmEntskrkuBymla Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 18, 2021 at 07:26:57PM +0300, Eli Zaretskii wrote: > > Date: Wed, 18 Aug 2021 18:22:16 +0200 > > From: tomas@tuxteam.de > > Cc: emacs-devel@gnu.org > >=20 > > When the user wants to change a distribution-specific .el, the default > > 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. They would be different, one of them from an .el with user changes. > That's got to confuse people and perhaps create > hard-to-debug situations where Emacs behaves erratically. >=20 > > > We actually do use native-comp-eln-load-path to also decide where to > > > store the *.eln files, but that uses a simplistic heuristic that > > > treats the last element of the list specially. The heuristic is > > > hard-coded in several places, so not easily overridden. > >=20 > > Oh, the /last/ element, i.e. the one with the least precedence is the > > one where .eln files are stored? There goes my house of cards. > > Interesting ;-) >=20 > The preloaded *.eln files are stored there, yes. But why on the "least precedence" slot, i.e. in the place at the list's tail? I'd have expected them to be stored in the place at the list's head. > How else would you > arrange for them to be of the least precedence, when lists are > generally searched head to tail? Why would I want to arrange "them" [1] to be of the least precedence? A freshly user-compiled file should have the highest precedence, IMO. You see: those are the interesting details I've not yet digested, it seems :-) Cheers [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" - t --bAmEntskrkuBymla Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAmEdNq8ACgkQBcgs9XrR2kZrZgCfYSS42xXC+jq8r4fIjFU/oYHX JrsAnRzudSEekDpcZUE87t0go2/XfRJ3 =IiIL -----END PGP SIGNATURE----- --bAmEntskrkuBymla--