Re: Add a configure option for NATIVE_FULL_AOT?

[<tomas@tuxteam.de>]

[-- Attachment #1: Type: text/plain, Size: 3166 bytes --]

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.

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 :-)

> I am trying to see what Emacs uses by default choice [...]

[...]

Actually those are the things the FHS developed from. And yes, by
default /usr/local makes sense: that's where you want to have the
stuff installed when you compile things yourself: the distro won't
touch them.

But it provides infrastructure for you to use them. Have a look at
your default $PATH: you'll typically see "/usr/local/bin" before
"/usr/bin". There are many, many places where this precedence of
/usr/local before /usr is encoded. /etc/ld.so.conf*, as another
example.

> > I definitely see the same concept being extended to AOT and being a net
> > advantage in such cases.
> 
> A problem with Emacs is that, there are different cases for different
> users, which sometimes even get orthogonal to each other so it can be
> hard to make everyone happy att same time.

Definitely. Not only different users, but also different usages. My
system has about 2k packages installed. Some of them I barely know
by name. I'm infinitely thankful to the Debian Developer who keeps
them happy and humming for me. Others are my pets, I download their
source, learn their build quirks (Emacs is one of them, you guessed).
Those go to /usr/local :-)

Cheers

[1] During installation & updates all bets are off :-)
[2] A bit more of effort is needed, of course, like Debian's Multi-Arch,
   which splits /usr/lib into /usr/lib/<arch-triple>, but I think it's
   totally worth it :-)

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]