|
From: | Max Nikulin |
Subject: | bug#62762: 'make' often errors with "Org version mismatch" after pulling a new version of the code |
Date: | Fri, 5 May 2023 18:20:09 +0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 |
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 NikulinThe 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.
[Prev in Thread] | Current Thread | [Next in Thread] |