GNU bug report logs - #62762
'make' often errors with "Org version mismatch" after pulling a new version of the code

Previous Next

Full log

Message #170 received at 62762 <at> debbugs.gnu.org (full text, mbox):

From: Max Nikulin <manikulin <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, 62762 <at> debbugs.gnu.org, bzg <at> gnu.org,
 dmitry <at> gutov.dev, Alan Mackenzie <acm <at> muc.de>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after
 pulling a new version of the code
Date: Fri, 5 May 2023 23:37:36 +0700

On 05/05/2023 21:29, Stefan Monnier wrote:
>> `load-prefer-newer' is a kludge as well.
> 
> I have to point out at this stage that I feel your answers aren't
> helping address the very concrete short term question at hand.

It was not me who bring `load-prefer-newer' to this discussion. My point 
is: if timestamps were helpful to solve the issue with using of stale 
.elc files during incremental built after update then check based on .el 
content hashsum would do it even better.

> E.g. the mixed-version problems that `org-assert-version` tries to
> detect can happen without any `.elc` file in sight at all.

Current variant `org-assert-version' can not work when Org update is 
loaded uncompiled, Certainly mixed version loading may happen purely 
with .el files. Mixed compilation issue (the topic of this bug) happens 
namely with .elc files.

>> By the way, `load-prefer-newer' make things even worse [...] (.el
>> files not changed, so they are older)
> 
> No, if ".el files not changed, so they are older", then
> `load-prefer-newer` has no effect at all, so it can't make things worse.

If *.el files had higher priority than newer *.elc files than compiling 
result would be correct. An .elc file may become stale not due to change 
of its .el source, but due to changes in required files. The price is 
slower incremental builds. Initial clean build may use .elc files. This 
is applicable to Emacs builds, things may be more complicated when users 
build Org updates.

> Yes, ELisp has lot of other problems.  But can we move those discussions
> to other bug reports, otherwise I'm afraid we'll never get anywhere.

I see 2 possible routes to avoid make + org-assert-version issues
- to make incremental builds really reliable, rather than just "it 
generally works well"
- improve `org-assert-version'

Unfortunately committed code made `org-assert-version' less efficient. 
The function you suggested may solve some issues, but I am unsure if it 
can replace current variant of `org-assert-version' completely.

I have no ideas how to make `org-assert-version' better.

I had a hope that dependency generation may solve compiling issue, but I 
can not figure out what sort of circular dependencies is troublesome. I 
just must believe you and Eli.

> [ I'm stopping here, I have to go.  ]

Certainly there is no hurry. For me priority is the following:

Example of circular dependencies that may cause trouble during 
determining of compiling order (names of files or complete example, I 
hope it should not be longer that a dozen of lines).

Whether I missed something and your function may handle loading files 
from updated directory.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.