help-gnu-emacs
[Top][All Lists]
Advanced

[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: Tue, 11 Jan 2022 14:18:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii wrote:

>>>>>> Here is what it said during the native compile:
>>>>>> 
>>>>>> Warning (comp): Cannot look-up eln file as no source file
>>>>>> was found for /home/incal/.emacs.elc
>>>>> 
>>>>> The former means your .emacs was not natively compiled
>>>>> (which is generally a Good Thing).
>>>> 
>>>> Thanks, you mean not to compile it natively or not compile
>>>> it at all?
>>>
>>> Natively.
>> 
>> Okay, it is interesting that you say so because didn't you
>> use (?) to say that byte-compiling of the .emacs and
>> supplemental files was disencouraged?
>
> I did, but how is that relevant to the issue at hand?

Because I would like to know if this new (?) attitude to a new
thing - is that actually a new attitude, or is it an old
attitude ("don't byte-compile your own Elisp") applied to
a new thing? (native byte-compilation)

Or, if it indeed is a new attitude, what is the basis of
that attitude? 

>> Why is it that while it makes sense to natively
>> byte-compile the Elisp of GNU Emacs it doesn't make sense
>> to natively byte-compile all other Elisp?
>
> Because the gains will be null and void.

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?

>> But OK, just byte-compiling the old what, that doesn't make
>> it natively byte-compiled, right?
>
> No.

Right, it doesn't look like it, either. So how do you natively
byte-compile the file x.el?

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

>> Or what about [M]ELPA Elisp, that natively byte-compiled
>> as well?
>
> What do you mean by "MELPA Elisp"?

The Elisp you get from ELPA and MELPA and possibly other
places with the package manager.

>> If so, even more so, then why not all Elisp?
>
> Why not what?

_If_ there is an advantage, and I agree it is, both in theory
and in practice, to natively byte-compile the GNU Emacs
(vanilla Emacs) Elisp, then how can it be that "the gains will
be null and void" to do the same with the local (HOME) Elisp?

And, as asked, the [M]ELPA Elisp?

Why/how can it makes sense to do this on some Elisp but not all?

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]