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: Thu, 19 Aug 2021 12:05:00 +0200 Message-ID: <20210819100500.GI13517@tuxteam.de> References: <87r1er3oqr.fsf@igel.home> <83lf4z6hh0.fsf@gnu.org> <83fsv75w43.fsf@gnu.org> <875yw3xpek.fsf@gnu.org> <838s0z552h.fsf@gnu.org> <83bl5t3obt.fsf@gnu.org> <20210819072706.GD13517@tuxteam.de> <83y28x26vg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IR1Y5IvQhrKgS4e6" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5863"; 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 Thu Aug 19 12:06:16 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 1mGewC-0001Do-Eo for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Aug 2021 12:06:16 +0200 Original-Received: from localhost ([::1]:44024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGewA-0003QG-Bg for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Aug 2021 06:06:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34662) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGevB-0002cP-Jl for emacs-devel@gnu.org; Thu, 19 Aug 2021 06:05:15 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:50820) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1mGev7-0002Zo-GZ; Thu, 19 Aug 2021 06:05:13 -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=BXQ9Qfob1Naz0ZA9rPPrEDu91hlGJ6UHeOqGq2mQkMc=; b=Nl50uIBH1NTl+0CqMgV11R3U63jriD8Pon6YM6MWxGOU/kBV2rdlE4UuY6iffMHKo6x1B6UueuP9qLddcqywrlzzQKJ21xFNNdKq5gYu/wn0D/ndnup54HSWCDM0cuUZoHS6AYbw6CH6J8O6sSIrcyRZtw4t81cICJacS/RMVwNfeRQB6vpKbE2m7mheVFKoIuagPsIXUIP5+NPwyk8ExR1vBYxnGwRgt2j0MCjXffQJKN3QsHdN4I8jUWbPx5vHaZSkpH9mh0ZAv7/IOmovjivp07lUBzRhmsCFEbL1DF2+HkSxdrglzNLKy1EmvreHee+TPNRh6ou6ID3wFHdcPg==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1mGeuy-0005uH-F7; Thu, 19 Aug 2021 12:05:00 +0200 Content-Disposition: inline In-Reply-To: <83y28x26vg.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:272658 Archived-At: --IR1Y5IvQhrKgS4e6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 19, 2021 at 11:09:23AM +0300, Eli Zaretskii wrote: > > Date: Thu, 19 Aug 2021 09:27:06 +0200 > > From: > >=20 > > I agree that this problem hasn't a trivial (or unique) solution. > > But this is something for distros to solve. Emacs has just to > > provide the mechanisms to make that possible (and, as far as I > > can see, it does). >=20 > This discussion started when a distro came here asking for a change > where Emacs already provides the mechanism to make that possible. But perhaps, it's possible as it is. What distors want, one way or another is to provide pre-compiled .eln files for the .el libraries they provide. At the same time giving users a way to override some of them locally. If Emacs is capable to locate the correct .eln (as far as I have understood now, it searches for the .el to resolve that), the above should be possible, no? For example, if the distro provides the .el (most probably those will be compressed, as .el.gz, but I think that's a transparent detail), the corresponding .elc and .eln) all would be well. If a user wants to hack on a single .el, she would typically copy that to a user controlled place [1] and the corresponding =2Eelc and .eln would also go to corresponding user-controlled spaces and would, hopefully, override the system-provided ones, if all `path' variables are set up correctly. It could well be that I'm missing something important, though. [1] She could (most of the time) also hack the files in-place, but updates would obliterate those changes. --IR1Y5IvQhrKgS4e6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAmEeLMwACgkQBcgs9XrR2kY0FwCfcJLSRcKR3ERJttLjUIAPZAQR VHwAnRIVYESie4BVEHS3kKQOx+RmWjpb =e2R3 -----END PGP SIGNATURE----- --IR1Y5IvQhrKgS4e6--