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

[Stefan Monnier]

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

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

>> Anyway, any other words of wisdom?  Like which org/*.el files actually
>> need to be recompiled in this case?  Or are you saying all of them
>> need to be recompiled?

[ BTW, `rm lisp/org/*.elc` is a better solution since it avoids changing
  timestamps on all those .el files.  ]

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

>> I also am not sure I understand the logic of this test: AFAIU it only
>> tests the version string, not the actual macros that might have been
>> changed.  Are you saying that Org bumps its version string each time
>> _any_ Org macro is modified?
>
> 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?
[ We may need to adjust the test to account for the `package.el`
  "solution" which will result in the above test detecting a mixed
  version situation even though it "should" work correctly.  ]


        Stefan