The doxygendiagram branch (albeit very outdated) attempts a more complicated solution for supporting dot graphs. It may actually be focused only on builtin graphs generated by doxygen whereas this PR additionally focuses on user-defined graphs via \dot * \dotfile cmds.

Found a bug in the NodeFinder when enabling dot graphs for the doc's "Test Suite"'s "diagrams" example (generated xml from examples/doxygen/diagrams.cfg). It wasn't recognizing the graphviz nodes, so I fixed it. Now the docs show this feature in use (as it was originally intended).

@2bndy5 This seems very nice, thanks a lot. Just to make sure (even though I believe it says so in description), this does also include the inheritance diagrams etc found in Doxygen's own HTML output right? That really is a long-standing wish so fantastic to see this implemented if the case.

Do you consider this ready for review/merging?

Just to make sure (even though I believe it says so in description), this does also include the inheritance diagrams etc found in Doxygen's own HTML output right?

Indeed, it does. This addition makes use of the dot executable though (as noted in the new docs' page dot_graphs.rst)

Do you consider this ready for review/merging?

Yes, please.

Its been so long since I opened this PR, that I figured I'd double check the proposed changes....

I think I messed up my fork's master branch by merging all changes from all my separate PRs (targeting upstream) into a branch on my fork that was supposed to be called "remix" (I think I mistakenly merged to my fork's master).

• The idea was to pip install my fork's remix branch until these changes were merged & released (because of limited attention/time allotted to this lib from maintainers).

With that said, I found and removed changes that were specific to #760 and #759 . If I have to keep rebasing this branch, then I'll have to do it manually because git seems to be confusing my fork's master with upstream master.

With all due respect, I want to mention that this lib's infrequent/sporadic dev activity is disheartening and tends to discourage contributions from those willing to do so. I mean no offense at all. It is amazing that the lib has gotten so old and popular considering the maintainers' limited time.

With all due respect, I want to mention that this lib's infrequent/sporadic dev activity is disheartening and tends to discourage contributions from those willing to do so. I mean no offense at all. It is amazing that the lib has gotten so old and popular considering the maintainers' limited time.

@2bndy5 Specifically for this, I do agree it's unfortunate. Especially because the bigger changes like this that really give a lot of value usually end up sitting in queue longer as a result. Normally things progress more quickly but the past year (or maybe two at this point) have just been tough for me personally resulting in too little time for Breathe.

I'll try my best to get some more time available for the pending PRs within a week and bump version again afterwards.

Rebasing this properly and handling and the merge commits and conflicts, removing the does+undoes, merging fixups was a ton of work, but it's finally done now and clean enough for merging.

@2bndy5 For a large part the convoluted history is a result of the delayed reviews, however for next time (at any project) I definitely recommend using git rebase -i upstream/master or similar to update a patchset with a force-push instead of separate fixup and merge branch commits. This is a lot easier to review per commit and also helps keep history clean and concise. (https://git-rebase.io/ may be useful in case you are not familiar.)

Thanks again for this great addition!

FYI #803