[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [External] : Re: Native compilation
From: |
Emanuel Berg |
Subject: |
Re: [External] : Re: Native compilation |
Date: |
Wed, 12 Jan 2022 23:38:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
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
- Re: [External] : Re: Native compilation, Emanuel Berg, 2022/01/09
- Re: [External] : Re: Native compilation, Eli Zaretskii, 2022/01/09
- Re: [External] : Re: Native compilation, Emanuel Berg, 2022/01/10
- Re: [External] : Re: Native compilation, Eli Zaretskii, 2022/01/10
- Re: [External] : Re: Native compilation, Emanuel Berg, 2022/01/11
- Re: [External] : Re: Native compilation, Eli Zaretskii, 2022/01/11
- Re: [External] : Re: Native compilation,
Emanuel Berg <=
- Re: [External] : Re: Native compilation, Emanuel Berg, 2022/01/12
- Re: [External] : Re: Native compilation, Eli Zaretskii, 2022/01/13
- Re: [External] : Re: Native compilation, Emanuel Berg, 2022/01/13
- Re: [External] : Re: Native compilation, Emanuel Berg, 2022/01/13
- Re: [External] : Re: Native compilation, Eli Zaretskii, 2022/01/13
- Re: [External] : Re: Native compilation, Emanuel Berg, 2022/01/13