Re: Add a configure option for NATIVE_FULL_AOT?

[Arthur Miller <arthur.miller@live.com>]

tomas@tuxteam.de writes:

> 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.
Is there a laptop that costs $10k? What is deal with that? Cover made of
gold? :-)

> 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).
But with Emacs one might wish to modify sources (at least in theory)
even if when not compiling them to elc or eln. I don't know why would
someone wish to run only interpretted code, but a theoretical
possibility. Even docs are subject of use modification. I mean at least
on ideological level. Emacs is very atypical application in this regard.

But as suggested by several here, I can also agree that is more
pragmatic to just download/copy whichever file needs to be modified and
place it elsewhere, so I don't think we have to be super lazer precise
of what goes where.

> 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.
I actually run emacs from source dir. I compile it every few days, so it
does not really make sense to me to run make-install and copy over
everything to some other directory every now and then. Also when running
from source directory, without compressing sources, looking up stuff
with built in help is more efficient, and even on my i7 6700k desktop
with 32 gig ram and m.2 970 Pro drive feels faster. I still though copy
lisp file I wish to modify elsewhere, and if wish changes to persist I
copy entire function somewhere to my config and re-eval it after Emacs
starts. That way I don't have to switch branches when I wish to pull
latest and rebuild, or have two source trees etc. I don't know. Many
ways to play with a dear child.

>> > 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).
I agree, and I am aware of that; I use myself /usr/local/bin to place
few scripts where I pre-configure environments for few apps, Emacs
amongst them, where I add some special paths or envs which I don't use
system-wide. Isn't it also the same idea that "containers"
(docker/kubernettes) exploit so successfuly? But I think we are
regressing quite a bit now :).

> 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 :-)
I have learned is that what Eli says is usually the right thing to do,
and he got a migrain after this comming up, so I don't think I have so
much more to add here, since my expertise with native comp does not go
further from enabliing it in the configure script, unfortunately.

> 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