Getting started

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) for which you do not have the sources 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.

Step 1: Creating a configuration file

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>
where <config-file> is the name of the configuration file. If you omit the file name, a file named Doxyfile will be created. If a file with the name <config-file> already exists, doxygen will rename it to <config-file>.bak before generating the configuration template. If you use - as the file name then doxygen will try to read the configuration file from standard input (stdin).

The configuration file has a format that is similar to that of a (simple) Makefile. It contains of a number of assignments (tags) of the form:

TAGNAME = VALUE or
TAGNAME = VALUE1 VALUE2 ...

You can probably leave the values of most tags in a generated template configuration file 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 (for instance *.cpp *.h). 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. To further fine-tune the list of files that is parsed the EXCLUDE and EXCLUDE_PATTERNS tags can be used.

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. Please note that warnings of undocumented members will not be generated as long as EXTRACT_ALL is set to YES.

To analyse an existing piece of software it is useful to cross-reference a (documented) entity with its definition in the source files. Doxygen will generate such cross-references if you set the SOURCE_BROWSER tag to YES.

Step 2: Running doxygen

To generate the documentation you can now enter:

doxygen <config-file>

Doxygen will create a html, latex and/or man directory inside the output directory. As the names suggest the html directory contains the generated documentation in HTML format and the latex directory contains the generated documentation in format. Man pages are put in a man3 directory inside the man directory.

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, LATEX_OUTPUT, and MAN_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.61 to test the generated output).

The generated documentation must first be compiled by a compiler. (I use teTeX distribution version 0.9 that contains 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 (provided that you have a make tool called make ofcourse). This file can then be viewed using xdvi or converted into a postscript file refman.ps by typing make ps (this requires dvips ). Conversion to PDF is also possible; just type make pdf. The Postscript file can be send to a postscript printer. If you do not have a postscript printer, you can try to use ghostscript to convert postscript into something your printer understands. To get the best results for PDF output you should set the PDF_HYPERLINKS tag to YES.

The generated man pages can be viewed using the man program. You do need to make sure the man directory is in the man path (see the MANPATH environment variable). Note that there are some limitations to the capabilities of the man page format, so some information (like class diagrams, cross references and formulas) will be lost.

Step 3: Documenting the sources

Although documenting the source is presented as step 3, in a new project this should ofcourse be step 1. Here I assume you already have some code and you want doxygen to generate a nice document describing the API and maybe the internals as well.

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, classes and namespaces. So how do you document these? For members, classes and namespaces there are basicly two options:

  1. Place a special documentation block in front of the declaration or definition of the member, class or namespace. For file, class and namespace members it is also allowed to place the documention directly after the member. See section Special documentation blocks to learn more about special documentation blocks.
  2. Place a special documentation block somewhere else (another file or another location) and put a structural command in the documentation block. A structural command links a documentation block to a certain entity that can be documented (e.g. a member, class, namespace or file). See section Structural commands to learn more about structural commands.
Files can only be documented using the second option. The text inside a special documentation block is parsed before it is written to the HTML and/or output files.

During parsing the following steps take place:

Special documentation blocks

The following types of special documentation blocks are supported by doxygen:

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 { 
                 TVal1, /*!< Enum value TVal1. */  
                 TVal2, /*!< Enum value TVal2. */  
                 TVal3  /*!< Enum value TVal3. */  
               } 
         //! Enum pointer.
         /*! Details. */
         *enumPtr, 
         //! Enum variable.
         /*! Details. */
         enumVar;  
    
    //! 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);
};

Click here for the corresponding HTML documentation that is generated by doxygen.

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, namespace 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). By default the brief descriptions are also the first sentence of the detailed description (this can be changed by setting the REPEAT_BRIEF tag to NO). Both the brief and the detailed descriptions are optional for the Qt style.

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 { 
          TVal1, /**< enum value TVal1. */  
          TVal2, /**< enum value TVal2. */  
          TVal3  /**< enum value TVal3. */  
         } 
       *enumPtr, /**< enum pointer. Details. */
       enumVar;  /**< enum variable. Details. */
       
      /**
       * 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);
};

Click here for the corresponding HTML documentation that is generated by doxygen.

Note that the first sentence of the documentation (until the .) is treated as a brief description, whereas the documentation block as a whole forms the 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 members (including global functions) in front of the definition. This way the documentation can be placed in the source file instead of the header file. This keeps the header file 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 (assuming you use the Qt style comments).

Structural commands

So far we have assumed that the documentation blocks are always located in front of the declaration or definition of a file, class or namespace or in front of 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 that is read by doxygen:

/*! \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:

See section Special Commands for detailed information about these and other commands. Note that the documentation block belonging to a file should always contain a structural command.

To document a member of a C++ class, you must also document the class itself. The same holds for namespaces. To document a C function, typedef, enum or preprocessor definition 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 named structcmd.h 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);
Click here for the corresponding HTML documentation that is generated by doxygen.

Note:
Because each comment block in the example above contains a structural command, all the comment blocks could be moved to another location or input file (the source file for instance), without affecting the generated documentation. The disadvantage of this approach is that prototypes are duplicated, so all changes have to be made twice!

Documenting compound members.

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 sometimes desired to place the documentation block after the member instead of before. For this purpose doxygen has the following additional comment blocks:

/*!< ... */
This block can be used to put a qt style documentation blocks after a member. The one line version look as follows:
//!< ...
There are also JavaDoc versions:
/**< ... */
and
///< ... 
Note that these blocks have the same structure and meaning as the special comment blocks above only the < indicates that the member is located in front of the block instead of after the block.

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 */
};
Click here for the corresponding HTML documentation that is generated by doxygen.

