Re: [External] : Re: Native compilation

[Emanuel Berg]

Eli Zaretskii wrote:

> It is both. I see little sense in compiling init files
> (except as a method of finding bugs in them, which means you
> compile them and then throw away the .elc files). I see even
> less sense in natively compiling them: you get all the
> "issues" caused by natively-compiled ELisp, without any
> benefits. So it's a net loss. It follows that our advice to
> users should be not to do something that results in net loss
> for them.

Well ... okay, a general approach of course, but nonetheless.

>> Or, if it indeed is a new attitude, what is the basis of
>> that attitude? 
>
> Natively-compiling Lisp files needs to make sure they are
> self-contained, i.e. they don't depend on other Lisp files
> that are not explicitly 'load'ed or 'require'd in them.
> Otherwise you will have warnings and errors during JIT
> native-compilation.

Yes, but that's completely natural ... good, even?

> Natively-compiling Lisp files also means you'll need to have
> the original Lisp files around, or else Emacs will refuse to
> load the .eln file. If you compress the source file, you
> need to have Emacs built with decompression support (zlib),
> otherwise Emacs will refuse to load the .eln file, claiming
> that the source isn't available.

Okay, why?

Anyway I always have the .elc next to the .el anyway ...

> Replacing the .eln file that is loaded into a running Emacs
> session is "tricky" at best, because the *.eln files are
> actually shared libraries in disguise, and your typical OS
> doesn't like it very much when you delete a shared library
> that's in use.

Well, we don't intend to do that a lot ... if we do that will
be interesting to know and we'll cross that bridge when/if we
reach it ...

>> OK, so that's the basis, but then I again ask, why are
>> there gains doing this to the GNU Emacs (vanilla Emacs)
>> Elisp, but not to the local (HOME) Elisp?
>
> Because most of the code in a typical init file doesn't
> perform any significant processing that can be sped up by
> natively-compiling it.

Yeah ... I have 144 Elisp files [1] so maybe it isn't
a typical setup. Anyway it isn't (for me) really about making
anything faster anyway, it is about natively byte-compiling
the Elisp ...

>> Right, it doesn't look like it, either. So how do you
>> natively byte-compile the file x.el?
>
> By using one or more of special commands designed for that.

Which are?

Or where is this documented perhaps better ...

>>>> That happens automatically when Emacs is run, after being
>>>> configured --with-native-compilation [1], and it only
>>>> affects GNU Emacs Elisp, right?
>>>
>>> What is "that" in this case?
>> 
>> Native byte-compilation of GNU Emacs (vanilla Emacs) Elisp.
>
> It happens automatically when Emacs loads a .elc file whose
> .el file can be found in the usual places, yes.

What places are these?

I have the .elc files and they are in the same directory as
the .el files - okay, so maybe they are indeed
natively byte-compiled already?

.eln files do exist in ~/.emacs.d/eln-cache/29.0.50-9e08bfb0
including my files, e.g. time-incal-760bfd05-7cbfad50.eln -
okay, so maybe that's why I got the warning/error for just one
file, .emacs - because .emacs is named .emacs and not
emacs.el?

Everything else taken cared of already?

[1] https://dataswamp.org/~incal/emacs-init/

-- 
underground experts united
https://dataswamp.org/~incal