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

From: Max Nikulin <[email-masked]>
Date: Fri, 5 May 2023 18:20:09 +0700

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.