emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: More reliable byte compilation, take 45


From: Eli Zaretskii
Subject: Re: More reliable byte compilation, take 45
Date: Tue, 05 Oct 2021 14:52:46 +0300

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: raman@google.com,  cpitclaudel@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 04 Oct 2021 16:13:33 -0400
> 
> >> Converting a `.elc` file to a `.eln` file can be done by a pure function
> >> with no need for any extra information.
> > I very much doubt that.
> 
> You might be right, there might be corner cases I'm not taking into
> account, but by and large it should be the case.  At least much more so
> than for `.el` files where it's clearly a real problem.
> 
> > I have no reason to believe that the problems we see with native
> > compilation are related to these aspects.
> 
> I'm not sure which problems you're referring to.

The Subject is "more reliable byte compilation", and we are talking
specifically about more reliable native compilation.  So the problems
I was referring to are problems with compilation reliability.

> > Do you have evidence of that?
> 
> IIRC, in Raman's case the evidence was that the `.eln` file was calling
> a macro as if it were a function, and that this didn't happen when using
> the `.elc` file.  These problems typically happen when a `.el` file is
> miscompiled because some other ELisp file was not loaded beforehand.

And that's all?  Then why not fix that problem right away, it sounds
like something that should be easy to fix.  (Though I'm not sure I
understand why "some other ELisp file was not loaded beforehand" -- is
that a case of a missing 'require' or 'eval-when-compile' or somesuch?)

> In any case, the problem with compiling from the `.el` file instead of
> from the `.elc` file is real and it's easy to trigger it on purpose.

Examples?  Are you saying that it's impossible to solve those
problems?

> There's a chance that it will simply encourage people to fix their ELisp
> files to better follow the (undocumented) conventions, so to some degree
> I agree that it might be preferable not to fix this issue.

Ah, so the problem is with buggy *.el files, and only with them?



reply via email to

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