Doxygen is a documentation system for C, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors), Fortran, VHDL, PHP and C#. Have a look at the doxygen output. It is easy to see which is the effect of the comments. Basically, C-style comments are used, e.g. It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in LATEX) from a set of documented source ﬁles. There is also support for generating output in RTF (MS-Word), PostScript, hyperlinked PDF, compressed HTML, and Unix man pages. Doxyfile is the name of your doxy-configuration file, doxylog.log is the output file to analyze warnings and errors, pdflatex.input is the helpful file with an answer to all questions. Doxygen (reads a conﬁguration ﬁle to control source code processing and documentation output formats, the default ﬁlename is Doxyfile. Doxygen Run with default conﬁg ﬁle. Doxygen Run with. Doxygen -g Generate.
doxygen is the main program that parses the sources and generates the documentation. See section Doxygen usage for more detailed usage information.
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. See section Doxytag usage for more detailed usage information.
Optionally, the executable
doxywizard can be used, which is a graphical front-end for editing the configuration file that is used by doxygen and for running doxygen in a graphical environment. For Mac OS X doxywizard will be started by clicking on the Doxygen application icon.
The following figure shows the relation between the tools and the flow of information between them (it looks complex but that's only because it tries to be complete):
Step 0: Check if doxygen supports your programming language
First, assure that your programming language has a reasonable chance of being recognized by Doxygen. These languages are supported by default: C, C++, C#, Objective-C, IDL, Java, VHDL, PHP, Python, Fortran, and D. It is possible to configure certain filetype extensions to use certain parsers: see the Configuration/ExtensionMappings for details. Also, completely different languages can be supported by using preprocessor programs: see the Helpers page for details.
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 from the command line with the
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), which can be useful for scripting.
The configuration file has a format that is similar to that of a (simple) Makefile. It consists 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. See section Configuration for more details about the configuration file.
If you do not wish to edit the config file with a text editor, you should have a look at doxywizard, which is a GUI front-end that can create, read and write doxygen configuration files, and allows setting configuration options by entering them via dialogs.
For a small project consisting of a few C and/or C++ source and header files, you can leave INPUT tag empty and doxygen will search for sources in the current directory.
If you have a larger project consisting of a source directory or tree you should assign the root directory or directories to 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 a list of source extensions is used). 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. To omit all
test directories from a source tree for instance, one could use:
Doxygen looks at the file's extension to determine how to parse a file. If a file has an
.odl extension it is treated as an IDL file. If it has a
.java extension it is treated as a file written in Java. Files ending with
.cs are treated as C# files and the
.py extension selects the Python parser. Finally, files with the extensions
.phtml are treated as PHP sources. Any other extension is parsed as if it is a C/C++ file, where files that end with
.m are treated as Objective-C source files.
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 structure is and how the documented result would look like. 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 as a consequence warnings about undocumented members will not be generated as long as EXTRACT_ALL is set to
To analyze 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 handy for code reviews for instance).
Step 2: Running doxygen
To generate the documentation you can now enter:
Depending on your settings doxygen will create
man directories inside the output directory. As the names suggest these directories contain the generated documentation in HTML, RTF, , XML and Unix-Man page format.
Doxygen Output To Pdf
The default output directory is the directory in which
doxygen is started. The root directory to which the output is written can be changed using the OUTPUT_DIRECTORY. The format specific directory within the output directory can be selected using the HTML_OUTPUT, RTF_OUTPUT, LATEX_OUTPUT, XML_OUTPUT, and MAN_OUTPUT tags of the configuration file. If the output directory does not exist,
doxygen will try to create it for you (but it will not try to create a whole path recursively, like
mkdir -p does).
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 using Mozilla, Safari, Konqueror, and sometimes IE6 to test the generated output).
The generated documentation must first be compiled by a compiler (I use a recent teTeX distribution for Linux and MacOSX and MikTex for Windows). To simplify the process of compiling the generated documentation,
doxygen writes a
Makefile into the
The contents and targets in the
Makefile depend on the setting of USE_PDFLATEX. If it is disabled (set to
NO), then typing
make in the
latex directory a dvi file called
refman.dvi will be generated. This file can then be viewed using
xdvi or converted into a PostScript file
refman.ps by typing
make ps (this requires
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
To get the best results for PDF output you should set the PDF_HYPERLINKS and USE_PDFLATEX tags to
YES. In this case the
Makefile will only contain a target to build
Doxygen combines the RTF output to a single file called refman.rtf. This file is optimized for importing into the Microsoft Word. Certain information is encoded using so called fields. To show the actual value you need to select all (Edit - select all) and then toggle fields (right click and select the option from the drop down menu).
The XML output consists of a structured 'dump' of the information gathered by doxygen. Each compound (class/namespace/file/..) has its own XML file and there is also an index file called index.xml.
A file called combine.xslt XSLT script is also generated and can be used to combine all XML files into a single file.
Doxygen also generates two XML schema files index.xsd (for the index file) and compound.xsd (for the compound files). This schema file describes the possible elements, their attributes and how they are structured, i.e. it the describes the grammar of the XML files and can be used for validation or to steer XSLT scripts.
In the addon/doxmlparser directory you can find a parser library for reading the XML output produced by doxygen in an incremental way (see addon/doxmlparser/include/doxmlintf.h for the interface of the library)
Man page output
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 sources 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:
- 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 documentation directly after the member. See section Special documentation blocks to learn more about special documentation blocks.
- 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 Documentation at other places to learn more about structural commands.
Files can only be documented using the second option, since there is no way to put a documentation block before a file. Of course, file members (functions, variables, typedefs, defines) do not need an explicit structural command; just putting a special documentation block in front or behind them will do.
Forgot password. 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:
- The special commands inside the documentation are executed. See section Special Commands for an overview of all commands.
- If a line starts with some whitespace followed by one or more asterisks (
*) and then optionally more whitespace, then all whitespace and asterisks are removed.
- 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.
- Links are created for words corresponding to documented classes (unless the word is preceded by a %; then the word will not be linked and the % sign is removed).
- Links to members are created when certain patterns are found in the text. See section Automatic link generation for more information on how the automatic link generation works.
- HTML tags that are in the documentation are interpreted and converted to equivalents for the output. See section HTML Commands for an overview of all supported HTML tags.
Since version 1.2.18, Doxygen can generate a new output format we have called the 'Perl Module output format'. It has been designed as an intermediate format that can be used to generate new and customized output without having to modify the Doxygen source. Therefore, its purpose is similar to the XML output format that can be also generated by Doxygen. The XML output format is more standard, but the Perl Module output format is possibly simpler and easier to use.
The Perl Module output format is still experimental at the moment and could be changed in incompatible ways in future versions, although this should not be very probable. It is also lacking some features of other Doxygen backends. However, it can be already used to generate useful output, as shown by the Perl Module-based LaTeX generator.
Please report any bugs or problems you find in the Perl Module backend or the Perl Module-based LaTeX generator to the doxygen-develop mailing list. Suggestions are welcome as well.
Using the Perl Module output format.When the GENERATE_PERLMOD tag is enabled in the Doxyfile, running Doxygen generates a number of files in the perlmod/ subdirectory of your output directory. These files are the following:
- DoxyDocs.pm. This is the Perl module that actually contains the documentation, in the Perl Module format described below.
- DoxyModel.pm. This Perl module describes the structure of DoxyDocs.pm, independently of the actual documentation. See below for details.
- doxyrules.make. This file contains the make rules to build and clean the files that are generated from the Doxyfile. Also contains the paths to those files and other relevant information. This file is intended to be included by your own Makefile.
- Makefile. This is a simple Makefile including doxyrules.make.
To make use of the documentation stored in DoxyDocs.pm you can use one of the default Perl Module-based generators provided by Doxygen (at the moment this includes the Perl Module-based LaTeX generator, see below) or write your own customized generator. This should not be too hard if you have some knowledge of Perl and it's the main purpose of including the Perl Module backend in Doxygen. See below for details on how to do this.
Using the Perl Module-based LaTeX generator.The Perl Module-based LaTeX generator is pretty experimental and incomplete at the moment, but you could find it useful nevertheless. It can generate documentation for functions, typedefs and variables within files and classes and can be customized quite a lot by redefining TeX macros. However, there is still no documentation on how to do this.
Setting the PERLMOD_LATEX tag to YES in the Doxyfile enables the creation of some additional files in the perlmod/ subdirectory of your output directory. These files contain the Perl scripts and LaTeX code necessary to generate PDF and DVI output from the Perl Module output, using PDFLaTeX and LaTeX respectively. Rules to automate the use of these files are also added to doxyrules.make and the Makefile.
The additional generated files are the following:
- doxylatex.pl. This Perl script uses DoxyDocs.pm and DoxyModel.pm to generate doxydocs.tex, a TeX file containing the documentation in a format that can be accessed by LaTeX code. This file is not directly LaTeXable.
- doxyformat.tex. This file contains the LaTeX code that transforms the documentation from doxydocs.tex into LaTeX text suitable to be LaTeX'ed and presented to the user.
- doxylatex-template.pl. This Perl script uses DoxyModel.pm to generate doxytemplate.tex, a TeX file defining default values for some macros. doxytemplate.tex is included by doxyformat.tex to avoid the need of explicitly defining some macros.
- doxylatex.tex. This is a very simple LaTeX document that loads some packages and includes doxyformat.tex and doxydocs.tex. This document is LaTeX'ed to produce the PDF and DVI documentation by the rules added to doxyrules.make.
Simple creation of PDF and DVI output using the Perl Module-based LaTeX generator.To try this you need to have installed LaTeX, PDFLaTeX and the packages used by doxylatex.tex.
- Update your Doxyfile to the latest version using:
- Set both GENERATE_PERLMOD and PERLMOD_LATEX tags to YES in your Doxyfile.
- Run Doxygen on your Doxyfile:
- A perlmod/ subdirectory should have appeared in your output directory. Enter the perlmod/ subdirectory and run:
This should generate a doxylatex.pdf with the documentation in PDF format.
This should generate a doxylatex.dvi with the documentation in DVI format.
Perl Module documentation format.The Perl Module documentation generated by Doxygen is stored in DoxyDocs.pm. This is a very simple Perl module that contains only two statements: an assigment to the variable $doxydocs and the customary 1; statement which usually ends Perl modules. The documentation is stored in the variable $doxydocs, which can then be accessed by a Perl script using DoxyDocs.pm
Doxygen Latex Pdf Output.
$doxydocs contains a tree-like structure composed of three types of nodes: strings, hashes and lists.
Doxygen To Pdf
- Strings. These are normal Perl strings. They can be of any length can contain any character. Their semantics depends on their location within the tree. This type of node has no children.
- Hashes. These are references to anonymous Perl hashes. A hash can have multiple fields, each with a different key. The value of a hash field can be a string, a hash or a list, and its semantics depends on the key of the hash field and the location of the hash within the tree. The values of the hash fields are the children of the node.
- Lists. These are references to anonymous Perl lists. A list has an undefined number of elements, which are the children of the node. Each element has the same type (string, hash or list) and the same semantics, depending on the location of the list within the tree.
As you can see, the documentation contained in $doxydocs does not present any special impediment to be processed by a simple Perl script. To be able to generate meaningful output using the documentation contained in $doxydocs you'll probably need to know the semantics of the nodes of the documentation tree, which we present in this page.
Data structure describing the Perl Module documentation tree.You might be interested in processing the documentation contained in DoxyDocs.pm without needing to take into account the semantics of each node of the documentation tree. For this purpose, Doxygen generates a DoxyModel.pm file which contains a data structure describing the type and children of each node in the documentation tree.
The rest of this section is to be written yet, but in the meantime you can look at the Perl scripts generated by Doxygen (such as doxylatex.pl or doxytemplate-latex.pl) to get an idea on how to use DoxyModel.pm.Generated on Thu Feb 5 16:59:09 2004 for Doxygen manual by1.3.5