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

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, bzg@gnu.org, 62762@debbugs.gnu.org
> Date: Tue, 11 Apr 2023 18:35:51 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The fact the Org error is triggered means that Emacs does not re-compile
> >> .el files that refer to macros that have been changed.
> >
> > You know this is not really possible in Emacs.
> 
> 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.

We need to do this the "make" way.  That is, we need to be able to
produce dependencies that Make can understand, e.g. similarly to how
the *.d files in src/.deps are produced by GCC.  This is in principle
possible, but we need changes in the byte compiler and in 'load', and
probably more.

> Note that the reported issue will only happen when Org version string
> changes between the builds.

Which happened twice during the last week or two, AFAIR.  Moreover, it
happens on almost every branch, and if someone builds several branches
routinely (I do), the annoyance happens several times in a row.

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

Not sure I understand: the byte compiler is a Lisp program, so every
compilation is "from Lisp", no?  Or what am I missing?

> > Also, how about the alternative of including the version string in
> > every Org Lisp file that needs to be recompiled when the version
> > changes (or the macros change)?  Then recompilation will happen
> > automatically, and this problem will go away.  Does this make sense?
> 
> No. We will not be able to maintain this manually.

I guess it means we are on our own, sigh...