GNOME Bugzilla – Bug 765369
Collaboration diagram generation requires EXTRACT_PRIVATE = YES
Last modified: 2018-07-30 10:43:35 UTC
Correct collaboration diagrams are only generated when EXTRACT_PRIVATE is also enabled. That is, if I set EXTRACT_ALL = NO EXTRACT_PRIVATE = NO EXTRACT_PACKAGE = YES EXTRACT_STATIC = YES EXTRACT_LOCAL_CLASSES = YES EXTRACT_LOCAL_METHODS = YES EXTRACT_ANON_NSPACES = NO HIDE_UNDOC_MEMBERS = NO HIDE_UNDOC_CLASSES = NO I get only a single class for the collaboration diagram. If I set EXTRACT_PRIVATE = YES, then the collaboration diagram magically appear!
Can you please attach a self-contained example (source+config file in a tar or zip) that allows us to reproduce the problem?
Created attachment 326551 [details] Example of when EXTRACT_PRIVATE affects collaboration diagram Toggling of EXTRACT_PRIVATE from NO to YES affects the collaboration diagrams. When set to NO it is not seen that Bar is used, when set to YES it is seen. There is a Use Case when you do not want to extract documentation for private members, but still see in the collaboration diagram classes that are stored in private attributes.
Thanks for the case and the explanation. I think it is a bit strange to expose the privately inherited class, there might be use cases that this is required but which relation (in case of EXTRACT_PRIVATE = YES : _aBarReference) is to be mentioned? No relation means that we have a complete inheritance relation. At the moment I don't see a conceptual fix for this.
Created attachment 326658 [details] Added dependencies via methods I have now modified the file Foo.hpp; two public methods with the following signatures were added Bar getBar(); void setBar(Bar bar); This exposes (via a puplic interface) that the Foo class indeed collaborates with the Bar class. Still the collaboration diagram generated by Doxygen (when EXTRACT_PRIVATE=NO) only contains the Foo class... Why? Another example is that if you start with a UML model showing the relationship between classes, then you expose relations even though those relations are usually stored as private members. It is nothing weired in that. What is weired is that Doxygen requires us to document all private members (due to that we want all public and protected members to be documented) in order to have meaningful collaboration diagrams... Thus it is only those members that carries the dependencies to other classes that needs to be exposed, not those with containing internal data and internal states. But this is not possible to express using the current set of configuration options for Doxygen. :( What I am after is that the collaboration diagram generated by Doxygen should at least contain all classes that are exposed within the documented method signatures.
As discussed in https://github.com/doxygen/doxygen/pull/734 , Doxygen has moved its issue tracking to https://github.com/doxygen/doxygen/issues All Doxygen tickets in GNOME Bugzilla have been migrated to Github. You can subscribe and participate in the new ticket in Github. You can find the corresponding Github ticket by searching for its Bugzilla ID (number) in Github. Hence I am closing this GNOME Bugzilla ticket. Please use the corresponding ticket in Github instead. Thanks a lot!