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

[Max Nikulin]

On 06/05/2023 01:17, Stefan Monnier wrote:
> I'll refrain from discussing this here.  Incremental recompilation
> problems should be discussed in another bug report, IMO.

I will try to explain why this bug report was caused by issues with 
incremental builds.

Original report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#5

> Could someone fix that, so that I don't have to 'make bootstrap' every 
> other time after a 'git pull'?
>
> make[3]: Entering directory '/home/dgutov/vc/emacs-master/lisp'
>   ELC      org/ox.elc
> Warning (emacs): Org version mismatch.  Org loading aborted.

It may be a *valid* error, however on minor Org updates it is likely a 
false positive.

ox.el has a number of `require's. Byte compilation loaded an .elc file 
before it was recompiled with new definition of a macro. Notice that an 
.elc file may become stale even if the corresponding .el file has not 
changed. The .el file may require macros from other .el (.elc) files and 
expand them during compiling.

So incremental build must compile files in certain order. It must take 
into account dependencies between .elc and .el files and prevent loading 
of stale .elc files.

`load-prefer-newer' can be a workaround only for direct "%.elc: %.el" 
dependencies. Transitional dependencies still may cause troubles.

Let's assume that a trouble with cyclic dependencies is a real one (I 
have not convinced in that). A way to the correct builds is to 
*completely* avoid loading of .elc files during incremental builds. When 
only a few files changed then relying purely on .el files should cause 
significant performance penalty. Unfortunately it would not work without 
describing at least some dependencies. In the `org-assert-version' they 
should be at least that all lisp/org/*.elc files depend on 
lisp/org/org-version.el and lisp/org/org-macs.el. Without automatic 
dependency generation it is a kludge, but it should significantly 
alleviate the issue. Grepping org sources for defmacro and adding e.g. 
org-element.el dependency will make incremental builds with stale macro 
definitions even more rare.

Commits pushed so far trade false positives to false negatives and to 
reports of bugs due to "undefined" functions and incorrect signatures to 
Org developers and maintainers.

Perhaps `org-assert-version' may be improved, but this report was caused 
by broken build rules.