Re: Add a configure option for NATIVE_FULL_AOT?

[tomas@tuxteam.de]

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

On Thu, Aug 19, 2021 at 11:17:57PM +0200, Arthur Miller wrote:
> <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.

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

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

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