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

[Max Nikulin]

On 05/05/2023 17:38, Eli Zaretskii wrote:
> > Date: Fri, 5 May 2023 14:27:29 +0700 From: Max Nikulin
> >
> > On 05/05/2023 13:46, Eli Zaretskii wrote:
> > > Date: Fri, 5 May 2023 12:27:25 +0700 From: Max Nikulin
> > > > The robust way is to define compilation order through dependencies,
> > > > preferably autogenerated ones).
> >
> > > This doesn't work in Emacs, in general, due to circular dependencies.
> >
> > Could you, please, provide an example where circular dependencies are
> > unavoidable or cost of disentangling of mutual dependencies is prohibitive?
>
> What do you mean by "unavoidable"?

Ones that do not allow to apply approaches like:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62762#140
Max Nikulin Fri, 5 May 2023 11:18:17 +0700
> In the C and C++ world the solution for cyclic dependencies is forward 
> declarations. Some kind of such approach I see in Org as well. 
> lisp/org/ol.el and lisp/org/org-element.el are mutually dependent. 
> org-element.el requires 'ol, while the latter just declares functions 
> from 'org-element.

On 05/05/2023 17:38, Eli Zaretskii wrote:
> > My general impression that behavior of code having circular dependencies
> > is harder to comprehend.
>
> AFAIR, the problem is that we use 'require', eval-when-compile etc. to
> get definitions of macros, functions, and variables.  There's nothing
> difficult to comprehend in this.

I still have no idea which way it may be related to determining of order 
of compilation based on dependency tree. That is why I asked for 
particular examples.