bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code

[Ihor Radchenko <yantar92@posteo.net>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I don't.  Say, why not to store hash of the macro sources in the byte
>> code and verifying the hash when re-compilation is requested?  Though I
>> am not that much familiar with Emacs source compilation.
>
> In theory it's possible.  Nobody has worked on it :-)
> Note that it's not just macros but defsubsts as well.

... and other define-inlines.

>> Sure, in the context of Emacs compilation. The code in question is
>> mostly aiming at newer Org installed on top of built-in Org. We are
>> consistently getting issues related to incorrect macro expansion and
>> mixing different Org versions.
>
> Someone™ *really* needs to sit down and fix the underlying problem in
> `package.el`.  The current "solution" in `package.el` *should* work (it
> should reload the new `org-macs.el` on top of the old one, which
> I think should avoid all the problems seen in practice for Org), so it
> seems we just have a plain bug in the implementation of our "solution".
> [ Which is good: it should be simple to fix, compared to trying to come
>   up with another solution.  ]

AFAIK, the current re-loading approach in package.el does help.
But not all the Org users are using that new Emacs versions.
And not all the Org users are using package.el.

>> What we might do to work around the problem is detecting Emacs compilation
>> and disable the check.  Is there a way to detect that Emacs source is
>> being compiled from Elisp?
>
> This sounds like adding more brittle hacks on top of brittle hacks.

Sure. But I really have no better ideas, especially considering backward
compatibility requirements down to Emacs 26.

>> No. We originally tested by commit hash. Version string check is a
>> trade-off between the problem with ELPA builds (see the links in my
>> previous message) and the need to detect mixed installation problems.
>
> BTW, have you tried to use a test along the lines of: look through
> `load-history` to see if we loaded org-* files from a different directory
> than the one in which `load-file-name` resides?

Yup. Several problems here:
1. Not all the org-* files are a part of Org.
2. This will completely block the possibility for users to provide custom
   versions of Org libraries, when they need to.
3. We actually have `org-version' that is using this approach to
   indicate problems without blocking staff, but it still misses many
   cases.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>