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: Fri, 20 Aug 2021 09:20:14 +0200 Message-ID: <20210820072014.GC9839@tuxteam.de> References: <83zgtg57jv.fsf@gnu.org> <87r1er3oqr.fsf@igel.home> <83lf4z6hh0.fsf@gnu.org> <87r1er8b3e.fsf@igel.home> <87tujm4ut1.fsf@wavexx.thregr.org> <20210819070409.GB13517@tuxteam.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Uq4LBwYP4y1W6pO" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10502"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 20 09:21:00 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 1mGypn-0002YR-TT for ged-emacs-devel@m.gmane-mx.org; Fri, 20 Aug 2021 09:21:00 +0200 Original-Received: from localhost ([::1]:32848 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mGypm-0004gD-28 for ged-emacs-devel@m.gmane-mx.org; Fri, 20 Aug 2021 03:20:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mGyp9-0003yx-QH for emacs-devel@gnu.org; Fri, 20 Aug 2021 03:20:19 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:53438) by eggs.gnu.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.90_1) (envelope-from ) id 1mGyp7-0002L4-1N for emacs-devel@gnu.org; Fri, 20 Aug 2021 03:20:19 -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=idK26MF5N5FhihjmD65y66eB3pBdWH4Vuxgo0LpcQ0Q=; b=NO6Wxq9WkwKOfUX6PiS5PID6VEFNv46CmqOtL6v8R6CIOAP+MLxBtuApn68WnHuXW75soxBBAyo0k11UXLOwDz0qJds3Ew2uc3BDAy8zZkEiq+ll2U7+NSXWgJM+HIu75LM8rXQuMtCta3lOBNjGxoCc106Focr9fJ07S7eHzRHBEHozhCGfufrGxVLCltdpAAMN5G0Geq7uRwfkcQJsvbERz7eZM1/USTZH5kLt5LhNR+FUqDV3kGi0qzDNUgFvt7LaBlsDXlMyO3QiM+DjNZc7erQpCVZskK9aF1qPERQn012gJ7BfPzeygUfnpozGN1P53aN0vLYRJFuiUOfsKQ==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.80) (envelope-from ) id 1mGyp4-0003Qe-2c; Fri, 20 Aug 2021 09:20:14 +0200 Content-Disposition: inline In-Reply-To: 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:272698 Archived-At: --/Uq4LBwYP4y1W6pO Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 19, 2021 at 11:17:57PM +0200, Arthur Miller wrote: > writes: >=20 > > On Thu, Aug 19, 2021 at 02:57:55AM +0200, Arthur Miller wrote: > >> Yuri D'Elia writes: > >>=20 > >> > On Wed, Aug 18 2021, Andreas Schwab wrote: > >> >> On Aug 18 2021, Arthur Miller wrote: > >> >> > >> >>> Sorry, I picking on it, I know that most of distributions do so, b= ut > >> >>> that is unfortunate practice against the nature of Emacs as applic= ation, > >> >>> since Emacs comes with sources as fully modifiable and extendable > >> >>> editor. > >> >> > >> >> Nothing prevents you from reading and modifying the lisp files. > >> Y > >> > I don't want to add anything which hasn't been said by others alread= y, > >> > but just point out that the way that emacs is packaged in debian is > >> > actually pretty nice and convenient for many users, especially in a > >> > multi-tenant setup. > >> I haven't seen a Debian since somewhere around 2001 or something, so I > >> really don't know how they do. But I think that many distros put elisp > >> in /usr/share which is not user modifiable location by default. > > > > Basically, this is the FHS. /usr/share is for architecture-independent, > > mostly immutable [1] stuff. Scripts written in some scripting language. > > Timezone data. Bytecodes. That kind of stuff. >=20 > So emacs sources should not be in there. That depends on what you mean by "sources" :-) C sources "typically" not. But .el sources can be thought of as "scripts", so possibly yes. Operatively, they can be replaced by the .elc, so a distro which wants to give users the choice of "not installing sources" (e.g. you want to *use* Emacs on your constrained Raspi, but to hack on it you've got your shining new $10K Linux laptop), .el wouldn't go there. Debian, for example has one source package for each (set of) binary package(s), including all the necessary buildery to reproduce those. If you want sources, you download those. I think RedHat-ish distros work more or less the same. > But than as other stuff also > will also not end there, like .elc files if .el files are not there it > almost implied that nothing of Emacs should be in /usr/share :-). =2Eelc are arch-independent files. Those are the typical examples of things which go there. Also possibly .el, especially in the cases you don't want them compiled. Icons, .xml, that kind of stuff. Docs (/usr/share/doc). To get an idea on what Debian (courtesy of the Emacsen maintainer, Rob Browning) puts there for Emacs, have a look at [1]. > So I > guess, as suggested, someone who wishes to modify Emacs sources should > download sources to their home directories and load after so all > headaches avoided :). That's the way I do it, since I compile from sources anyway. But if someone wants to just override one .el in the whole kaboodle, and this perhaps only temporarily, I don't see why the distro would have to force her to do that, while there are easier ways. > > But in these days of emulators [...] share... my /usr/share, > > which is kind of nifty :-) >=20 > Indeed, that is nifty. Actually this is just the repetition of one pattern, that of the "nested environments", so dear to us in programming languages (think scopes). The innermost environment takes precedence over the next outer layers of the onion [2]. The world is a tree, where "your" private world only depends on your path to the root. Yadda, yadda. In the current OS context, there are three main layers -- operating system (/bin, /lib, /usr/bin, etc.), machine instance (/usr/local and so on, but also /etc), user whithin machine (/home/foo, mostly). Somewhere between OS and machine instance there is another layer, machine architecture. That's why I was so surprised to see the tendency here "every user has all of their .eln files in a local place". I'm not convinced at all that this is a good idea [4]. Eli seems to be convinced of this, and he's a much smarter person than me. Interesting :-) Cheers [1] https://packages.debian.org/buster/all/emacs-common/filelist [2] I should rather say "shallot" [3], since it has several cores, resembling more the tree structure. Besides... yummy ;-) [3] https://packages.debian.org/buster/all/emacs-common/filelist [4] I'd prefer those .eln derived from (unchanged) system files to live in system places (outer layers of the shallot), and be provided, pre-compiled, by the system. Possibly in the architecture-dependent layer (they're architecture-dependent, I guess). - t --/Uq4LBwYP4y1W6pO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAmEfV64ACgkQBcgs9XrR2kYLqwCeLlZSAGi+snTp4iE6GpSpMgSJ emUAn2WPRbcuI66jREr48SXEiPgDbRUw =JRZb -----END PGP SIGNATURE----- --/Uq4LBwYP4y1W6pO--