Morgan Smith <[email protected]> writes: >>> But as far as I can tell, if we disable `org-babel-do-load-languages' >>> and `org-load-export-backends', then there is no circular dependencies >>> at all. >> >> That's not true. There is a huge number of cyclic dependencies. For >> example, org.el depends on org-element.el, which depends on org.el. >> >> (defun org-set-modules (var value) >> ... >> (require 'org-element) > > I've spent some time trying to graph the dependencies using graphviz. > See the attached graph.org for how to generate the graph and graph.svg > for the final graph. As you can see the only cyclic dependency I found > (indicated by a green node and red edge) was the one you pointed out. > > My graph only includes "requires". I suspect that the circular > dependencies you're talking about are the implied ones. Where a file > expects a certain function to already be defined but doesn't explicitly > load that file (and silences the compiler using a "declare-function" > call).
Yes, I am talking about the implied dependencies. If you ever try to remove all those declare-function lines and replace them with proper requires, you will see (there be dragons). > I could be wrong, but I don't think this type of circular dependency > actually effects compiling at all. I belive this is how I was how I was > able to compile org with Tup. It depends on how you compile. If you compile individual files in isolation, there is a risk of loading built-in Org libraries instead of the versions from the repo, AFAIR. And the worst thing is that it will still compile, and sometimes even without warnings. Into wrong, "mixed" .elc files, without various subtle errors we get reports about after every single major release. Admittedly, I ran into these issues too often. Enough to stop trying finding smart solutions of the problem and instead just go for getting rid of implied dependencies and cycles completely. > However, it's possible there was actually some contamination from the > emacs package that allowed it to compile. I think my next step is going > to be to define (using Guix of course) an Emacs package that contains no > org whatsoever so I can run my tests again. That's one way, yes. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
