About: Doxygen is a source code documentation generator tool for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP, C#, and to some extent D. Different output formats are supported.
Fossies Dox: doxygen-1.8.13.src.tar.gz ("inofficial" and yet experimental doxygen-generated source code documentation)
This page provides a high-level overview of the internals of doxygen, with links to the relevant parts of the code. This document is intended for developers who want to work on doxygen. Users of doxygen are referred to the User Manual.
The generic starting point of the application is of cource the main() function.
Configuration file data is stored in singleton class Config and can be accessed using wrapper macros Config_getString(), Config_getInt(), Config_getList(), Config_getEnum(), and Config_getBool() depending on the type of the option.
The format of the configuration file (options and types) is defined by the file
config.xml. As part of the build process, the python script
configgen.py will create a file configoptions.cpp from this, which serves as the input for the configuration file parser that is invoked using Config::parse(). The script
configgen.py will also create the documentation for the configuration items, creating the file
After the configuration is known, the input files are searched using searchInputFiles() and any tag files are read using readTagFile()
The function parseFiles() takes care of parsing all files. It uses the ParserManager singleton factory to create a suitable parser object for each file. Each parser implements the abstract interface ParserInterface.
A second step is to convert multiline C++-style comments into C style comments for easier processing later on. As side effect of this step also aliases (ALIASES option) are resolved. The function that performs these 2 tasks is called convertCppComments().
Note: Alias resolution should better be done in a separate step as it is now coupled to C/C++ code and does not work automatically for other languages!
When a parser finds a special comment block in the input, it will do a first pass parsing via parseCommentBlock(). During this pass the comment block is split into multiple parts if needed. Some data that is later needed is extracted like section labels, xref items, and formulas. Also Markdown markup is processed using processMarkdown() during this pass.
The Entry objects created and filled during parsing are stored on disk (to keep memory needs low). The name, parent/child relation, and location on disk of each Entry is stored as a tree of EntryNav nodes, which is kept in memory.
The resulting data structures are all children of the generic base class called Definition which holds all non-specific data for a symbol definition.
Definition is an abstract base class. Concrete subclasses are
For doxygen specific concepts the following subclasses are available
Finally the data for members of classes, namespaces, and files is stored in the subclass MemberDef.
Within doxygen there are a number of ways to obtain debug output. Besides the invasive method of putting print statements in the code there are a number of easy ways to get debug information.
flex / lexcommand. The result is that of each input line the (lex) rule(s) that are applied on it are shown.
Propertiesof this file
Write used lex rulesto
.lfile is newer than the corresponding
.cppfile or remove the corresponding
perlscript is given to toggle the possibility of having the rules debug information.
LEX="flex -d"with the
makecommand on the command line. In this case the
.lthat are converted to the corresponding
.cppfiles during this
makeget the rules debug information.
.lfiles that are rebuild to
.cppfiles so be sure that only the
.lfiles(s) of which you want to have the rules debug information is (are) newer than the corresponding
-doption with the following possibilities (each option has to be preceded by
#definestatements etc., definitions in the doxygen configuration file like:
MULTILINE_CPP_IS_BRIEFis set to
\cond ... \endcondblocks)
lexfiles used. When a lexer is started and when a lexer ends the name of the
lexfile is given so it is possible to see in which lexer the problem occurs. This makes it easier to select the file to be compiled in