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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Max Nikulin <manikulin <at> gmail.com>
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: bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code
Date: Sun, 07 May 2023 17:57:37 -0400

>> AFAIU there are 2 main situations:
>> A) recompilation (i.e. `git pull; make`).
>>     This can happen either in Org's repository or in Emacs's repository.
> ...
> Are there brave enough developers and users who do not restart emacs after
>  rebuild of Emacs?

I recompile daily, and restart every other month or so?
FWIW, I never bumped into a problem with Org due to that (and never
used `org-reload` either).

>> B) mixed versions from different directories.
>> AFAICT `my-require-with-shadow-check` should be able to catch most/all
>> problems for (B),
>
> Agree.
>
>> without impacting (A), and more reliably than
>> `org-assert-version` (and in an arguably less ad-hoc way).
>
> Sorry, but `org-assert-version' should catch loading from the same directory
> a file compiled for new version since loaded earlier org-version.el defined
> old version that does not match `org-version' inscribed into new .elc
> files.  I assume either combination of "make clean" and "make" or proper
> incremental build.

I'd consider these scenarios to fall into (A) or thereabout.  And users
who do like I do (i.e. recompile Org while a session is using those Org
files) get what they deserve if they encounter a problem.

We have so many more real problems that I'm not interested in
considering such cases.  I can give you a life-long supply of further
hypothetical cases if you're so inclined :-)

> By the way, if just org-macs should be checked then would not be it more
> efficient in respect to load time to define a variable containing the
> directory and to check in other files if they are loaded from the same
> directory? With such approach there is no need in walking through the
> `load-history' list.

You might be right.  I was thinking in more general terms (e.g. I'm
thinking that maybe a test along the lines of the one performed by
`my-require-with-shadow-check` could be (optionally) included in
`require`).


        Stefan

Previous Next

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