emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add a configure option for NATIVE_FULL_AOT?


From: Arthur Miller
Subject: Re: Add a configure option for NATIVE_FULL_AOT?
Date: Thu, 19 Aug 2021 23:17:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

<tomas@tuxteam.de> writes:

> On Thu, Aug 19, 2021 at 02:57:55AM +0200, Arthur Miller wrote:
>> Yuri D'Elia <wavexx@thregr.org> writes:
>> 
>> > 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, but
>> >>> that is unfortunate practice against the nature of Emacs as application,
>> >>> 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 already,
>> > 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.

So emacs sources should not be in there. 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 :-). 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 :).

> The idea of separating arch-independent and arch-dependent stuff stems
> from old times where disk space was at a premium and you wanted to share
> one /usr via NFS in your heterogeneous network. A kind of deduplication,
> if you like.
>
> But in these days of emulators, cross-compiles and cross-builds it does
> reveal a big potential. With qemu and some luck I can run things meant
> for a Raspberry Pi on my AMD64 laptop [2] and share... my /usr/share,
> which is kind of nifty :-)

Indeed, that is nifty.
 
Thanks for deatiled mail, that was indeed an interesting read!

Cheers!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]