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 #143 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 12:27:25 +0700

On 05/05/2023 11:18, Max Nikulin wrote:
> On 05/05/2023 04:53, Stefan Monnier wrote:
>> Also, the use of `load-prefer-newer` in lisp/Makefile eliminates most of
>> the brokenness we used to have in our incremental builds.
> 
> `load-prefer-newer' is a kludge as well. E.g. Python people migrated 
> from comparison of timestamps to inscribing of .py file hash into byte 
> compiled .pyc files. So if the hash in .pyc does not match .py content 
> then .pyc file is recompiled or just ignored.

I have realized that neither `load-prefer-newer' not checking hash of 
the source .el file can help per se when an .elc file becomes stale due 
to update of a macro in a require'd file.

The robust way is to define compilation order through dependencies, 
preferably autogenerated ones). An alternative is to hope that usually 
it does not hurt and you are ready to remove .elc files (e.g. by make 
bootstrap) when you faced an apparent error or just suspect mixed 
version compilation as the cause of noticed strange behavior (I named 
this broken incremental builds).

Previous Next

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