Re: Merging native-comp and pgtk

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> There are some important differences between compiling to byte-code and
> compiling to native-code:
>
> - Compiling to byte-code is not transparent.  The resulting code may
>   behave differently in the two cases, there are questions like
>   `load-prefer-newer`, the compilation itself is useful to get feedback
>   via warnings (or even failures), the compilation can also have all
>   kinds of side-effects (like an `eval-when-compile` which triggers
>   compilation of something else...), the `load-history` will tell you
>   which of .el or .elc you loaded, ...

.eln isn't fully transparent either -- you get different backtraces etc
from compiled code than byte-compiled code, for instance.

> - Compilation of byte-code is fast.

That's the main point for not switching it on, I guess.

> - Byte-code enjoys backward compatibility.

Very limited backwards compatibility -- we've introduced new byte codes
in Emacs 28, for instance.  It's not a goal, but when it happens it's
nice.

Byte-code enjoys sideways compatibility, though -- one can use the same
.elc files on both ARM and AMD systems, but that's definitely not true
for .eln files.  But...  I'm not sure that's much of a consideration
either -- the rest of Emacs has to be built for a specific architecture,
so...

> None of those apply to native-code compilation.  On an under-powered
> machine like a BananaPi byte-code compilation of the whole of Emacs
> takes quite a while (order of magnitude around 1h).  It's a pain but
> it's bearable.  For native-code compilation the order of magnitude is
> a whole day, which I don't find bearable, especially since all those
> .eln files need to be rebuilt as soon as I have recompiled a new
> `temacs`!

Oh, they have to be?  I didn't know that.  Why?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no