Re: Add a configure option for NATIVE_FULL_AOT?

[<tomas@tuxteam.de>]

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

On Wed, Aug 18, 2021 at 05:23:40AM +0300, Eli Zaretskii wrote:
> > From: Ulrich Mueller <ulm@gentoo.org>

[...]

> > In the scenario I had in mind the *.el files (as well as the *.eln
> > files) would be installed as part of a distro's Emacs package.
> > They would live somewhere under /usr where the user has no business.
> 
> It is strange for a Free Software project to assume the user will
> never want to modify the sources.

I think that's the wrong conclusion there hidden between your two
lines.

A distribution has to strike a balance between a novice user not
messing up the whole system for herself and the other users, those
individual users being able to override selected parts of the
distribution-provided stuff and system administrators (which most
of the times are the users themselves) changing the system in ways
that an operating system upgrade doesn't cause havoc.

That's why there are, in general ascending order of precedence,
several layers of "places" to consult when looking for an executable,
a library, a package, a doc, or whatever tidbit of infrastructure
you OS offers.

 - system "directories" [1]
   (think /usr/lib, /usr/bin and so on)
   Those are typically provided by the system installation. E.g.
   the distro. The distro is free to change that stuff on upgrades
   and is free to assume the sysadmin doesn't change these. If
   and when she does, she gets to hold both pieces, especially
   after a system update.

 - system-local "directories"
   (think /usr/local/lib and so on [2])
   Locally (in "this system") installed stuff, accessible by all
   users ot this system). Typically the stuff my sysadmin (hey,
   that's me) and myself decide to compile and install. Distro
   has no business there. My Emacs, since it is one very important
   app for me, is in /usr/local/bin & friends.

 - user-local "directories"
   what each user does for herself. For example I have a ~/.bin.
   For Emacs, I have some ~/.emacs.d/lisp

One popular mechanism to cope with that is that apps have one or
more "paths", fashioned after the shell's $PATH, which list, in
descending order of precedence, where to look for some service
or other bit of infrastructure.

Cf. Emacs's variable `load-path'.

Now I assume I'm boring all of you with well-known things, but I
really don't understand why .eln files would be so different that
they can't follow (some variation of) the `load-path' pattern?

Cheers

[1] I'm putting directory in quotes, because not all is in the
   file system. It's more the pattern than the actual implementation
   (although the implementation /is/ often at this level, but there
   are counter-examples).

[2] Some vendors have a crush on /opt. I don't like it that much,
   because I don't want a third-party vendor giving itself so
   much importance. My sysadmin and me decide on what is important
   and what not).

 - t

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