\hypertarget{starting}{}\section{Getting started}\label{starting}
 The executable {\tt doxygen} is the main program that parses the sources and  generates the documentation. See section \hyperlink{doxygen_usage}{Doxygen usage} for more detailed usage information.

The executable {\tt 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 \hyperlink{doxytag_usage}{Doxytag usage} for more detailed usage  information.

The executable {\tt doxysearch} is only needed if you want to use the search  engine. See section \hyperlink{doxysearch_usage}{Doxysearch usage} for more detailed usage information.

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

\hypertarget{step1}{}\subsection{Step 1: Creating a configuration file}\label{step1}


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 {\tt doxygen} with the {\tt -g}  option:



\footnotesize\begin{verbatim}
doxygen -g <config-file>
\end{verbatim}\normalsize 
 where $<$config-file$>$ is the name of the configuration file. If you omit the file name, a file named {\tt 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 {\tt -} (i.e. the minus sign) as the file name then  doxygen will try to read the configuration file from standard  input ({\tt 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:

{\tt TAGNAME = VALUE} or \par
 {\tt TAGNAME = VALUE1 VALUE2 ... }\par


You can probably leave the values of most tags in a generated template  configuration file to their default value.

The \hyperlink{config_cfg_input}{INPUT} tag is the only tag for which you are required to  provide a value. See section \hyperlink{config}{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  \hyperlink{config_cfg_input}{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 \hyperlink{config_cfg_input}{INPUT} tag, and add one or more file  patterns to the \hyperlink{config_cfg_file_patterns}{FILE\_\-PATTERNS} tag  (for instance {\tt $\ast$.cpp $\ast$.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 \hyperlink{config_cfg_recursive}{RECURSIVE} tag to {\tt YES}. To further fine-tune the  list of files that is parsed the \hyperlink{config_cfg_exclude}{EXCLUDE} and  \hyperlink{config_cfg_exclude_patterns}{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 \hyperlink{config_cfg_extract_all}{EXTRACT\_\-ALL} tag in the configuration file  to {\tt 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 \hyperlink{config_cfg_extract_all}{EXTRACT\_\-ALL} is set to {\tt 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 \hyperlink{config_cfg_source_browser}{SOURCE\_\-BROWSER} tag to {\tt YES}.  It can also include the sources directly into the documentation by setting \hyperlink{config_cfg_inline_sources}{INLINE\_\-SOURCES} to {\tt YES} (this can be handly for  code reviews for instance).

\hypertarget{step2}{}\subsection{Step 2: Running doxygen}\label{step2}


To generate the documentation you can now enter: 

\footnotesize\begin{verbatim}
doxygen <config-file>
\end{verbatim}\normalsize 


Doxygen will create a {\tt html}, {\tt rtf}, {\tt latex} and/or {\tt man} directory inside  the output directory.  As the names suggest these directories contain the generated documentation in HTML, RTF, $\mbox{\LaTeX}$ and Unix-Man page format.

The default output directory is the directory in which {\tt doxygen} is started. The directory to which the output is written can be changed  using the \hyperlink{config_cfg_output_directory}{OUTPUT\_\-DIRECTORY},  \hyperlink{config_cfg_html_output}{HTML\_\-OUTPUT}, \hyperlink{config_cfg_rtf_output}{RTF\_\-OUTPUT}, \hyperlink{config_cfg_latex_output}{LATEX\_\-OUTPUT}, and \hyperlink{config_cfg_man_output}{MAN\_\-OUTPUT}  tags of the configuration file. If the output directory does not exist,  {\tt doxygen} will try to create it for you.

\index{browser@{browser}} The generated HTML documentation can be viewed by pointing a HTML browser to the {\tt index.html} file in the {\tt 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). \index{LaTeX@{LaTeX}}

The generated $\mbox{\LaTeX}$ documentation must first be compiled by  a $\mbox{\LaTeX}$ compiler (I use te\-Te\-X distribution version 0.9 that contains $\mbox{\TeX}$ version 3.14159). To simplify the process  of compiling the generated documentation, {\tt doxygen} writes a {\tt Makefile} into the {\tt latex} directory.  By typing {\tt make} in the {\tt latex} directory the dvi file {\tt refman.dvi} will be generated (provided that you have a make tool called  {\tt make} of course). This file can then be viewed using {\tt xdvi} or  converted into a Post\-Script file {\tt refman.ps} by  typing {\tt make ps} (this requires {\tt dvips}).  To put 2 pages on one physical page use {\tt make ps\_\-2on1} instead. The resulting Post\-Script file can be send to a Post\-Script printer. If you do not have a Post\-Script printer, you can try to use  ghostscript to convert Post\-Script into something your printer understands. Conversion to PDF is also possible if you have installed the ghostscript interpreter; just type {\tt make pdf} (or {\tt make pdf\_\-2on1}).  To get the best results for PDF output you should set  the \hyperlink{config_cfg_pdf_hyperlinks}{PDF\_\-HYPERLINKS} tag to {\tt YES}.

The generated man pages can be viewed using the {\tt man} program. You do need to make sure the man directory is in the man path (see the {\tt 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.

\hypertarget{step3}{}\subsection{Step 3: Documenting the sources}\label{step3}


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 \hyperlink{config_cfg_extract_all}{EXTRACT\_\-ALL} option is set to {\tt NO} in the  configuration file (the default), then doxygen will only generate  documentation for {\em documented} members, files, classes and namespaces. So  how do you document these? For members, classes and namespaces there are  basically two options: \begin{enumerate}
\item 
Place a {\em 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 \hyperlink{specialblock}{Special documentation blocks} to learn more about special  documentation blocks. \item 
Place a special documentation block somewhere else (another file or  another location) {\em and} put a {\em 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 \hyperlink{structuralcommands}{Structural commands} to learn more  about structural commands. \end{enumerate}
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 $\mbox{\LaTeX}$ output files.

\index{parsing@{parsing}} During parsing the following steps take place: \begin{CompactItemize}
\item 
 The special commands inside the documentation are executed. See section \hyperlink{commands}{Special Commands} for an overview of all commands. \item 
 If a line starts with some whitespace followed by one or more asterixes  ({\tt $\ast$}) and then optionally more whitespace,  then all whitespace and asterixes are removed. \item 
 All resulting blank lines are treated as a paragraph separators. This saves you from placing new-paragraph commands yourself  in order to make the generated documentation readable. \item 
 Links are created for words corresponding to documented classes.  \item 
 Links to members are created when certain patterns are found in the text. See section \hyperlink{autolink}{Automatic link generation} for more information on how the automatic link generation works. \item 
 HTML tags that are in the documentation are interpreted and converted  to $\mbox{\LaTeX}$ equivalents for the $\mbox{\LaTeX}$ output.  See section \hyperlink{htmlcmds}{HTML Commands} for an overview of all supported HTML tags. \end{CompactItemize}


