Doxygen Generated Code - High level structure

[John Ralls]

> On Sep 14, 2015, at 2:00 AM, Matt Graham <matt_graham2001 at hotmail.com> wrote:
> 
> You are 100% right, John – since we want multiple files in the one group we need to always use addtogroup and not defgroup.
>  
> But is the idea about module structure definition and standardisation worth considering? I.e. having a single file lay out the hierarchical structure of the modules (using addtogroup with the sub group inside @{ and @} ). That way you would just need to add the file with addtogroup and it would automatically be in the module hierarchy.
>  
> Am I just overthinking things? Am I best off focusing on updating the current structure? Or is this a good idea?

Matt,

I’d go with “overly optimistic”. The dependencies between modules isn’t really hierarchical except for QOF. There is an order of compilation but Scheme is used in some places in a way that allows dependencies on code that hasn’t yet been compiled. For example, src/engine/optiondb.c has dependencies on code in src/app-utils, but those dependencies are implemented in Scheme.

Another major barrier to effective use of Doxygen is that our objects are mostly implemented in GObject, which Doxygen doesn’t understand. It would make more sense to document with Gtk-doc except that we rarely use the GObject inheritance macros, hand-rolling inheritance with struct magic instead, and if there’s any use of virtualization I haven’t found it yet. We’re also inconsistent with function naming and Gtk-doc depends on a particular naming scheme to associate functions to classes. The good news is that we’re engaged in rewriting all of that into C++ which Doxygen does understand, so there’s hope for the future.

While I agree with your original statement, that a new contributor should be able to use the Doxygen docs to understand GnuCash’s structure, I don’t think that GnuCash has enough structure right now to enable that.

Regards,
John Ralls