The executable doxygen
is the main program that parses the sources and
generates the documentation. See section "Doxygen usage" for more
detailed usage information.
The executable doxytag
is only needed if you want to generate references
to external documentation (i.e. documentation that was generated by Doxygen)
or to create a search index for the search engine.
See section "Doxytag usage" for more detailed usage information.
The executable doxysearch
is only needed if you want to use the search
engine. See section "Doxysearch usage" for more detailed usage information.
Doxygen uses a configuration file to determine all of its settings. Each project should get its own configuration file. A project can consist of a single source file, but can also be an entire source tree that is recursively scanned.
To simplify the creation of a configuration file, Doxygen can create a
template configuration file for you. To do this call doxygen
with the -g
option:
doxygen -g <config-file>
Doxyfile
will be created.
The configuration file has a format that is similar to that of a Makefile. It contains of a number of assignments of the form:
TAGNAME = VALUE
or
TAGNAME = VALUE1 VALUE2 ...
You can probably leave the values of most tags to their default value.
The INPUT
tag is the only tag for which you are required to provide
a value. See section "Configuration" for more details about the configuration file.
For a small project consisting of a few C and/or C++ source and header files,
you can add the names of the files after the INPUT
tag.
If you have a larger project consisting of a source directory or tree
this may become tiresome. In this case you should put the root directory or
directories after the INPUT
tag, and add one or more file
patterns to the FILE_PATTERN
tag. Only files that match one of the
patterns will be parsed (if the patterns are omitted all files will be parsed).
For recursive parsing of a source tree you must set
the RECURSIVE
tag to YES.
If you start using Doxygen for an existing project (thus without any
documentation that Doxygen is aware of), you can still get an idea of
what the documented result would be. To do so, you must set the EXTRACT_ALL
tag in the configuration file to YES.
Then, Doxygen will pretend
everything in your sources is documented.
To generate the documentation you can now enter:
doxygen <config-file>
Doxygen will create a html
and a latex
directory inside the output
As the names suggest the html
directory contains the
generated documentation in HTML format and the latex
directory contains the
generated documentation in
LaTeX format.
The default output directory is the directory in which doxygen
is started. The directory to which the output is written can be changed
using the OUTPUT_DIRECTORY
, HTML_OUTPUT
and LATEX_OUTPUT
tags of
the configuration file. If the output directory does not
exist, doxygen
will try to create it for you.
The generated HTML documentation can be viewed by pointing a HTML browser
to the index.html
file in the html
directory. For the best results
a browser that supports cascading style sheets (CSS) should be used
(I'm currently using Netscape 4.0 to test the generated output).
The generated LaTeX
documentation must first be compiled by a LaTeX
compiler. (I use teTeX distribution version 0.4
that contains TeX
version 3.14159). To simplify the process of compiling the generated
documentation, doxygen
writes a Makefile
into the latex
directory.
By typing make
in the latex
directory the dvi file refman.dvi
will be generated. This file can then be viewed using xdvi
or
converted into postscript using dvips.
If the EXTRACT_ALL
option is set to NO
in the configuration file
(the default), then doxygen will only generate documentation for
documented members, files, and classes. So how do you document something?
For members and classes there are basicly two options:
During parsing the following steps take place:
*
)
then the whitespace and asterix are removed.
The following types of special documentation blocks are supported by Doxygen:
/*! ... text ... */
//! ... one line of text ...
/** ... text ... /
Here is an example of a documented piece of C++ code using the Qt style:
//! A test class. /*! A more elaborate class description. */ class Test { public: //! An enum. /* More detailed enum description. */ enum TEnum { /*! Enum value TVal1. */ TVal1, /*! Enum value TVal2. */ TVal2, /*! Enum value TVal3. */ TVal3 } //! Enum pointer. /*! Details. */ *p, //! Enum variable. /*! Details. */ a; //! A constructor. /*! A more elaborate description of the constructor. */ Test(); //! A destructor. /*! A more elaborate description of the destructor. */ ~Test(); //! A normal member taking two arguments and returning an integer value. /*! \param a an integer argument. \param s a constant chararcter pointer. \return The test results \sa Test(), ~Test(), testMeToo() and publicVar() */ int testMe(int a,const char *s); //! A pure virtual member. /*! \sa testMe() \param c1 the first argument. \param c2 the second argument. */ virtual void testMeToo(char c1,char c2) = 0; //! A public variable. /*! Details. */ int publicVar; //! A function variable. /*! Details. */ int (*handler)(int a,int b); };
The one-line comments should contain a brief description, whereas the multi-line comment blocks contain a more detailed description. The brief descriptions are included in the member overview of a class or file and are printed using a small italic font (this description can be omitted by setting BRIEF_MEMBER_DESC to NO in the config file). The brief descriptions also form the first sentence of the detailed description. Both the brief and the detailed descriptions are optional for the Qt style. If both are present, the brief description is placed before the detailed description.
Here is the same piece of code, this time documented using the JavaDoc style:
/** A test class. A more elaborate class description. */ class Test { public: /** * An enum. * More detailed enum description. */ enum TEnum { /** enum value TVal1. */ TVal1, /** enum value TVal2. */ TVal2, /** enum value TVal3. */ TVal3 } /** enum pointer. Details. */ *p, /** enum variable. Details. */ a; /** * A constructor. * A more elaborate description of the constructor. */ Test(); /** * A destructor. * A more elaborate description of the destructor. */ ~Test(); /** * a normal member taking two arguments and returning an integer value. * @param a an integer argument. * @param s a constant chararcter pointer. * @see Test() * @see ~Test() * @see testMeToo() * @see publicVar() * @return The test results */ int testMe(int a,const char *s); /** * A pure virtual member. * @see testMe() * @param c1 the first argument. * @param c2 the second argument. */ virtual void testMeToo(char c1,char c2) = 0; /** * a public variable. * Details. */ int publicVar; /** * a function variable. * Details. */ int (*handler)(int a,int b); };
Notice that the first sentence of the documentation (until the .
)
is treated as a brief description, whereas the documentation block as a whole
forms a detailed description. The brief description is required for the JavaDoc
style.
Unlike most other documentation systems, Doxygen also allows you to put the documentation of class members in front of the member definition. This way the documentation can be placed in the source code instead of the header files. This keeps the header files compact, and allows the implementer of the members more direct access to the documentation. As a compromise the brief description could be placed before the declaration and the detailed description before the member definition.
So far we have assumed that the documentation blocks are always located in front of the declaration or definition of a class or one of its members. Although this is often comfortable, it may sometimes be better to put the documentation somewhere else. For some types of documentation blocks (like file documentation) this is even required. Doxygen allows you to put your documentation blocks practically anywhere (the exception is inside the body of a function or inside a normal C style comment block), as long as you put a structural command inside the documentation block.
Structural commands (like all other commands) start with a backslash
(\
) followed by a command name and one or more parameters.
For instance, if you want to document the class Test
in the example
above, you could have also put the following documentation block somewhere
in the input:
/*! \class Test \brief A test class. A more detailed class description. */
Here the special command \class
is used to indicated that the
comment block contains documentation for the class Test.
Other structural commands are:
\struct
to document a C-struct.
\union
to document a union.
\enum
to document an enumeration type.
\fn
to document a function.
\var
to document a variable or typedef or enum value.
\def
to document a #define.
\file
to document a file.
To document a member of a C++ class, you must also document the class itself. To document a C function, typedef, enum or define you must first document the file that contains it (usually this will be a header file, because that file contains the information that is exported to other source files).
Here is an example of a C header that is documented using structural commands:
/*! \file structcmd.h \brief A Documented file. Details. */ /*! \def MAX(a,b) \brief A macro that returns the maximum of \a a and \a b. Details. */ /*! \var typedef unsigned int UINT32 \brief A type definition for a . Details. */ /*! \var int errno \brief Contains the last error code. \warning Not thread safe! */ /*! \fn int open(const char *pathname,int flags) \brief Opens a file descriptor. \param pathname The name of the descriptor. \param flags Opening flags. */ /*! \fn int close(int fd) \brief Closes the file descriptor \a fd. \param fd The descriptor to close. */ /*! \fn size_t write(int fd,const char *buf, size_t count) \brief Writes \a count bytes from \a buf to the filedescriptor \a fd. \param fd The descriptor to write to. \param buf The data buffer to write. \param count The number of bytes to write. */ /*! \fn int read(int fd,char *buf,size_t count) \brief Read bytes from a file descriptor. \param fd The descriptor to read from. \param buf The buffer to read into. \param count The number of bytes to read. */ #define MAX(a,b) (((a)>(b))?(a):(b)) typedef unsigned int UINT32; int errno; int open(const char *,int); int close(int); size_t write(int,const char *, size_t); int read(int,char *,size_t);
If you want to document the members of a file, struct, union, class, or enum and you want to put the documentation for these members inside the compound, it is often desired to place the documentation block after the member instead of before. For this purpose Doxygen has the following additional comment blocks:
/*!< ... */
//!< ... */
/**< ... */
Here is an example of a the use of these comment blocks:
/*! A test class */ class Test { public: /** An enum type. * The documentation block cannot be put after the enum! */ enum EnumType { int EVal1, /**< enum value 1 */ int EVal2 /**< enum value 2 */ }; void member(); //!< a member function. protected: int value; /*!< an integer value */ };
For a more elaborate example see the documentation of QdbtTabular . I hope that was clear. If not, please let me know, so I can improve this document. If you have problems take a look at the troubleshooting section.