Warning:
These blocks can only be used to document members. They cannot be used to document file classes, unions, structs and enums. Furthermore, the structural commands mentioned in the previous section are ignored inside these comment blocks.

Including formulas in the documentation

Doxygen allows you to put formulas in the output (this works only for the HTML and formats, not for the man page output). To be able to include formulas (as images) in the HTML documentation, you will also need to have the following tools installed

There are two ways to include formulas in the documentation.

  1. Using in-text formulas that appear in the running text. These formulas should be put between a pair of \f$ commands, so
      The distance between \f$(x_1,y_1)\f$ and \f$(x_2,y_2)\f$ is 
      \f$\sqrt{(x_2-x_1)^2+(y_2-y_1)^2}\f$.
    
    results in:

    The distance between and is .

  2. Unnumbered displayed formulas that are centered on a separate line. These formulas should be put between \f\[ and \f\] commands. An example:
      \f[
        |I_2|=\left| \int_{0}^T \psi(t) 
                 \left\{ 
                    u(a,t)-
                    \int_{\gamma(t)}^a 
                    \frac{d\theta}{k(\theta,t)}
                    \int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
                 \right\} dt
              \right|
      \f]
    
    results in:

Formulas should be valid commands in 's math-mode.

Warning:
Currently, doxygen is not very fault tolerant in recovering from typos in formulas. It may have to be necessary to remove the file formula.repository that is written in the html directory to a rid of an incorrect formula

Preprocessing

Source files that are used as input to doxygen can be parsed by doxygen's build-in C-preprocessor.

By default doxygen does only partial preprocessing. That is, it evaluates conditional compilation statements (like #if) and evaluates macro definitions, but it does not perform macro expansion.

So if you have the following code fragment

#define VERSION 200
#define CONST_STRING const char *

#if VERSION >= 200
  static CONST_STRING version = "2.xx";
#else
  static CONST_STRING version = "1.xx";
#endif

Then by default doxygen will feed the following to its parser:

#define VERSION
#define CONST_STRING

  static CONST_STRING version = "1.xx";

You can disable all preprocessing by setting ENABLE_PREPROCESSING to NO in the configuation file. In the case above doxygen will then read both statements!

In case you want to expand the CONST_STRING macro, you should set the MACRO_EXPANSION tag in the config file to YES. Then the result after preprocessing becomes:

#define VERSION
#define CONST_STRING

  static const char * version = "1.xx";

Note that doxygen will now expand all macro definitions (recursively if needed). This is often too much. Therefore, doxygen also allows you to expand only those defines that you explicitly specify. For this you have to set the EXPAND_ONLY_PREDEF tag to YES and specify the macro definitions after the PREDEFINED tag.

As an example, suppose you have the following obfusciated code fragment of an abstract base class called IUnknown:

/*! A reference to an IID */
#ifdef __cplusplus
#define REFIID const IID &
#else
#define REFIID const IID *
#endif

/*! The IUnknown interface */
DECLARE_INTERFACE(IUnknown)
{
  STDMETHOD(HRESULT,QueryInterface) (THIS_ REFIID iid, void **ppv) PURE;
  STDMETHOD(ULONG,AddRef) (THIS) PURE;
  STDMETHOD(ULONG,Release) (THIS) PURE;
};

without macro expansion doxygen will get confused, but we may not want to expand the REFIID macro, because it is documented and the user that reads the documentation should use it when implementing the interface.

By setting the following in the config file:

ENABLE_PREPROCESSING = YES
MACRO_EXPANSION      = YES
EXPAND_ONLY_PREDEF   = YES
PREDEFINED           = "DECLARE_INTERFACE(name)=class name" \
                       "STDMETHOD(result,name)=virtual result name" \
                       "PURE= = 0" \
                       THIS_= \
                       THIS= \
                       __cplusplus

we can make sure that the proper result is fed to doxygen's parser:

/*! A reference to an IID */
#define REFIID

/*! The IUnknown interface */
class  IUnknown
{
  virtual  HRESULT   QueryInterface ( REFIID iid, void **ppv) = 0;
  virtual  ULONG   AddRef () = 0;
  virtual  ULONG   Release () = 0;
};

Note that the PREDEFINED tag accepts function like macro definitions (like DECLARE_INTERFACE), normal macro substitutions (like PURE and THIS) and plain defines (like __cplusplus).

Note also that preprocessor definitions that are normally defined automatically by the preprocessor (like __cplusplus), have to be defined by hand with doxygen's parser (this is done because these defines are often platform/compiler specific).

In some cases you may want to substitute a macro name or function by something else without exposing the result to further macro substitution. You can do this but using the := operator instead of =

As an example suppose we have the following piece of code:

#define QList QListT
class QListT
{
};

Then the only way to get doxygen interpret this as a class definition for class QList is to define:

PREDEFINED = QListT:=QList

As you can see doxygen's preprocessor is quite powerful, but if you want even more flexibility you can always write an input filter and specify it on the INPUT_FILTER flag.

More information

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 faq and the troubleshooting sections.


Generated at Sun Nov 7 15:43:34 1999 by doxygen 0.49-991106 written by Dimitri van Heesch, © 1997-1999