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 #146 received at 62762 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Max Nikulin <manikulin <at> gmail.com>
Cc: yantar92 <at> posteo.net, 62762 <at> debbugs.gnu.org, bzg <at> gnu.org, dmitry <at> gutov.dev,
 monnier <at> iro.umontreal.ca, acm <at> muc.de
Subject: Re: bug#62762: 'make' often errors with "Org version mismatch" after
 pulling a new version of the code
Date: Fri, 05 May 2023 09:46:50 +0300

> Date: Fri, 5 May 2023 12:27:25 +0700
> From: Max Nikulin <manikulin <at> gmail.com>
> Cc: Ihor Radchenko <yantar92 <at> posteo.net>, Eli Zaretskii <eliz <at> gnu.org>,
>  bzg <at> gnu.org, dmitry <at> gutov.dev, 62762 <at> debbugs.gnu.org,
>  Alan Mackenzie <acm <at> muc.de>
> 
> 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.

Yes.

> The robust way is to define compilation order through dependencies, 
> preferably autogenerated ones).

This doesn't work in Emacs, in general, due to circular dependencies.

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

That's what we have been doing for ages, and it generally works well.

Previous Next

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