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

[Eli Zaretskii]

> Date: Fri, 5 May 2023 22:33:48 +0700
> Cc: monnier@iro.umontreal.ca, yantar92@posteo.net, bzg@gnu.org,
>  dmitry@gutov.dev, 62762@debbugs.gnu.org, acm@muc.de
> From: Max Nikulin <manikulin@gmail.com>
> 
> On 05/05/2023 18:33, Eli Zaretskii wrote:
> >> Date: Fri, 5 May 2023 18:20:09 +0700 From: Max Nikulin
> >> On 05/05/2023 17:38, Eli Zaretskii wrote:
> >>>>> This doesn't work in Emacs, in general, due to circular dependencies.
> 
> Eli, I am still unable to associate this with particular cases of elisp 
> code or with how it is split over several files. That is why I am again 
> asking for examples illustrating issues you have in mind.
> 
> >>> What do you mean by "unavoidable"?
> >>
> >> 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.
> > 
> > If it's this part, then I don't see how it can be relevant to our
> > case: our problem is to teach Make about these dependencies, not to
> > teach a Lisp compiler about them.
> 
> I can not figure out which kind of cyclic dependencies may cause 
> troubles with dependency generation, but I had a hope that it would be 
> possible to reorganize code to avoid such kind of dependencies.
> 
> > I don't have ready examples off the top of my head, sorry.  You have
> > the Emacs Lisp sources, so you have all the information, and can find
> > those circular dependencies yourself if you don't believe me and
> > Stefan.
> 
> It might be even better if you will provide a brief example unrelated to 
> real Emacs code. I have no idea which code I should search for.

You should look for all the ways we load one Lisp file from another:

  . require
  . eval-when-compile
  . eval-and-compile

etc.  When fileA.el does any of that to load fileB.el, and fileB.el
does something to load fileA.el (whether directly or indirectly, via
other files), you have a circular dependency.