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.

Optionally, the executable doxywizard is a GUI front-end for editing the configuration files that are used by doxygen.

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 - (i.e. the minus sign) 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:


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_PATTERNS 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. It can also include the sources directly into the documentation by setting INLINE_SOURCES to YES (this can be handly for code reviews for instance).

Step 2: Running doxygen

To generate the documentation you can now enter:

doxygen <config-file>

Doxygen will create a html, rtf, latex and/or man directory inside the output directory. As the names suggest the html directory contain the generated documentation in HTML, RTF, and Unix-Man page 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, 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 of course). This file can then be viewed using xdvi or converted into a postscript file by typing make ps (this requires dvips). To put 2 pages on one physical page use make ps_2on1 instead. The resulting 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. Conversion to PDF is also possible if you have installed the ghostscript interpreter; just type make pdf (or make pdf_2on1). 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 of course 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 basically 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:

Go to the next section or return to the index.

Generated at Fri Mar 23 20:22:17 2001 by doxygen1.2.6-20010319 written by Dimitri van Heesch, © 1997-2001