Doxygen Manual
Doxygen Manual
8
Written by Dimitri van Heesch
1997-2014
Contents
I User Manual 1
1 Introduction 3
2 Installation 7
2.1 Compiling from source on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Installing the binaries on UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Known compilation problems for UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Compiling from source on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Installing the binaries on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Tools used to develop doxygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Getting Started 13
3.1 Step 0: Check if doxygen supports your programming language . . . . . . . . . . . . . . . . . . . . 14
3.2 Step 1: Creating a conguration le . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Step 2: Running doxygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.1 HTML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 LaTeX output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.3 RTF output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.4 XML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.5 Man page output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.6 DocBook output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Step 3: Documenting the sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Documenting the code 19
4.1 Special comment blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 Comment blocks for C-like languages (C/C++/C#/Objective-C/PHP/Java) . . . . . . . . . . . 19
4.1.1.1 Putting documentation after members . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.1.3 Documentation at other places . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1.2 Comment blocks in Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.3 Comment blocks in VHDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
II CONTENTS
4.1.4 Comment blocks in Fortran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.5 Comment blocks in Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Anatomy of a comment block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5 Markdown 31
5.1 Standard Markdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1 Paragraphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.3 Block quotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.4 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.5 Code Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.6 Horizontal Rulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.7 Emphasis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.8 code spans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.9 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.9.1 Inline Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.9.2 Reference Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.10 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.11 Automatic Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Markdown Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.2 Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.3 Fenced Code Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.4 Header Id Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3 Doxygen specics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.1 Including Markdown les as pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.2 Treatment of HTML blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.3 Code Block Indentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.4 Emphasis limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.5 Code Spans Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.6 Lists Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.7 Use of asterisks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.8 Limits on markup scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.4 Debugging of problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6 Lists 41
7 Grouping 43
7.1 Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.2 Member Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.3 Subpaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Generated by Doxygen
CONTENTS III
8 Including Formulas 49
9 Graphs and diagrams 51
10 Preprocessing 55
11 Automatic link generation 59
11.1 Links to web pages and mail addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.2 Links to classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.3 Links to les . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.4 Links to functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
11.5 Links to other members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
11.6 typedefs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
12 Output Formats 63
13 Searching 65
13.1 External Indexing and Searching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13.1.2 Conguring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
13.1.2.1 Single project index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.1.2.2 Multi project index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
13.1.3 Updating the index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.1.4 Programming interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.1.4.1 Indexer input format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13.1.4.2 Search URL format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
13.1.4.3 Search results format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
14 Customizing the Output 73
14.1 Minor Tweaks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
14.1.1 Overall Color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
14.1.2 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
14.1.3 Dynamic Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
14.1.4 Header, Footer, and Stylesheet changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
14.2 Changing the layout of pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
14.3 Using the XML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
15 Custom Commands 79
15.1 Simple aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
15.2 Aliases with arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
15.3 Nesting custom command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
16 Link to external documentation 81
Generated by Doxygen
IV CONTENTS
17 Frequently Asked Questions 83
17.1 How to get information on the index page in HTML? . . . . . . . . . . . . . . . . . . . . . . . . . . 83
17.2 Help, some/all of the members of my class / le / namespace are not documented? . . . . . . . . . . 83
17.3 I set EXTRACT_ALL to NO none of my functions are shown in the documentation. . . . . . . . . . . 83
17.4 How can I make doxygen ignore some code fragment? . . . . . . . . . . . . . . . . . . . . . . . . . 84
17.5 How can I change what is after the <code>#include</code> in the class documentation? . . . . . . 84
17.6 How can I use tag les in combination with compressed HTML? . . . . . . . . . . . . . . . . . . . . 84
17.7 I dont like the quick index that is put above each HTML page, what do I do? . . . . . . . . . . . . . . 85
17.8 The overall HTML output looks different, while I only wanted to use my own html header le . . . . . 85
17.9 Why does doxygen use Qt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
17.10 How can I exclude all test directories from my directory tree? . . . . . . . . . . . . . . . . . . . . . . 85
17.11 Doxygen automatically generates a link to the class MyClass somewhere in the running text. How do I
prevent that at a certain place? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
17.12 My favorite programming language is X. Can I still use doxygen? . . . . . . . . . . . . . . . . . . . . 86
17.13 Help! I get the cryptic message "input buffer overow, cant enlarge buffer because scanner uses
REJECT" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
17.14 When running make in the latex dir I get "TeX capacity exceeded". Now what? . . . . . . . . . . . . 86
17.15 Why are dependencies via STL classes not shown in the dot graphs? . . . . . . . . . . . . . . . . . 86
17.16 I have problems getting the search engine to work with PHP5 and/or windows . . . . . . . . . . . . . 86
17.17 Can I congure doxygen from the command line? . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
17.18 How did doxygen get its name? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
17.19 What was the reason to develop doxygen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
18 Troubleshooting 89
18.1 Known Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
18.2 How to Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
18.3 How to report a bug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
II Reference Manual 91
19 Features 93
20 Doxygen usage 95
20.1 Fine-tuning the output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
21 Doxywizard usage 97
22 Conguration 103
22.1 Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
22.2 Project related conguration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
22.3 Build related conguration options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
22.4 Conguration options related to warning and progress messages . . . . . . . . . . . . . . . . . . . 113
Generated by Doxygen
CONTENTS V
22.5 Conguration options related to the input les . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
22.6 Conguration options related to source browsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
22.7 Conguration options related to the alphabetical class index . . . . . . . . . . . . . . . . . . . . . . 117
22.8 Conguration options related to the HTML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
22.9 Conguration options related to the LaTeX output . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
22.10 Conguration options related to the RTF output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
22.11 Conguration options related to the man page output . . . . . . . . . . . . . . . . . . . . . . . . . . 128
22.12 Conguration options related to the XML output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
22.13 Conguration options related to the DOCBOOK output . . . . . . . . . . . . . . . . . . . . . . . . . 128
22.14 Conguration options for the AutoGen Denitions output . . . . . . . . . . . . . . . . . . . . . . . . 129
22.15 Conguration options related to the Perl module output . . . . . . . . . . . . . . . . . . . . . . . . . 129
22.16 Conguration options related to the preprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
22.17 Conguration options related to external references . . . . . . . . . . . . . . . . . . . . . . . . . . 130
22.18 Conguration options related to the dot tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
22.19 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
23 Special Commands 137
23.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
23.2 \addtogroup <name> [(title)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
23.3 \callgraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
23.4 \callergraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
23.5 \category <name> [<header-le>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . 140
23.6 \class <name> [<header-le>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . . 140
23.7 \def <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
23.8 \defgroup <name> (group title) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
23.9 \dir [<path fragment>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
23.10 \enum <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
23.11 \example <le-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
23.12 \endinternal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
23.13 \extends <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
23.14 \le [<name>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
23.15 \fn (function declaration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
23.16 \headerle <header-le> [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
23.17 \hideinitializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
23.18 \idlexcept <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
23.19 \implements <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
23.20 \ingroup (<groupname> [<groupname> <groupname>]) . . . . . . . . . . . . . . . . . . . . . . 145
23.21 \interface <name> [<header-le>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . 145
23.22 \internal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
23.23 \mainpage [(title)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Generated by Doxygen
VI CONTENTS
23.24 \memberof <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
23.25 \name [(header)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
23.26 \namespace <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
23.27 \nosubgrouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
23.28 \overload [(function declaration)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
23.29 \package <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
23.30 \page <name> (title) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
23.31 \private . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
23.32 \privatesection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
23.33 \property (qualied property name) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
23.34 \protected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
23.35 \protectedsection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
23.36 \protocol <name> [<header-le>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . 149
23.37 \public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
23.38 \publicsection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
23.39 \pure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
23.40 \relates <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
23.41 \related <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
23.42 \relatesalso <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
23.43 \relatedalso <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
23.44 \showinitializer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
23.45 \static . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
23.46 \struct <name> [<header-le>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . . 151
23.47 \typedef (typedef declaration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
23.48 \union <name> [<header-le>] [<header-name>] . . . . . . . . . . . . . . . . . . . . . . . . . . 151
23.49 \var (variable declaration) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
23.50 \vhdlow [(title for the ow chart)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
23.51 \weakgroup <name> [(title)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
23.52 \attention { attention text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
23.53 \author { list of authors } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
23.54 \authors { list of authors } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
23.55 \brief { brief description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
23.56 \bug { bug description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
23.57 \cond [(section-label)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
23.58 \copyright { copyright description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
23.59 \date { date description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
23.60 \deprecated { description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
23.61 \details { detailed description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
23.62 \else . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
23.63 \elseif (section-label) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Generated by Doxygen
CONTENTS VII
23.64 \endcond . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
23.65 \endif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
23.66 \exception <exception-object> { exception description } . . . . . . . . . . . . . . . . . . . . . . . . 155
23.67 \if (section-label) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
23.68 \ifnot (section-label) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
23.69 \invariant { description of invariant } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
23.70 \note { text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
23.71 \par [(paragraph title)] { paragraph } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
23.72 \param [(dir)] <parameter-name> { parameter description } . . . . . . . . . . . . . . . . . . . . . . 157
23.73 \parblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
23.74 \endparblock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
23.75 \tparam <template-parameter-name> { description } . . . . . . . . . . . . . . . . . . . . . . . . . . 158
23.76 \post { description of the postcondition } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
23.77 \pre { description of the precondition } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
23.78 \remark { remark text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
23.79 \remarks { remark text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
23.80 \result { description of the result value } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
23.81 \return { description of the return value } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
23.82 \returns { description of the return value } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
23.83 \retval <return value> { description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
23.84 \sa { references } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
23.85 \see { references } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.86 \short { short description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.87 \since { text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.88 \test { paragraph describing a test case } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.89 \throw <exception-object> { exception description } . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.90 \throws <exception-object> { exception description } . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.91 \todo { paragraph describing what is to be done } . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.92 \version { version number } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
23.93 \warning { warning message } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
23.94 \xretem <key> "(heading)" "(list title)" { text } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
23.95 \addindex (text) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
23.96 \anchor <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
23.97 \cite <label> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
23.98 \endlink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
23.99 \link <link-object> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
23.100\ref <name> ["(text)"] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
23.101\retem <name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
23.102\secreist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
23.103\endsecreist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Generated by Doxygen
VIII CONTENTS
23.104\subpage <name> ["(text)"] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
23.105\tableofcontents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
23.106\section <section-name> (section title) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
23.107\subsection <subsection-name> (subsection title) . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
23.108\subsubsection <subsubsection-name> (subsubsection title) . . . . . . . . . . . . . . . . . . . . . 164
23.109\paragraph <paragraph-name> (paragraph title) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
23.110\dontinclude <le-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
23.111\include <le-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
23.112\includelineno <le-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
23.113\line ( pattern ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
23.114\skip ( pattern ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
23.115\skipline ( pattern ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
23.116\snippet <le-name> ( block_id ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
23.117\until ( pattern ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
23.118\verbinclude <le-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
23.119\htmlinclude <le-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
23.120\latexinclude <le-name> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
23.121\a <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
23.122\arg { item-description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
23.123\b <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
23.124\c <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
23.125\code [ {<word>}] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
23.126\copydoc <link-object> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
23.127\copybrief <link-object> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
23.128\copydetails <link-object> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
23.129\docbookonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
23.130\dot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
23.131\msc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
23.132\startuml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
23.133\dotle <le> ["caption"] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
23.134\mscle <le> ["caption"] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
23.135\diale <le> ["caption"] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
23.136\e <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
23.137\em <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
23.138\endcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
23.139\enddocbookonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
23.140\enddot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
23.141\endmsc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
23.142\enduml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
23.143\endhtmlonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Generated by Doxygen
CONTENTS IX
23.144\endlatexonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
23.145\endmanonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
23.146\endrtfonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
23.147\endverbatim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
23.148\endxmlonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
23.149\f$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
23.150\f[ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
23.151\f] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
23.152\f{environment}{ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
23.153\f} . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
23.154\htmlonly ["[block]"] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
23.155\image <format> <le> ["caption"] [<sizeindication>=<size>] . . . . . . . . . . . . . . . . . . . 177
23.156\latexonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
23.157\manonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
23.158\li { item-description } . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
23.159\n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
23.160\p <word> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
23.161\rtfonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
23.162\verbatim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
23.163\xmlonly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
23.164\\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
23.165\@ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
23.166\[LanguageId] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
23.167\& . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
23.168\$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
23.169\# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
23.170\< . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
23.171\> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
23.172\% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
23.173\" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
23.174\. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
23.175\:: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
23.176\[ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
23.177\-- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
23.178\--- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
24 HTML commands 183
25 XML commands 193
Generated by Doxygen
X CONTENTS
III Developers Manual 195
26 Doxygens internals 197
27 Perl Module Output format 201
27.1 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
27.2 Using the LaTeX generator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
27.2.1 Creation of PDF and DVI output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
27.3 Documentation format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
27.4 Data structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
28 Internationalization 205
Generated by Doxygen
Part I
User Manual
Chapter 1
Introduction
Introduction
Doxygen is the de facto standard tool for generating documentation fromannotated C++ sources, but it also supports
other popular programming languages such as C, Objective-C, C#, PHP, Java, Python, IDL (Corba, Microsoft, and
UNO/OpenOfce avors), Fortran, VHDL, Tcl, and to some extent D.
Doxygen can help you in three ways:
1. It can generate an on-line documentation browser (in HTML) and/or an off-line reference manual (in L
A
T
E
X)
from a set of documented source les. There is also support for generating output in RTF (MS-Word), Post
Script, hyperlinked PDF, compressed HTML, and Unix man pages. The documentation is extracted directly
from the sources, which makes it much easier to keep the documentation consistent with the source code.
2. You can congure doxygen to extract the code structure from undocumented source les. This is very useful
to quickly nd your way in large source distributions. Doxygen can also visualize the relations between the
various elements by means of include dependency graphs, inheritance diagrams, and collaboration diagrams,
which are all generated automatically.
3. You can also use doxygen for creating normal documentation (as I did for the doxygen user manual and
web-site).
Doxygen is developed under Mac OS X and Linux, but is set-up to be highly portable. As a result, it runs on most
other Unix avors as well. Furthermore, executables for Windows are available.
This manual is divided into three parts, each of which is divided into several sections.
The rst part forms a user manual:
Section Installation discusses how to download, compile and install doxygen for your platform.
Section Getting started tells you how to generate your rst piece of documentation quickly.
Section Documenting the code demonstrates the various ways that code can be documented.
Section Markdown support show the Markdown formatting supported by doxygen.
Section Lists shows how to create lists.
Section Grouping shows how to group things together.
Section Including formulas shows how to insert formulas in the documentation.
Section Graphs and diagrams describes the diagrams and graphs that doxygen can generate.
4 Introduction
Section Preprocessing explains how doxygen deals with macro denitions.
Section Automatic link generation shows how to put links to les, classes, and members in the documentation.
Section Output Formats shows how to generate the various output formats supported by doxygen.
Section Searching shows various ways to search in the HTML documentation.
Section External Indexing and Searching shows how use the external search and index tools
Section Customizing the output explains how you can customize the output generated by doxygen.
Section Custom Commands show how to dene and use custom commands in your comments.
Section Linking to external documentation explains how to let doxygen create links to externally generated
documentation.
Section Frequently Asked Questions gives answers to frequently asked questions.
Section Troubleshooting tells you what to do when you have problems.
The second part forms a reference manual:
Section Features presents an overview of what doxygen can do.
Section Doxygen usage shows how to use the doxygen program.
Section Doxywizard usage shows how to use the doxywizard program.
Section Conguration shows how to ne-tune doxygen, so it generates the documentation you want.
Section Special Commands shows an overview of the special commands that can be used within the docu-
mentation.
Section HTML Commands shows an overview of the HTML commands that can be used within the documen-
tation.
Section XML Commands shows an overview of the C# style XML commands that can be used within the
documentation.
The third part provides information for developers:
Section Doxygens Internals gives a global overview of how doxygen is internally structured.
Section Perl Module Output shows how to use the PerlMod output.
Section Internationalization explains how to add support for new output languages.
Doxygen license
Copyright 1997-2014 by Dimitri van Heesch.
Permission to use, copy, modify, and distribute this software and its documentation under the terms of the GNU
General Public License is hereby granted. No representations are made about the suitability of this software for any
purpose. It is provided "as is" without express or implied warranty. See the GNU General Public License
for more details.
Documents produced by doxygen are derivative works derived from the input used in their production; they are not
affected by this license.
Generated by Doxygen
5
User examples
Doxygen supports a number of output formats where HTML is the most popular one. Ive gathered some nice
examples of real-life projects using doxygen.
These are part of a larger list of projects that use doxygen. If you know other projects, let me know and
Ill add them.
Future work
Although doxygen is successfully used by large number of companies and open source projects already, there is
always room for improvement.
You can submit enhancement requests in the bug tracker. Make sure the severity of the bug report is set to
"enhancement".
Acknowledgments
Thanks go to:
Malte Zckler and Roland Wunderling, authors of DOC++. The rst version of doxygen borrowed some code
of an old version of DOC++. Although I have rewritten practically all code since then, DOC++ has still given
me a good start in writing doxygen.
All people at Qt Software, for creating a beautiful GUI Toolkit (which is very useful as a Windows/Unix platform
abstraction layer :-)
My brother Frank for rendering the logos.
Harm van der Heijden for adding HTML help support.
Wouter Slegers of Your Creative Solutions for registering the www.doxygen.org domain.
Parker Waechter for adding the RTF output generator.
Joerg Baumann, for adding conditional documentation blocks, PDF links, and the conguration generator.
Tim Mensch for adding the todo command.
Christian Hammond for redesigning the web-site.
Ken Wong for providing the HTML tree view code.
Talin for adding support for C# style comments with XML markup.
Petr Prikryl for coordinating the internationalization support. All language maintainers for providing transla-
tions into many languages.
The band Porcupine Tree for providing hours of great music to listen to while coding.
many, many others for suggestions, patches and bug reports.
Generated by Doxygen
6 Introduction
Generated by Doxygen
Chapter 2
Installation
First go to the download page to get the latest distribution, if you have not downloaded doxygen already.
2.1 Compiling from source on UNIX
If you downloaded the source distribution, you need at least the following to build the executable:
The GNU tools flex, bison, libiconv and GNU make, and strip
In order to generate a Makefile for your platform, you need perl
The congure script assume the availability of standard UNIX tools such as sed, date, find,
uname, mv, cp, cat, echo, tr, cd and rm.
To take full advantage of doxygens features the following additional tools should be installed.
Qt Softwares GUI toolkit Qt version 4.3 or higher (but currently, Qt 5.x is not supported). This is needed to
build the GUI front-end doxywizard.
A L
A
T
E
X distribution: for instance TeX Live This is needed for generating L
A
T
E
X, Postscript, and PDF output.
the Graph visualization toolkit version 1.8.10 or higher Needed for the include
dependency graphs, the graphical inheritance graphs, and the collaboration graphs. If you compile graphviz
yourself, make sure you do include freetype support (which requires the freetype library and header les),
otherwise the graphs will not render proper text labels.
For formulas or if you do not wish to use pdatex, the ghostscript interpreter is needed. You can nd it at
www.ghostscript.com.
In order to generate doxygens own documentation, Python is needed, you can nd it at www.python.org.
Compilation is now done by performing the following steps:
1. Unpack the archive, unless you already have done that:
gunzip doxygen-$VERSION.src.tar.gz # uncompress the archive
tar xf doxygen-$VERSION.src.tar # unpack it
2. Run the congure script:
sh ./configure
The script tries to determine the platform you use, the make tool (which must be GNU make) and the perl
interpreter. It will report what it nds.
To override the auto detected platform and compiler you can run congure as follows:
8 Installation
configure --platform platform-type
See the PLATFORMS le for a list of possible platform options.
If you have Qt-4.3 or higher installed and want to build the GUI front-end, you should run the congure script
with the --with-doxywizard option:
configure --with-doxywizard
For an overview of other conguration options use
configure --help
3. Compile the program by running make:
make
The program should compile without problems and the binaries (doxygen and optionally doxywizard)
should be available in the bin directory of the distribution.
4. Optional: Generate the user manual.
make docs
To let doxygen generate the HTML documentation.
The HTML directory of the distribution will now contain the html documentation (just point a HTML browser to
the le index.html in the html directory). You will need the python interpreter for this.
5. Optional: Generate a PDF version of the manual (you will need pdflatex, makeindex, and egrep for
this).
make pdf
The PDF manual doxygen_manual.pdf will be located in the latex directory of the distribution. Just view
and print it via the acrobat reader.
2.2 Installing the binaries on UNIX
After the compilation of the source code do a make install to install doxygen. If you downloaded the binary
distribution for UNIX, type:
./configure
make install
Binaries are installed into the directory <prefix>/bin. Use make install_docs to install the documen-
tation and examples into <docdir>/doxygen.
<prefix> defaults to /usr/local but can be changed with the --prefix option of the congure script.
The default <docdir> directory is <prefix>/share/doc/packages and can be changed with the
--docdir option of the congure script.
Alternatively, you can also copy the binaries from the bin directory manually to some bin directory in your search
path. This is sufcient to use doxygen.
Note
You need the GNU install tool for this to work (it is part of the coreutils package). Other install tools may put the
binaries in the wrong directory!
If you have a RPM or DEP package, then please follow the standard installation procedure that is required for these
packages.
Generated by Doxygen
2.3 Known compilation problems for UNIX 9
2.3 Known compilation problems for UNIX
Qt problems
The Qt include les and libraries are not a subdirectory of the directory pointed to by QTDIR on some systems (for
instance on Red Hat 6.0 includes are in /usr/include/qt and libs are in /usr/lib).
The solution: go to the root of the doxygen distribution and do:
mkdir qt
cd qt
ln -s your-qt-include-dir-here include
ln -s your-qt-lib-dir-here lib
ln -s your-qt-bin-dir-here bin
export QTDIR=$PWD
If you have a csh-like shell you should use setenv QTDIR $PWD instead of the export command above.
Now install doxygen as described above.
Bison problems
Versions 1.31 to 1.34 of bison contain a "bug" that results in a compiler errors like this:
ce_parse.cpp:348: member class CPPValue yyalloc::yyvs with constructor not al-
lowed in union
This problem has been solved in version 1.35 (versions before 1.31 will also work).
Sun compiler problems
It appears that doxygen doesnt work properly if it is compiled with Suns C++ WorkShop Compiler. I cannot verify
this myself as I do not have access to a Solaris machine with this compiler. With GNU compiler it does work and
installing Sun patch 111679-13 has also been reported as a way to x the problem.
when conguring with --static I got:
Undefined first referenced
symbol in file
dlclose /usr/lib/libc.a(nss_deffinder.o)
dlsym /usr/lib/libc.a(nss_deffinder.o)
dlopen /usr/lib/libc.a(nss_deffinder.o)
Manually adding -Bdynamic after the target rule in Makefile.doxygen will x this:
$(TARGET): $(OBJECTS) $(OBJMOC)
$(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJMOC) $(LIBS) -Bdynamic
GCC compiler problems
Older versions of the GNU compiler have problems with constant strings containing characters with character codes
larger than 127. Therefore the compiler will fail to compile some of the translator_xx.h les. A workaround,
if you are planning to use the English translation only, is to congure doxygen with the --english-only option.
On some platforms (such as OpenBSD) using some versions of gcc with -O2 can lead to eating all memory during
the compilation of les such as cong.cpp. As a workaround use --debug as a congure option or omit the -O2
for the particular les in the Makele.
Gcc versions before 2.95 may produce broken binaries due to bugs in these compilers.
Dot problems
Due to a change in the way image maps are generated, older versions of doxygen (<=1.2.17) will not work correctly
with newer versions of graphviz (>=1.8.8). The effect of this incompatibility is that generated graphs in HTML are
not properly clickable. For doxygen 1.3 it is recommended to use at least graphviz 1.8.10 or higher. For doxygen
1.4.7 or higher it is recommended to use GraphViz 2.8 or higher to avoid font issues.
Red Hat 9.0 problems
If you get the following error after running make
Generated by Doxygen
10 Installation
tmake error: qtools.pro:70: Syntax error
then rst type
export LANG=
before running make.
2.4 Compiling from source on Windows
From version 1.7.0 onwards, build les are provided for Visual Studio 2008. Also the free (as in beer) "Express"
version of Developer Studio can be used to compile doxygen. Alternatively, you can compile doxygen the UNIX way
using Cygwin or MinGW.
The next step is to install modern versions of bison and flex (see http://sourceforge.
net/projects/winflexbison. After installation and adding them to your path rename win_flex.exe
to flex.exe and win_bison.exe to bison.exe) Furthermore you have to install python (version 2.6 or
higher, see http://www.python.org). These packages are needed during the compilation process if you
use a GitHub snapshot of doxygen (the ofcial source releases come with pre-generated sources).
Download doxygens source tarball and put it somewhere (e.g. use c:\tools)
Now start a new command shell and type
cd c:\tools
tar zxvf doxygen-x.y.z.src.tar.gz
to unpack the sources (you can obtain tar frome.g. http://gnuwin32.sourceforge.net/packages.
html). Alternatively you can use an unpack program, like 7-Zip (see http://www.7-zip.org) or use the
build in unpack feature of modern Windows systems).
Now your environment is setup to build doxygen.
Inside the doxygen-x.y.z directory you will nd a winbuild directory containing a Doxygen.sln le. Open
this le in Visual Studio. You can now build the Release or Debug avor of Doxygen by right-clicking the project in
the solutions explorer, and selecting Build.
Note that compiling Doxywizard currently requires Qt version 4 (see http://qt-project.org/).
Also read the next section for additional tools you may need to install to run doxygen with certain features enabled.
2.5 Installing the binaries on Windows
Doxygen comes as a self-installing archive, so installation is extremely simple. Just follow the dialogs.
After installation it is recommended to also download and install GraphViz (version 2.20 or better is highly recom-
mended). Doxygen can use the dot tool of the GraphViz package to render nicer diagrams, see the HAVE_DOT
option in the conguration le.
If you want to produce compressed HTML les (see GENERATE_HTMLHELP) in the cong le, then you need the
Microsoft HTML help workshop. You can download it from Microsoft.
If you want to produce Qt Compressed Help les (see QHG_LOCATION) in the cong le, then you need qhelp-
generator which is part of Qt. You can download Qt from Qt Software Downloads.
In order to generate PDF output or use scientic formulas you will also need to install LaTeX and Ghostscript.
For L
A
T
E
X a number of distributions exists. Popular ones that should work with doxygen are MikTex and proTeXt.
Ghostscript can be downloaded from Sourceforge.
After installing L
A
T
E
X and Ghostscript youll need to make sure the tools latex.exe, pdatex.exe, and gswin32c.exe are
present in the search path of a command box. Follow these instructions if you are unsure and run the commands
from a command box to verify it works.
Generated by Doxygen
2.6 Tools used to develop doxygen 11
2.6 Tools used to develop doxygen
Doxygen was developed and tested under Linux & MacOSX using the following open-source tools:
GCC version 4.6.3 (Linux) and 4.2.1 (MacOSX)
GNU ex version 2.5.35
GNU bison version 2.5 (Linux) and 2.3 (MacOSX)
GNU make version 3.81
Perl version 5.12
Python version 2.7 and 3.4
TeX Live 2009 (or later)
Generated by Doxygen
12 Installation
Generated by Doxygen
Chapter 3
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.
Optionally, the executable doxywizard can be used, which is a graphical front-end for editing the conguration
le 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 gure shows the relation between the tools and the ow of information between them (it looks complex
but thats only because it tries to be complete):
import
headers
images
footers
Config file
Doxyfile
Layout file
read
read
generate read
Doxygen
make ps
latex
custom
output
postscript
PDF
HTML
pages
Windows only
read
Sources
Custom
generate/edit
Doxywizard
read
generate
update
generate
XML files
Latex files
Makefile
+
Man pages
refman.rtf
HTML Help Workshop
make pdf
doxmlparser lib
Your application
Tag file(s)
doc
MSWord
chm
read
Figure 3.1: Doxygen information ow
14 Getting Started
3.1 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, Tcl, Fortran, and
D. It is possible to congure certain le type extensions to use certain parsers: see the Conguration/Extension
Mappings for details. Also, completely different languages can be supported by using preprocessor programs: see
the Helpers page for details.
3.2 Step 1: Creating a conguration le
Doxygen uses a conguration le to determine all of its settings. Each project should get its own conguration le.
A project can consist of a single source le, but can also be an entire source tree that is recursively scanned.
To simplify the creation of a conguration le, doxygen can create a template conguration le for you. To do this
call doxygen from the command line with the -g option:
doxygen -g <config-file>
where <cong-le> is the name of the conguration le. If you omit the le name, a le named Doxyfile will
be created. If a le with the name <cong-le> already exists, doxygen will rename it to <cong-le>.bak before
generating the conguration template. If you use - (i.e. the minus sign) as the le name then doxygen will try to
read the conguration le from standard input (stdin), which can be useful for scripting.
The conguration le has a format that is similar to that of a (simple) Makele. 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 conguration le to their default value. See
section Conguration for more details about the conguration le.
If you do not wish to edit the cong le with a text editor, you should have a look at doxywizard, which is a GUI
front-end that can create, read and write doxygen conguration les, and allows setting conguration options by
entering them via dialogs.
For a small project consisting of a few C and/or C++ source and header les, 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 le patterns to the FILE_PATTERNS tag (for instance .cpp .h). Only
les that match one of the patterns will be parsed (if the patterns are omitted a list of typical patterns is used for the
types of les doxygen supports). For recursive parsing of a source tree you must set the RECURSIVE tag to YES.
To further ne-tune the list of les 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:
EXCLUDE_PATTERNS =
*
/test/
*
Doxygen looks at the les extension to determine how to parse a le, using the following table:
Extension Language
.idl IDL
.ddl IDL
.odl IDL
.java Java
.cs C#
Generated by Doxygen
3.3 Step 2: Running doxygen 15
.d D
.php PHP
.php4 PHP
.php5 PHP
.inc PHP
.phtml PHP
.m Objective-C
.M Objective-C
.mm Objective-C
.py Python
.f Fortran
.for Fortran
.f90 Fortran
.vhd VHDL
.vhdl VHDL
.tcl TCL
.ucf VHDL
.qsf VHDL
.md Markdown
.markdown Markdown
Any other extension is parsed as if it is a C/C++ le.
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 conguration le 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 YES.
To analyze an existing piece of software it is useful to cross-reference a (documented) entity with its denition in the
source les. 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).
3.3 Step 2: Running doxygen
To generate the documentation you can now enter:
doxygen <config-file>
Depending on your settings doxygen will create html, rtf, latex, xml, man, and/or docbook directories inside
the output directory. As the names suggest these directories contain the generated documentation in HTML, RTF,
L
A
T
E
X, XML, Unix-Man page, and DocBook format.
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 specic directory within the output directory
can be selected using the HTML_OUTPUT, RTF_OUTPUT, LATEX_OUTPUT, XML_OUTPUT, MAN_OUTPUT,
and DOCBOOK_OUTPUT. tags of the conguration le. 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).
3.3.1 HTML output
The generated HTML documentation can be viewed by pointing a HTML browser to the index.html le in the
html directory. For the best results a browser that supports cascading style sheets (CSS) should be used (Im
using Mozilla Firefox, Google Chrome, Safari, and sometimes IE8, IE9, and Opera to test the generated output).
Some of the features the HTML section (such as GENERATE_TREEVIEW or the search engine) require a browser
that supports Dynamic HTML and Javascript enabled.
Generated by Doxygen
16 Getting Started
3.3.2 LaTeX output
The generated L
A
T
E
X documentation must rst be compiled by a L
A
T
E
X 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 latex directory (on the Windows platform also a make.bat batch le is
generated).
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 le called refman.dvi will be generated. This le can then be
viewed using xdvi or converted into a PostScript le refman.ps by typing make ps (this requires dvips).
To put 2 pages on one physical page use make ps_2on1 instead. The resulting PostScript le 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 and USE_PDFLATEX tags to YES.
In this case the Makefile will only contain a target to build refman.pdf directly.
3.3.3 RTF output
Doxygen combines the RTF output to a single le called refman.rtf. This le is optimized for importing into the
Microsoft Word. Certain information is encoded using so called elds. To show the actual value you need to select
all (Edit - select all) and then toggle elds (right click and select the option from the drop down menu).
3.3.4 XML output
The XML output consists of a structured "dump" of the information gathered by doxygen. Each compound (class/-
namespace/le/...) has its own XML le and there is also an index le called index.xml.
A le called combine.xslt XSLT script is also generated and can be used to combine all XML les into a single
le.
Doxygen also generates two XML schema les index.xsd (for the index le) and compound.xsd (for the
compound les). This schema le describes the possible elements, their attributes and how they are structured, i.e.
it the describes the grammar of the XML les and can be used for validation or to steer XSLT scripts.
In the addon/doxmlparser directory you can nd 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)
3.3.5 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.
3.3.6 DocBook output
Doxygen can also generate output in the DocBook format. How to process the DocBook output is beyond the
scope of this manual.
Generated by Doxygen
3.4 Step 3: Documenting the sources 17
3.4 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 and some related design documentation as well.
If the EXTRACT_ALL option is set to NO in the conguration le (the default), then doxygen will only generate
documentation for documented entities. 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 denition of the member, class or names-
pace. For le, class and namespace members it is also allowed to place the documentation directly after the
member.
See section Special comment blocks to learn more about special documentation blocks.
2. Place a special documentation block somewhere else (another le 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 le).
See section Documentation at other places to learn more about structural commands.
The advantage of the rst option is that you do not have to repeat the name of the entity.
Files can only be documented using the second option, since there is no way to put a documentation block before
a le. Of course, le members (functions, variables, typedefs, denes) do not need an explicit structural command;
just putting a special documentation block in front or behind them will work ne.
The text inside a special documentation block is parsed before it is written to the HTML and/or L
A
T
E
X output les.
During parsing the following steps take place:
Markdown formatting is replaced by corresponding HTML or special commands.
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 whites-
pace, 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 gener-
ation for more information on how the automatic link generation works.
HTML tags that are in the documentation are interpreted and converted to L
A
T
E
X equivalents for the L
A
T
E
X
output. See section HTML Commands for an overview of all supported HTML tags.
Generated by Doxygen
18 Getting Started
Generated by Doxygen
Chapter 4
Documenting the code
This chapter covers two topics:
1. How to put comments in your code such that doxygen incorporates them in the documentation it generates.
This is further detailed in the next section.
2. Ways to structure the contents of a comment block such that the output looks good, as explained in section
Anatomy of a comment block.
4.1 Special comment blocks
A special comment block is a C or C++ style comment block with some additional markings, so doxygen knows it
is a piece of structured text that needs to end up in the generated documentation. The next section presents the
various styles supported by doxygen.
For Python, VHDL, Fortran, and Tcl code there are different commenting conventions, which can be found in sec-
tions Comment blocks in Python, Comment blocks in VHDL, Comment blocks in Fortran, and Comment blocks in
Tcl respectively.
4.1.1 Comment blocks for C-like languages (C/C++/C#/Objective-C/PHP/Java)
For each entity in the code there are two (or in some cases three) types of descriptions, which together form
the documentation for that entity; a brief description and detailed description, both are optional. For methods
and functions there is also a third type of description, the so called in body description, which consists of the
concatenation of all comment blocks found within the body of the method or function.
Having more than one brief or detailed description is allowed (but not recommended, as the order in which the
descriptions will appear is not specied).
As the name suggest, a brief description is a short one-liner, whereas the detailed description provides longer, more
detailed documentation. An "in body" description can also act as a detailed description or can describe a collection
of implementation details. For the HTML output brief descriptions are also used to provide tooltips at places where
an item is referenced.
There are several ways to mark a comment block as a detailed description:
1. You can use the JavaDoc style, which consist of a C-style comment block starting with two s, like this:
/
**
*
... text ...
*
/
2. or you can use the Qt style and add an exclamation mark (!) after the opening of a C-style comment block,
as shown in this example:
20 Documenting the code
/
*
!
*
... text ...
*
/
In both cases the intermediate s are optional, so
/
*
!
... text ...
*
/
is also valid.
3. A third alternative is to use a block of at least two C++ comment lines, where each line starts with an additional
slash or an exclamation mark. Here are examples of the two cases:
///
/// ... text ...
///
or
//!
//!... text ...
//!
Note that a blank line ends a documentation block in this case.
4. Some people like to make their comment blocks more visible in the documentation. For this purpose you can
use the following:
/
********************************************
//
**
*
... text
***********************************************
/
(note the 2 slashes to end the normal comment block and start a special comment block).
or
/////////////////////////////////////////////////
/// ... text ...
/////////////////////////////////////////////////
For the brief description there are also several possibilities:
1. One could use the \brief command with one of the above comment blocks. This command ends at the end of
a paragraph, so the detailed description follows after an empty line.
Here is an example:
/
*
! \brief Brief description.
*
Brief description continued.
*
*
Detailed description starts here.
*
/
2. If JAVADOC_AUTOBRIEF is set to YES in the conguration le, then using JavaDoc style comment blocks
will automatically start a brief description which ends at the rst dot followed by a space or new line. Here is
an example:
/
**
Brief description which ends at this dot. Details follow
*
here.
*
/
The option has the same effect for multi-line special C++ comments:
Generated by Doxygen
4.1 Special comment blocks 21
/// Brief description which ends at this dot. Details follow
/// here.
3. A third option is to use a special C++ style comment which does not span more than one line. Here are two
examples:
/// Brief description.
/
**
Detailed description.
*
/
or
//! Brief description.
//! Detailed description
//! starts here.
Note the blank line in the last example, which is required to separate the brief description from the block
containing the detailed description. The JAVADOC_AUTOBRIEF should also be set to NO for this case.
As you can see doxygen is quite exible. If you have multiple detailed descriptions, like in the following example:
//! Brief description, which is
//! really a detailed description since it spans multiple lines.
/
*
! Another detailed description!
*
/
They will be joined. Note that this is also the case if the descriptions are at different places in the code! In this case
the order will depend on the order in which doxygen parses the code.
Unlike most other documentation systems, doxygen also allows you to put the documentation of members (including
global functions) in front of the denition. This way the documentation can be placed in the source le instead of the
header le. This keeps the header le 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 denition.
4.1.1.1 Putting documentation after members
If you want to document the members of a le, struct, union, class, or enum, it is sometimes desired to place the
documentation block after the member instead of before. For this purpose you have to put an additional < marker
in the comment block. Note that this also works for the parameters of a function.
Here are some examples:
int var; /
*
!< Detailed description after the member
*
/
This block can be used to put a Qt style detailed documentation block after a member. Other ways to do the same
are:
int var; /
**
< Detailed description after the member
*
/
or
int var; //!< Detailed description after the member
//!<
or
int var; ///< Detailed description after the member
///<
Most often one only wants to put a brief description after a member. This is done as follows:
int var; //!< Brief description after the member
Generated by Doxygen
22 Documenting the code
or
int var; ///< Brief description after the member
For functions one can use the @param command to document the parameters and then use [in], [out],
[in,out] to document the direction. For inline documentation this is also possible by starting with the direc-
tion attribute, e.g.
void foo(int v /
**
< [in] docs for input parameter v.
*
/);
Note that these blocks have the same structure and meaning as the special comment blocks in the previous section
only the < indicates that the member is located in front of the block instead of after the block.
Here is an example of 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
*
/
};
Warning
These blocks can only be used to document members and parameters. They cannot be used to document les,
classes, unions, structs, groups, namespaces and enums themselves. Furthermore, the structural commands
mentioned in the next section (like \class) are not allowed inside these comment blocks.
4.1.1.2 Examples
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.
Generated by Doxygen
4.1 Special comment blocks 23
/
*
!
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 character 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 brief descriptions are included in the member overview of a class, namespace or le and are printed using
a small italic font (this description can be hidden by setting BRIEF_MEMBER_DESC to NO in the cong le). By
default the brief descriptions become the rst sentence of the detailed descriptions (but 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.
By default a JavaDoc style documentation block behaves the same way as a Qt style documentation block. This is
not according the JavaDoc specication however, where the rst sentence of the documentation block is automati-
cally treated as a brief description. To enable this behavior you should set JAVADOC_AUTOBRIEF to YES in the
conguration le. If you enable this option and want to put a dot in the middle of a sentence without ending it, you
should put a backslash and a space after it. Here is an example:
/
**
Brief description (e.g.\ using only a few words). Details follow.
*
/
Here is the same piece of code as shown above, this time documented using the JavaDoc style and JAVADOC_
AUTOBRIEF set to YES:
/
**
*
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.
Generated by Doxygen
24 Documenting the code
*
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 character 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);
};
Similarly, if one wishes the rst sentence of a Qt style documentation block to automatically be treated as a brief
description, one may set QT_AUTOBRIEF to YES in the conguration le.
4.1.1.3 Documentation at other places
In the examples in the previous section the comment blocks were always located in front of the declaration or
denition of a le, class or namespace or in front or after one of its members. Although this is often comfortable,
there may sometimes be reasons to put the documentation somewhere else. For documenting a le this is even
required since there is no such thing as "in front of a le".
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).
The price you pay for not putting the documentation block directly before (or after) an item is the need to put a
structural command inside the documentation block, which leads to some duplication of information. So in practice
you should avoid the use of structural commands unless other requirements force you to do so.
Structural commands (like all other commands) start with a backslash (\), or an at-sign (@) if you prefer JavaDoc
style, 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 indicate 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.
Generated by Doxygen
4.1 Special comment blocks 25
\fn to document a function.
\var to document a variable or typedef or enum value.
\def to document a #dene.
\typedef to document a type denition.
\file to document a le.
\namespace to document a namespace.
\package to document a Java package.
\interface to document an IDL interface.
See section Special Commands for detailed information about these and many other commands.
To document a member of a C++ class, you must also document the class itself. The same holds for namespaces.
To document a global C function, typedef, enum or preprocessor denition you must rst document the le that
contains it (usually this will be a header le, because that le contains the information that is exported to other
source les).
Attention
Lets repeat that, because it is often overlooked: to document global objects (functions, typedefs, enum, macros,
etc), you must document the le in which they are dened. In other words, there must at least be a
/
*
! \file
*
/
or a
/
**
@file
*
/
line in this le.
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.
Generated by Doxygen
26 Documenting the code
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);
Because each comment block in the example above contains a structural command, all the comment blocks could be
moved to another location or input le (the source le 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! Because
of this you should rst consider if this is really needed, and avoid structural commands if possible. I often receive
examples that contain \fn command in comment blocks which are place in front of a function. This is clearly a case
where the \fn command is redundant and will only lead to problems.
When you place a comment block in a le with one of the following extensions .dox, .txt, or .doc then doxygen
will hide this le from the le list.
If you have a le that doxygen cannot parse but still would like to document it, you can show it as-is using \verbin-
clude, e.g.
/
*
! \file myscript.sh
*
Look at this nice script:
*
\verbinclude myscript.sh
*
/
Make sure that the script is explicitly listed in the INPUT or that FILE_PATTERNS includes the .sh extention and
the the script can be found in the path set via EXAMPLE_PATH.
4.1.2 Comment blocks in Python
For Python there is a standard way of documenting the code using so called documentation strings. Such strings
are stored in doc and can be retrieved at runtime. Doxygen will extract such comments and assume they have to
be represented in a preformatted way.
1 """@package docstring
2 Documentation for this module.
3
4 More details.
5 """
6
7 def func():
8 """Documentation for a function.
9
10 More details.
11 """
12 pass
13
14 class PyClass:
15 """Documentation for a class.
16
17 More details.
18 """
19
20 def __init__(self):
21 """The constructor."""
22 self._memVar = 0;
23
24 def PyMethod(self):
25 """Documentation for a method."""
26 pass
27
Generated by Doxygen
4.1 Special comment blocks 27
Note that in this case none of doxygens special commands are supported.
There is also another way to document Python code using comments that start with "##". These type of comment
blocks are more in line with the way documentation blocks work for the other languages supported by doxygen and
this also allows the use of special commands.
Here is the same example again but now using doxygen style comments:
1 ## @package pyexample
2 # Documentation for this module.
3 #
4 # More details.
5
6 ## Documentation for a function.
7 #
8 # More details.
9 def func():
10 pass
11
12 ## Documentation for a class.
13 #
14 # More details.
15 class PyClass:
16
17 ## The constructor.
18 def __init__(self):
19 self._memVar = 0;
20
21 ## Documentation for a method.
22 # @param self The object pointer.
23 def PyMethod(self):
24 pass
25
26 ## A class variable.
27 classVar = 0;
28
29 ## @var _memVar
30 # a member variable
Since python looks more like Java than like C or C++, you should set OPTIMIZE_OUTPUT_JAVA to YES in the
cong le.
4.1.3 Comment blocks in VHDL
For VHDL a comment normally start with "--". Doxygen will extract comments starting with "--!". There are only two
types of comment blocks in VHDL; a one line "--!" comment representing a brief description, and a multi-line "--!"
comment (where the "--!" prex is repeated for each line) representing a detailed description.
Comments are always located in front of the item that is being documented with one exception: for ports the
comment can also be after the item and is then treated as a brief description for the port.
Here is an example VHDL le with doxygen comments:
1 -------------------------------------------------------
2 --! @file
3 --! @brief 2:1 Mux using with-select
4 -------------------------------------------------------
5
6 --! Use standard library
7 library ieee;
8 --! Use logic elements
9 use ieee.std_logic_1164.all;
10
11 --! Mux entity brief description
12
13 --! Detailed description of this
14 --! mux design element.
15 entity mux_using_with is
16 port (
17 din_0 : in std_logic; --! Mux first input
18 din_1 : in std_logic; --! Mux Second input
19 sel : in std_logic; --! Select input
20 mux_out : out std_logic --! Mux output
21 );
22 end entity;
23
24 --! @brief Architecture definition of the MUX
Generated by Doxygen
28 Documenting the code
25 --! @details More details about this mux element.
26 architecture behavior of mux_using_with is
27 begin
28 with (sel) select
29 mux_out <= din_0 when 0,
30 din_1 when others;
31 end architecture;
32
To get proper looking output you need to set OPTIMIZE_OUTPUT_VHDL to YES in the cong le. This will also
affect a number of other settings. When they were not already set correctly doxygen will produce a warning telling
which settings where overruled.
4.1.4 Comment blocks in Fortran
When using doxygen for Fortran code you should set OPTIMIZE_FOR_FORTRAN to YES.
The parser tries to guess if the source code is xed format Fortran or free format Fortran code. This may not always
be correct. If not one should use EXTENSION_MAPPING to correct this. By setting EXTENSION_MAPPING =
f=FortranFixed f90=FortranFree les with extension f are interpreted as xed format Fortran code and
les with extension f90 are interpreted as free format Fortran code.
For Fortran "!>" or "!<" starts a comment and "!!" or "!>" can be used to continue an one line comment into a
multi-line comment.
Here is an example of a documented Fortran subroutine:
!> Build the restriction matrix for the aggregation
!! method.
!! @param aggr information about the aggregates
!! @todo Handle special case
subroutine intrestbuild(A,aggr,Restrict,A_ghost)
implicit none
Type(spmtx), intent(in) :: a !< our fine level matrix
Type(aggrs), intent(in) :: aggr
Type(spmtx), intent(out) :: restrict !< Our restriction matrix
!...
end subroutine
As an alternative you can also use comments in xed format code:
C> Function comment
C> another line of comment
function a(i)
C> input parameter
integer i
end function A
4.1.5 Comment blocks in Tcl
Doxygen documentation can be included in normal Tcl comments.
To start a new documentation block start a line with ## (two hashes). All following comment lines and continuation
lines will be added to this block. The block ends with a line not starting with a # (hash sign).
A brief documentation can be added with ;#< (semicolon, hash and lower then sign). The brief documentation also
ends at a line not starting with a # (hash sign).
Inside doxygen comment blocks all normal doxygen markings are supported. The only exceptions are described in
the following two paragraphs.
If a doxygen comment block ends with a line containing only #\code or #@code all code until a line only containing
#\endcode or #@endcode is added to the generated documentation as code block.
If a doxygen comment block ends with a line containing only #\verbatim or #@verbatim all code until a line
only containing #\endverbatim or #@endverbatim is added verbatim to the generated documentation.
To detect namespaces, classes, functions and variables the following Tcl commands are recognized. Documenta-
tion blocks can be put on the lines before the command.
Generated by Doxygen
4.1 Special comment blocks 29
namespace eval .. Namespace
proc .. Function
variable .. Variable
common .. Common variable
itcl::class .. Class
itcl::body .. Class method body denition
oo::class create .. Class
oo::define .. OO Class denition
method .. Class method denitions
constructor .. Class constructor
destructor .. Class destructor
public .. Set protection level
protected .. Set protection level
private .. Set protection level
Following is an example using doxygen style comments:
1 ## file tclexample.tcl
2 # File documentation.
3 #verbatim
4
5 # Startup code:
6 exec tclsh "$0" "$@"
7 #endverbatim
8 ## Documented namespace c ns .
9 # The code is inserted here:
10 #code
11 namespace eval ns {
12 ## Documented proc c ns_proc .
13 # param[in] arg some argument
14 proc ns_proc {arg} {}
15 ## Documented var c ns_var .
16 # Some documentation.
17 variable ns_var
18 ## Documented itcl class c itcl_class .
19 itcl::class itcl_class {
20 ## Create object.
21 constructor {args} {eval $args}
22 ## Destroy object.
23 destructor {exit}
24 ## Documented itcl method c itcl_method_x .
25 # param[in] arg Argument
26 private method itcl_method_x {arg}{}
27 ## Documented itcl method c itcl_method_y .
28 # param[in] arg Argument
29 protected method itcl_method_y {arg} {}
30 ## Documented itcl method c itcl_method_z .
31 # param[in] arg Argument
32 public method itcl_method_z {arg} {}
33 ## Documented common itcl var c itcl_Var .
34 common itcl_Var
35 ## protectedsection
36
37 variable itcl_var1;#< Documented itcl var c itcl_var1 .
38 variable itcl_var2}
39 ## Documented oo class c oo_class .
40 oo::class create oo_class {
41 ## Create object.
42 # Configure with args
43 constructor {args} {eval $args}
44 ## Destroy object.
45 # Exit.
46 destructor {exit}
47 ## Documented oo var c oo_var .
48 # Defined inside class
49 variable oo_var
Generated by Doxygen
30 Documenting the code
50 ## private Documented oo method c oo_method_x .
51 # param[in] arg Argument
52 method oo_method_x {arg} {}
53 ## protected Documented oo method c oo_method_y .
54 # param[in] arg Argument
55 method oo_method_y {arg} {}
56 ## public Documented oo method c oo_method_z .
57 # param[in] arg Argument
58 method oo_method_z {arg} {}
59 }
60 }
61 #endcode
62
63 itcl::body ::ns::itcl_class::itcl_method_x {argx} {
64 puts "$argx OK"
65 }
66
67 oo::define ns::oo_class {
68 ## public Outside defined variable c oo_var_out .
69 # Inside oo_class
70 variable oo_var_out
71 }
72
73 ## Documented global proc c glob_proc .
74 # param[in] arg Argument
75 proc glob_proc {arg} {puts $arg}
76
77 variable glob_var;#< Documented global var c glob_var
78 with newline
79 #< and continued line
80
81 # end of file
4.2 Anatomy of a comment block
The previous section focused on how to make the comments in your code known to doxygen, it explained the
difference between a brief and a detailed description, and the use of structural commands.
In this section we look at the contents of the comment block itself.
Doxygen supports various styles of formatting your comments.
The simplest form is to use plain text. This will appear as-is in the output and is ideal for a short description.
For longer descriptions you often will nd the need for some more structure, like a block of verbatim text, a list,
or a simple table. For this doxygen supports the Markdown syntax, including parts of the Markdown Extra
extension.
Markdown is designed to be very easy to read and write. Its formatting is inspired by plain text mail. Markdown
works great for simple, generic formatting, like an introduction page for your project. Doxygen also supports reading
of markdown les directly. See here for more details regards Markdown support.
For programming language specic formatting doxygen has two forms of additional markup on top of Markdown
formatting.
1. Javadoc like markup. See here for a complete overview of all commands supported by doxygen.
2. XML markup as specied in the C# standard. See here for the XML commands supported by doxygen.
If this is still not enough doxygen also supports a subset of the HTML markup language.
Generated by Doxygen
Chapter 5
Markdown
Markdown support was introduced in doxygen version 1.8.0. It is a plain text formatting syntax written by John
Gruber, with the following underlying design goal:
The design goal for Markdowns formatting syntax is to make it as readable as possible. The idea is
that a Markdown-formatted document should be publishable as-is, as plain text, without looking like its
been marked up with tags or formatting instructions. While Markdowns syntax has been inuenced by
several existing text-to-HTML lters, the single biggest source of inspiration for Markdowns syntax is
the format of plain text email.
In the next section the standard Markdown features are briey discussed. The reader is referred to the Markdown
site for more details.
Some enhancements were made, for instance PHP Markdown Extra, and GitHub flavored
Markdown. The section Markdown Extensions discusses the extensions that doxygen supports.
Finally section Doxygen specics discusses some specics for doxygens implementation of the Markdown standard.
5.1 Standard Markdown
5.1.1 Paragraphs
Even before doxygen had Markdown support it supported the same way of paragraph handling as Markdown: to
make a paragraph you just separate consecutive lines of text by one or more blank lines.
An example:
Here is text for one paragraph.
We continue with more text in another paragraph.
5.1.2 Headers
Just like Markdown, doxygen supports two types of headers
Level 1 or 2 headers can be made as the follows
This is a level 1 header
========================
This is a level 2 header
------------------------
A header is followed by a line containing only =s or -s. Note that the exact amount of =s or -s is not important as
long as there are at least two.
32 Markdown
Alternatively, you can use #s at the start of a line to make a header. The number of #s at the start of the line
determines the level (up to 6 levels are supported). You can end a header by any number of #s.
Here is an example:
# This is a level 1 header
### This is level 3 header #######
5.1.3 Block quotes
Block quotes can be created by starting each line with one or more >s, similar to what is used in text-only emails.
> This is a block quote
> spanning multiple lines
Lists and code blocks (see below) can appear inside a quote block. Quote blocks can also be nested.
Note that doxygen requires that you put a space after the (last) > character to avoid false positives, i.e. when writing
0 if OK\n
>1 if NOK
the second line will not be seen as a block quote.
5.1.4 Lists
Simple bullet lists can be made by starting a line with -, +, or .
- Item 1
More text for this item.
- Item 2
+ nested list item.
+ another nested item.
- Item 3
List items can span multiple paragraphs (if each paragraph starts with the proper indentation) and lists can be
nested. You can also make a numbered list like so
1. First item.
2. Second item.
Make sure to also read Lists Extensions for doxygen specics.
5.1.5 Code Blocks
Preformatted verbatim blocks can be created by indenting each line in a block of text by at least 4 extra spaces
This a normal paragraph
This is a code block
We continue with a normal paragraph again.
Doxygen will remove the mandatory indentation from the code block. Note that you cannot start a code block in the
middle of a paragraph (i.e. the line preceding the code block must be empty).
See section Code Block Indentation for more info how doxygen handles indentation as this is slightly different than
standard Markdown.
Generated by Doxygen
5.1 Standard Markdown 33
5.1.6 Horizontal Rulers
A horizontal ruler will be produced for lines containing at least three or more hyphens, asterisks, or underscores.
The line may also include any amount of whitespace.
Examples:
- - -
______
Note that using asterisks in comment blocks does not work. See Use of asterisks for details.
5.1.7 Emphasis
To emphasize a text fragment you start and end the fragment with an underscore or star. Using two stars or
underscores will produce strong emphasis.
Examples:
single asterisks
*
_single underscores_
double asterisks
**
__double underscores__
See section Emphasis limits for more info how doxygen handles emphasis spans slightly different than standard
Markdown.
5.1.8 code spans
To indicate a span of code, you should wrap it in backticks (). Unlike code blocks, code spans appear inline in a
paragraph. An example:
Use the printf() function.
To show a literal backtick inside a code span use double backticks, i.e.
To assign the output of command ls to var use var=ls.
See section Code Spans Limits for more info how doxygen handles code spans slightly different than standard
Markdown.
5.1.9 Links
Doxygen supports both styles of make links dened by Markdown: inline and reference.
For both styles the link denition starts with the link text delimited by [square brackets].
5.1.9.1 Inline Links
For an inline link the link text is followed by a URL and an optional link title which together are enclosed in a set of
regular parenthesis. The link title itself is surrounded by quotes.
Examples:
[The link text](http://example.net/)
[The link text](http://example.net/ "Link title")
[The link text](/relative/path/to/index.html "Link title")
[The link text](somefile.html)
Generated by Doxygen
34 Markdown
In addition doxygen provides a similar way to link a documented entity:
[The link text](@ref MyClass)
5.1.9.2 Reference Links
Instead of putting the URL inline, you can also dene the link separately and then refer to it from within the text.
The link denition looks as follows:
[link name]: http://www.example.com "Optional title"
Instead of double quotes also single quotes or parenthesis can be used for the title part.
Once dened, the link looks as follows
[link text][link name]
If the link text and name are the same, also
[link name][]
or even
[link name]
can be used to refer to the link. Note that the link name matching is not case sensitive as is shown in the following
example:
I get 10 times more traffic from [Google] than from
[Yahoo] or [MSN].
[google]: http://google.com/ "Google"
[yahoo]: http://search.yahoo.com/ "Yahoo Search"
[msn]: http://search.msn.com/ "MSN Search"
Link denitions will not be visible in the output.
Like for inline links doxygen also supports @ref inside a link denition:
[myclass]: @ref MyClass "My class"
5.1.10 Images
Markdown syntax for images is similar to that for links. The only difference is an additional ! before the link text.
Examples:


![Caption text][img def]
![img def]
[img def]: /path/to/img.jpg "Optional Title"
Also here you can use @ref to link to an image:

![img def]
[img def]: @ref image.png "Caption text"
The caption text is optional.
Generated by Doxygen
5.2 Markdown Extensions 35
5.1.11 Automatic Linking
To create a link to an URL or e-mail address Markdown supports the following syntax:
<http://www.example.com>
<https://www.example.com>
<ftp://www.example.com>
<mailto:[email protected]>
<[email protected]>
Note that doxygen will also produce the links without the angle brackets.
5.2 Markdown Extensions
5.2.1 Table of Contents
Doxygen supports a special link marker [TOC] which can be placed in a page to produce a table of contents at the
start of the page, listing all sections.
Note that using [TOC] is the same as using a \tableofcontents command.
5.2.2 Tables
Of the features dened by "Markdown Extra" is support for simple tables:
A table consists of a header line, a separator line, and at least one row line. Table columns are separated by the
pipe ([) character.
Here is an example:
First Header | Second Header
------------- | -------------
Content Cell | Content Cell
Content Cell | Content Cell
which will produce the following table:
First Header Second Header
Content Cell Content Cell
Content Cell Content Cell
Column alignment can be controlled via one or two colons at the header separator line:
| Right | Center | Left |
| ----: | :----: | :---- |
| 10 | 10 | 10 |
| 1000 | 1000 | 1000 |
which will look as follows:
Right Center Left
10 10 10
1000 1000 1000
5.2.3 Fenced Code Blocks
Another feature dened by "Markdown Extra" is support for fenced code blocks:
A fenced code block does not require indentation, and is dened by a pair of "fence lines". Such a line consists of
3 or more tilde () characters on a line. The end of the block should have the same number of tildes. Here is an
example:
Generated by Doxygen
36 Markdown
This is a paragraph introducing:
~~~~~~~~~~~~~~~~~~~~~
a one-line code block
~~~~~~~~~~~~~~~~~~~~~
By default the output is the same as for a normal code block.
For languages supported by doxygen you can also make the code block appear with syntax highlighting. To do
so you need to indicate the typical le extension that corresponds to the programming language after the opening
fence. For highlighting according to the Python language for instance, you would need to write the following:
~~~~~~~~~~~~~{.py}
# A class
class Dummy:
pass
~~~~~~~~~~~~~
which will produce:
1 # A class
2 class Dummy:
3 pass
and for C you would write:
~~~~~~~~~~~~~~~{.c}
int func(int a,int b) { return a
*
b; }
~~~~~~~~~~~~~~~
which will produce:
int func(int a,int b) { return a
*
b; }
The curly braces and dot are optional by the way.
5.2.4 Header Id Attributes
Standard Markdown has no support for labeling headers, which is a problem if you want to link to a section.
PHP Markdown Extra allows you to label a header by adding the following to the header
Header 1 {#labelid}
========
## Header 2 ## {#labelid2}
To link to a section in the same comment block you can use
[Link text](#labelid)
to link to a section in general, doxygen allows you to use @ref
[Link text](@ref labelid)
Note this only works for the headers of level 1 to 4.
5.3 Doxygen specics
Even though doxygen tries to following the Markdown standard as closely as possible, there are couple of deviation
and doxygen specics additions.
Generated by Doxygen
5.3 Doxygen specics 37
5.3.1 Including Markdown les as pages
Doxygen can process les with Markdown formatting. For this to work the extension for such a le should be .md
or .markdown (see EXTENSION_MAPPING if your Markdown les have a different extension, and use md as the
name of the parser). Each le is converted to a page (see the page command for details).
By default the name and title of the page are derived from the le name. If the le starts with a level 1 header
however, it is used as the title of the page. If you specify a label for the header (as shown here) doxygen will use
that as the page name.
If the label is called index or mainpage doxygen will put the documentation on the front page (index.html).
Here is an example of a le README.md that will appear as the main page when processed by doxygen:
My Main Page {#mainpage}
============
Documentation that will appear on the main page
If a page has a label you can link to it using @ref as is shown above. To refer to a markdown page without such
label you can simple use the le name of the page, e.g.
See [the other page](other.md) for more info.
5.3.2 Treatment of HTML blocks
Markdown is quite strict in the way it processes block-level HTML:
block-level HTML elements e.g. <div>, <table>, <pre>, <p>, etc. must be separated
from surrounding content by blank lines, and the start and end tags of the block should not be indented
with tabs or spaces.
Doxygen does not have this requirement, and will also process Markdown formatting inside such HTML blocks. The
only exception is <pre> blocks, which are passed untouched (handy for ASCII art).
Doxygen will not process Markdown formatting inside verbatim or code blocks, and in other sections that need to
be processed without changes (for instance formulas or inline dot graphs).
5.3.3 Code Block Indentation
Markdown allows both a single tab or 4 spaces to start a code block. Since doxygen already replaces tabs by
spaces before doing Markdown processing, the effect will only be same if TAB_SIZE in the cong le has been set
to 4. When it is set to a higher value spaces will be present in the code block. A lower value will prevent a single tab
to be interpreted as the start of a code block.
With Markdown any block that is indented by 4 spaces (and 8 spaces inside lists) is treated as a code block. This
indentation amount is absolute, i.e. counting from the start of the line.
Since doxygen comments can appear at any indentation level that is required by the programming language, it uses
a relative indentation instead. The amount of indentation is counted relative to the preceding paragraph. In case
there is no preceding paragraph (i.e. you want to start with a code block), the minimal amount of indentation of the
whole comment block is used as a reference.
In most cases this difference does not result in different output. Only if you play with the indentation of paragraphs
the difference is noticeable:
text
text
text
code
Generated by Doxygen
38 Markdown
In this case Markdown will put the word code in a code block, whereas Doxygen will treat it as normal text, since
although the absolute indentation is 4, the indentation with respect to the previous paragraph is only 1.
Note that list markers are not counted when determining the relative indent:
1. Item1
More text for item1
2. Item2
Code block for item2
For Item1 the indentation is 4 (when treating the list marker as whitespace), so the next paragraph "More text..."
starts at the same indentation level and is therefore not seen as a code block.
5.3.4 Emphasis limits
Unlike standard Markdown, doxygen will not touch internal underscores or stars, so the following will appear as-is:
a_nice_identifier
Furthermore, a or _ only starts an emphasis if
it is followed by an alphanumerical character, and
it is preceded by a space, newline, or one the following characters <{([,:;
An emphasis ends if
it is not followed by an alphanumerical character, and
it is not preceded by a space, newline, or one the following characters ({[<=+-\@
Lastly, the span of the emphasis is limited to a single paragraph.
5.3.5 Code Spans Limits
Note that unlike standard Markdown, doxygen leaves the following untouched.
A cool word in a nice sentence.
In other words; a single quote cancels the special treatment of a code span wrapped in a pair of backtick characters.
This extra restriction was added for backward compatibility reasons.
5.3.6 Lists Extensions
With Markdown two lists separated by an empty line are joined together into a single list which can be rather
unexpected and many people consider it to be a bug. Doxygen, however, will make two separate lists as you would
expect.
Example:
- Item1 of list 1
- Item2 of list 1
1. Item1 of list 2
2. Item2 of list 2
With Markdown the actual numbers you use to mark the list have no effect on the HTML output Markdown produces.
I.e. standard Markdown treats the following as one list with 3 numbered items:
Generated by Doxygen
5.4 Debugging of problems 39
1. Item1
1. Item2
1. Item3
Doxygen however requires that the numbers used as marks are in strictly ascending order, so the above example
would produce 3 lists with one item. An item with an equal or lower number than the preceding item, will start a new
list. For example:
1. Item1 of list 1
3. Item2 of list 1
2. Item1 of list 2
4. Item2 of list 2
will produce:
1. Item1 of list 1
2. Item2 of list 1
1. Item1 of list 2
2. Item2 of list 2
Historically doxygen has an additional way to create numbered lists by using -# markers:
-# item1
-# item2
5.3.7 Use of asterisks
Special care has to be taken when using s in a comment block to start a list or make a ruler.
Doxygen will strip off any leading s from the comment before doing Markdown processing. So although the
following works ne
/
**
A list:
* *
item1
* *
item2
*
/
When you remove the leading s doxygen will strip the other stars as well, making the list disappear!
Rulers created with s will not be visible at all. They only work in Markdown les.
5.3.8 Limits on markup scope
To avoid that a stray or _ matches something many paragraphs later, and shows everything in between with
emphasis, doxygen limits the scope of a and _ to a single paragraph.
For a code span, between the starting and ending backtick only two new lines are allowed.
Also for links there are limits; the link text, and link title each can contain only one new line, the URL may not contain
any newlines.
5.4 Debugging of problems
When doxygen parses the source code it rst extracts the comments blocks, then passes these through the Mark-
down preprocessor. The output of the Markdown preprocessing consists of text with special commands and HTML
commands. A second pass takes the output of the Markdown preprocessor and converts it into the various output
formats.
Generated by Doxygen
40 Markdown
During Markdown preprocessing no errors are produced. Anything that does not t the Markdown syntax is simply
passed on as-is. In the subsequent parsing phase this could lead to errors, which may not always be obvious as
they are based on the intermediate format.
To see the result after Markdown processing you can run doxygen with the -d Markdown option. It will then print
each comment block before and after Markdown processing.
Generated by Doxygen
Chapter 6
Lists
Doxygen provides a number of ways to create lists of items.
Using dashes
By putting a number of column-aligned minus (-) signs at the start of a line, a bullet list will automatically be gener-
ated. Instead of the minus sign also plus (+) or asterisk () can be used.
Numbered lists can also be generated by using a minus followed by a hash or by using a number followed by a dot.
Nesting of lists is allowed and is based on indentation of the items.
Here is an example:
/
*
!
*
A list of events:
*
- mouse events
*
-# mouse move event
*
-# mouse click event\n
*
More info about the click event.
*
-# mouse double click event
*
- keyboard events
*
1. key down event
*
2. key up event
*
*
More text here.
*
/
The result will be:
A list of events:
mouse events
1. mouse move event
2. mouse click event
More info about the click event.
3. mouse double click event
keyboard events
1. key down event
2. key up event
More text here.
If you use tabs for indentation within lists, please make sure that TAB_SIZE in the conguration le is set to the
correct tab size.
42 Lists
You can end a list by starting a new paragraph or by putting a dot (.) on an empty line at the same indentation level
as the list you would like to end.
Here is an example that speaks for itself:
/
**
*
Text before the list
*
- list item 1
*
- sub item 1
*
- sub sub item 1
*
- sub sub item 2
*
.
*
The dot above ends the sub sub item list.
*
*
More text for the first sub item
*
.
*
The dot above ends the first sub item.
*
*
More text for the first list item
*
- sub item 2
*
- sub item 3
*
- list item 2
*
.
*
More text in the same paragraph.
*
*
More text in a new paragraph.
*
/
Using HTML commands
If you like you can also use HTML commands inside the documentation blocks.
Here is the above example with HTML commands:
/
*
!
*
A list of events:
*
<ul>
*
<li> mouse events
*
<ol>
*
<li>mouse move event
*
<li>mouse click event<br>
*
More info about the click event.
*
<li>mouse double click event
*
</ol>
*
<li> keyboard events
*
<ol>
*
<li>key down event
*
<li>key up event
*
</ol>
*
</ul>
*
More text here.
*
/
Note
In this case the indentation is not important.
Using \arg or \li
For compatibility with the Qt Softwares internal documentation tool qdoc and with KDoc, doxygen has two com-
mands that can be used to create simple unnested lists.
See \arg and \li for more info.
Generated by Doxygen
Chapter 7
Grouping
Doxygen has three mechanisms to group things together. One mechanism works at a global level, creating a new
page for each group. These groups are called modules in the documentation. The second mechanism works
within a member list of some compound entity, and is referred to as a member groups. For pages there is a third
grouping mechanism referred to as subpaging.
7.1 Modules
Modules are a way to group things together on a separate page. You can document a group as a whole, as well
as all individual members. Members of a group can be les, namespaces, classes, functions, variables, enums,
typedefs, and denes, but also other groups.
To dene a group, you should put the \defgroup command in a special comment block. The rst argument of the
command is a label that should uniquely identify the group. The second argument is the name or title of the group
as it should appear in the documentation.
You can make an entity a member of a specic group by putting a \ingroup command inside its documentation block.
To avoid putting \ingroup commands in the documentation for each member you can also group members together
by the open marker @{ before the group and the closing marker @} after the group. The markers can be put in the
documentation of the group denition or in a separate documentation block.
Groups themselves can also be nested using these grouping markers.
You will get an error message when you use the same group label more than once. If you dont want doxygen to
enforce unique labels, then you can use \addtogroup instead of \defgroup. It can be used exactly like \defgroup, but
when the group has been dened already, then it silently merges the existing documentation with the new one. The
title of the group is optional for this command, so you can use
/
**
\addtogroup <label>
*
@{
*
/
...
/
**
@}
*
/
to add additional members to a group that is dened in more detail elsewhere.
Note that compound entities (like classes, les and namespaces) can be put into multiple groups, but members (like
variable, functions, typedefs and enums) can only be a member of one group (this restriction is in place to avoid
ambiguous linking targets in case a member is not documented in the context of its class, namespace or le, but
only visible as part of a group).
Doxygen will put members into the group whose denition has the highest "priority": e.g. An explicit \ingroup
overrides an implicit grouping denition via @{ @}. Conicting grouping denitions with the same priority trigger a
warning, unless one denition was for a member without any explicit documentation.
The following example puts VarInA into group A and silently resolves the conict for IntegerVariable by putting it into
44 Grouping
group IntVariables, because the second instance of IntegerVariable is undocumented:
/
**
*
\ingroup A
*
/
extern int VarInA;
/
**
*
\defgroup IntVariables Global integer variables
*
@{
*
/
/
**
an integer variable
*
/
extern int IntegerVariable;
/
**
@}
*
/
....
/
**
*
\defgroup Variables Global variables
*
/
/
**
@{
*
/
/
**
a variable in group A
*
/
int VarInA;
int IntegerVariable;
/
**
@}
*
/
The \ref command can be used to refer to a group. The rst argument of the \ref command should be groups label.
To use a custom link name, you can put the name of the links in double quotes after the label, as shown by the
following example
This is the \ref group_label "link" to this group.
The priorities of grouping denitions are (from highest to lowest): \ingroup, \defgroup, \addtogroup, \weakgroup.
The last command is exactly like \addtogroup with a lower priority. It was added to allow "lazy" grouping denitions:
you can use commands with a higher priority in your .h les to dene the hierarchy and \weakgroup in .c les without
having to duplicate the hierarchy exactly.
Example:
/
**
@defgroup group1 The First Group
*
This is the first group
*
@{
*
/
/
**
@brief class C1 in group 1
*
/
class C1 {};
/
**
@brief class C2 in group 1
*
/
class C2 {};
/
**
function in group 1
*
/
void func() {}
/
**
@}
*
/ // end of group1
/
**
*
@defgroup group2 The Second Group
*
This is the second group
*
/
/
**
@defgroup group3 The Third Group
*
This is the third group
*
/
/
**
@defgroup group4 The Fourth Group
Generated by Doxygen
7.2 Member Groups 45
*
@ingroup group3
*
Group 4 is a subgroup of group 3
*
/
/
**
*
@ingroup group2
*
@brief class C3 in group 2
*
/
class C3 {};
/
**
@ingroup group2
*
@brief class C4 in group 2
*
/
class C4 {};
/
**
@ingroup group3
*
@brief class C5 in @link group3 the third group@endlink.
*
/
class C5 {};
/
**
@ingroup group1 group2 group3 group4
*
namespace N1 is in four groups
*
@sa @link group1 The first group@endlink, group2, group3, group4
*
*
Also see @ref mypage2
*
/
namespace N1 {};
/
**
@file
*
@ingroup group3
*
@brief this file in group 3
*
/
/
**
@defgroup group5 The Fifth Group
*
This is the fifth group
*
@{
*
/
/
**
@page mypage1 This is a section in group 5
*
Text of the first section
*
/
/
**
@page mypage2 This is another section in group 5
*
Text of the second section
*
/
/
**
@}
*
/ // end of group5
/
**
@addtogroup group1
*
*
More documentation for the first group.
*
@{
*
/
/
**
another function in group 1
*
/
void func2() {}
/
**
yet another function in group 1
*
/
void func3() {}
/
**
@}
*
/ // end of group1
7.2 Member Groups
If a compound (e.g. a class or le) has many members, it is often desired to group them together. Doxygen already
automatically groups things together on type and protection level, but maybe you feel that this is not enough or that
that default grouping is wrong. For instance, because you feel that members of different (syntactic) types belong to
the same (semantic) group.
Generated by Doxygen
46 Grouping
A member group is dened by a
///@{
...
///@}
block or a
/
**
@{
*
/
...
/
**
@}
*
/
block if you prefer C style comments. Note that the members of the group should be physically inside the member
groups body.
Before the opening marker of a block a separate comment block may be placed. This block should contain the
@name (or \name) command and is used to specify the header of the group. Optionally, the comment block may
also contain more detailed information about the group.
Nesting of member groups is not allowed.
If all members of a member group inside a class have the same type and protection level (for instance all are static
public members), then the whole member group is displayed as a subgroup of the type/protection level group (the
group is displayed as a subsection of the "Static Public Members" section for instance). If two or more members
have different types, then the group is put at the same level as the automatically generated groups. If you want
to force all member-groups of a class to be at the top level, you should put a \nosubgrouping command inside the
documentation of the class.
Example:
/
**
A class. Details
*
/
class Test
{
public:
//@{
/
**
Same documentation for both members. Details
*
/
void func1InGroup1();
void func2InGroup1();
//@}
/
**
Function without group. Details.
*
/
void ungroupedFunction();
void func1InGroup2();
protected:
void func2InGroup2();
};
void Test::func1InGroup1() {}
void Test::func2InGroup1() {}
/
**
@name Group2
*
Description of group 2.
*
/
///@{
/
**
Function 2 in group 2. Details.
*
/
void Test::func2InGroup2() {}
/
**
Function 1 in group 2. Details.
*
/
void Test::func1InGroup2() {}
///@}
/
*
! \file
*
docs for this file
*
/
//!@{
//! one description for all members of this group
//! (because DISTRIBUTE_GROUP_DOC is YES in the config file)
#define A 1
#define B 2
void glob_func();
//!@}
Generated by Doxygen
7.3 Subpaging 47
Here Group1 is displayed as a subsection of the "Public Members". And Group2 is a separate section because it
contains members with different protection levels (i.e. public and protected).
7.3 Subpaging
Information can be grouped into pages using the \page and \mainpage commands. Normally, this results in a at
list of pages, where the "main" page is the rst in the list.
Instead of adding structure using the approach described in section modules it is often more natural and convenient
to add additional structure to the pages using the \subpage command.
For a page A the \subpage command adds a link to another page B and at the same time makes page B a subpage
of A. This has the effect of making two groups GA and GB, where GB is part of GA, page A is put in group GA, and
page B is put in group GB.
Generated by Doxygen
48 Grouping
Generated by Doxygen
Chapter 8
Including Formulas
Doxygen allows you to put L
A
T
E
X formulas in the output (this works only for the HTML and L
A
T
E
X output, not for the
RTF nor 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
latex: the L
A
T
E
X compiler, needed to parse the formulas. To test I have used the teTeX 1.0 distribution.
dvips: a tool to convert DVI les to PostScript les I have used version 5.92b from Radical Eye software
for testing.
gs: the GhostScript interpreter for converting PostScript les to bitmaps. I have used Aladdin GhostScript
8.0 for testing.
For the HTML output there is also an alternative solution using MathJax which does not require the above tools.
If you enable USE_MATHJAX in the cong then the latex formulas will be copied to the HTML "as is" and a client
side javascript will parse them and turn them into (interactive) images.
There are three 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 (x
1
, y
1
) and (x
2
, y
2
) is
(x
2
x
1
)
2
+(y
2
y
1
)
2
.
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:
[I
2
[ =
T
0
(t)
u(a, t)
a
(t)
d
k(, t)
a
c()u
t
(, t)d
dt
3. Formulas or other latex elements that are not in a math environment can be specied using \f{environment},
where environment is the name of the L
A
T
E
X environment, the corresponding end command is \f}. Here is
an example for an equation array
50 Including Formulas
\f{eqnarray
*
}{
g &=& \frac{Gm_2}{r^2} \\
&=& \frac{(6.673 \times 10^{-11}\,\mbox{m}^3\,\mbox{kg}^{-1}\,
\mbox{s}^{-2})(5.9736 \times 10^{24}\,\mbox{kg})}{(6371.01\,\mbox{km})^2} \\
&=& 9.82066032\,\mbox{m/s}^2
\f}
which results in:
g =
Gm
2
r
2
=
(6.67310
11
m
3
kg
1
s
2
)(5.973610
24
kg)
(6371.01km)
2
= 9.82066032m/s
2
For the rst two commands one should make sure formulas contain valid commands in L
A
T
E
Xs math-mode. For the
third command the section should contain valid command for the specic environment.
Warning
Currently, doxygen is not very fault tolerant in recovering from typos in formulas. It may be necessary to remove
the le formula.repository that is written to the html directory to get rid of an incorrect formula.
Generated by Doxygen
Chapter 9
Graphs and diagrams
Doxygen has built-in support to generate inheritance diagrams for C++ classes.
Doxygen can use the "dot" tool from graphviz to generate more advanced diagrams and graphs. Graphviz is an
open-source, cross-platform graph drawing toolkit and can be found at http://www.graphviz.org/
If you have the "dot" tool in the path, you can set HAVE_DOT to YES in the conguration le to let doxygen use it.
Doxygen uses the "dot" tool to generate the following graphs:
A graphical representation of the class hierarchy will be drawn, along with the textual one. Currently this
feature is supported for HTML only.
Warning: When you have a very large class hierarchy where many classes derive from a common base
class, the resulting image may become too big to handle for some browsers.
An inheritance graph will be generated for each documented class showing the direct and indirect inheritance
relations. This disables the generation of the built-in class inheritance diagrams.
An include dependency graph is generated for each documented le that includes at least one other le. This
feature is currently supported for HTML and RTF only.
An inverse include dependency graph is also generated showing for a (header) le, which other les include
it.
A graph is drawn for each documented class and struct that shows:
the inheritance relations with base classes.
the usage relations with other structs and classes (e.g. class A has a member variable m_a of type
class B, then A has an arrow to B with m_a as label).
if CALL_GRAPH is set to YES, a graphical call graph is drawn for each function showing the functions that
the function directly or indirectly calls.
if CALLER_GRAPH is set to YES, a graphical caller graph is drawn for each function showing the functions
that the function is directly or indirectly called by.
Using a layout le you can determine which of the graphs are actually shown.
The options DOT_GRAPH_MAX_NODES and MAX_DOT_GRAPH_DEPTH can be used to limit the size of the
various graphs.
The elements in the class diagrams in HTML and RTF have the following meaning:
A yellow box indicates a class. A box can have a little marker in the lower right corner to indicate that the
class contains base classes that are hidden. For the class diagrams the maximum tree width is currently 8
elements. If a tree is wider some nodes will be hidden. If the box is lled with a dashed pattern the inheritance
relation is virtual.
52 Graphs and diagrams
A white box indicates that the documentation of the class is currently shown.
A gray box indicates an undocumented class.
A solid dark blue arrow indicates public inheritance.
A dashed dark green arrow indicates protected inheritance.
A dotted dark green arrow indicates private inheritance.
The elements in the class diagram in L
A
T
E
X have the following meaning:
A white box indicates a class. A marker in the lower right corner of the box indicates that the class has base
classes that are hidden. If the box has a dashed border this indicates virtual inheritance.
A solid arrow indicates public inheritance.
A dashed arrow indicates protected inheritance.
A dotted arrow indicates private inheritance.
The elements in the graphs generated by the dot tool have the following meaning:
A white box indicates a class or struct or le.
A box with a red border indicates a node that has more arrows than are shown! In other words: the graph
is truncated with respect to this node. The reason why a graph is sometimes truncated is to prevent images
from becoming too large. For the graphs generated with dot doxygen tries to limit the width of the resulting
image to 1024 pixels.
A black box indicates that the class documentation is currently shown.
A dark blue arrow indicates an include relation (for the include dependency graph) or public inheritance (for
the other graphs).
A dark green arrow indicates protected inheritance.
A dark red arrow indicates private inheritance.
A purple dashed arrow indicated a "usage" relation, the edge of the arrow is labeled with the variable(s)
responsible for the relation. Class A uses class B, if class A has a member variable m of type C, where B is a
subtype of C (e.g. C could be B, B, T<B>).
Here are a couple of header les that together show the various diagrams that doxygen can generate:
diagrams_a.h
#ifndef _DIAGRAMS_A_H
#define _DIAGRAMS_A_H
class A { public: A
*
m_self; };
#endif
diagrams_b.h
#ifndef _DIAGRAMS_B_H
#define _DIAGRAMS_B_H
class A;
class B { public: A
*
m_a; };
#endif
diagrams_c.h
#ifndef _DIAGRAMS_C_H
#define _DIAGRAMS_C_H
#include "diagrams_c.h"
class D;
class C : public A { public: D
*
m_d; };
#endif
Generated by Doxygen
53
diagrams_d.h
#ifndef _DIAGRAM_D_H
#define _DIAGRAM_D_H
#include "diagrams_a.h"
#include "diagrams_b.h"
class C;
class D : virtual protected A, private B { public: C m_c; };
#endif
diagrams_e.h
#ifndef _DIAGRAM_E_H
#define _DIAGRAM_E_H
#include "diagrams_d.h"
class E : public D {};
#endif
Generated by Doxygen
54 Graphs and diagrams
Generated by Doxygen
Chapter 10
Preprocessing
Source les that are used as input to doxygen can be parsed by doxygens built-in C-preprocessor.
By default doxygen does only partial preprocessing. That is, it evaluates conditional compilation statements (like
#if) and evaluates macro denitions, 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 = "2.xx";
You can disable all preprocessing by setting ENABLE_PREPROCESSING to NO in the conguration le. In the
case above doxygen will then read both statements, i.e.:
static CONST_STRING version = "2.xx";
static CONST_STRING version = "1.xx";
In case you want to expand the CONST_STRING macro, you should set the MACRO_EXPANSION tag in the
cong le 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 denitions (recursively if needed). This is often too much. Therefore,
doxygen also allows you to expand only those denes that you explicitly specify. For this you have to set the
EXPAND_ONLY_PREDEF tag to YES and specify the macro denitions after the PREDEFINED or EXPAND_A
S_DEFINED tag.
A typically example where some help from the preprocessor is needed is when dealing with the language extension
from Microsoft: __declspec. The same goes for GNUs __attribute__ extension. Here is an example
function.
extern "C" void __declspec(dllexport) ErrorMsg( String aMessage,...);
56 Preprocessing
When nothing is done, doxygen will be confused and see __declspec as some sort of function. To help doxygen
one typically uses the following preprocessor settings:
ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = YES
EXPAND_ONLY_PREDEF = YES
PREDEFINED = __declspec(x)=
This will make sure the __declspec(dllexport) is removed before doxygen parses the source code.
Similar settings can be used for removing __attribute__ expressions from the input:
ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = YES
EXPAND_ONLY_PREDEF = YES
PREDEFINED = __attribute__(x)=
For a more complex example, suppose you have the following obfuscated 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 cong le:
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 doxygens 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 denitions (like DECLARE_INTERFACE ), normal
macro substitutions (like PURE and THIS) and plain denes (like __cplusplus).
Generated by Doxygen
57
Note also that preprocessor denitions that are normally dened automatically by the preprocessor (like __
cplusplus), have to be dened by hand with doxygens parser (this is done because these denes are often
platform/compiler specic).
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 denition for class QList is to dene:
PREDEFINED = QListT:=QList
Here is an example provided by Valter Minute and Reyes Ponce that helps doxygen to wade through the boilerplate
code in Microsofts ATL & MFC libraries:
PREDEFINED = "DECLARE_INTERFACE(name)=class name" \
"STDMETHOD(result,name)=virtual result name" \
"PURE= = 0" \
THIS_= \
THIS= \
DECLARE_REGISTRY_RESOURCEID=// \
DECLARE_PROTECT_FINAL_CONSTRUCT=// \
"DECLARE_AGGREGATABLE(Class)= " \
"DECLARE_REGISTRY_RESOURCEID(Id)= " \
DECLARE_MESSAGE_MAP= \
BEGIN_MESSAGE_MAP=/
*
\
END_MESSAGE_MAP=
*
/// \
BEGIN_COM_MAP=/
*
\
END_COM_MAP=
*
/// \
BEGIN_PROP_MAP=/
*
\
END_PROP_MAP=
*
/// \
BEGIN_MSG_MAP=/
*
\
END_MSG_MAP=
*
/// \
BEGIN_PROPERTY_MAP=/
*
\
END_PROPERTY_MAP=
*
/// \
BEGIN_OBJECT_MAP=/
*
\
END_OBJECT_MAP()=
*
/// \
DECLARE_VIEW_STATUS=// \
"STDMETHOD(a)=HRESULT a" \
"ATL_NO_VTABLE= " \
"__declspec(a)= " \
BEGIN_CONNECTION_POINT_MAP=/
*
\
END_CONNECTION_POINT_MAP=
*
/// \
"DECLARE_DYNAMIC(class)= " \
"IMPLEMENT_DYNAMIC(class1, class2)= " \
"DECLARE_DYNCREATE(class)= " \
"IMPLEMENT_DYNCREATE(class1, class2)= " \
"IMPLEMENT_SERIAL(class1, class2, class3)= " \
"DECLARE_MESSAGE_MAP()= " \
TRY=try \
"CATCH_ALL(e)= catch(...)" \
END_CATCH_ALL= \
"THROW_LAST()= throw"\
"RUNTIME_CLASS(class)=class" \
"MAKEINTRESOURCE(nId)=nId" \
"IMPLEMENT_REGISTER(v, w, x, y, z)= " \
"ASSERT(x)=assert(x)" \
"ASSERT_VALID(x)=assert(x)" \
"TRACE0(x)=printf(x)" \
"OS_ERR(A,B)={ #A, B }" \
__cplusplus \
"DECLARE_OLECREATE(class)= " \
"BEGIN_DISPATCH_MAP(class1, class2)= " \
"BEGIN_INTERFACE_MAP(class1, class2)= " \
"INTERFACE_PART(class, id, name)= " \
Generated by Doxygen
58 Preprocessing
"END_INTERFACE_MAP()=" \
"DISP_FUNCTION(class, name, function, result, id)=" \
"END_DISPATCH_MAP()=" \
"IMPLEMENT_OLECREATE2(class, name, id1, id2, id3, id4,\
id5, id6, id7, id8, id9, id10, id11)="
As you can see doxygens preprocessor is quite powerful, but if you want even more exibility you can always write
an input lter and specify it after the INPUT_FILTER tag.
If you are unsure what the effect of doxygens preprocessing will be you can run doxygen as follows:
doxygen -d Preprocessor
This will instruct doxygen to dump the input sources to standard output after preprocessing has been done (Hint:
set QUIET = YES and WARNINGS = NO in the conguration le to disable any other output).
Generated by Doxygen
Chapter 11
Automatic link generation
Most documentation systems have special see also sections where links to other pieces of documentation can be
inserted. Although doxygen also has a command to start such a section (See section \sa), it does allow you to
put these kind of links anywhere in the documentation. For L
A
T
E
X documentation a reference to the page number
is written instead of a link. Furthermore, the index at the end of the document can be used to quickly nd the
documentation of a member, class, namespace or le. For man pages no reference information is generated.
The next sections show how to generate links to the various documented entities in a source le.
11.1 Links to web pages and mail addresses
Doxygen will automatically replace any URLs and mail addresses found in the documentation by links (in HTML).
To manually specify link text, use the HTML a tag:
<a href="linkURL">link text</a>
which will be automatically translated to other output formats by Doxygen.
11.2 Links to classes
All words in the documentation that correspond to a documented class and contain at least one non-lower case
character will automatically be replaced by a link to the page containing the documentation of the class. If you want
to prevent that a word that corresponds to a documented class is replaced by a link you should put a % in front of
the word. To link to an all lower case symbol, use \ref.
11.3 Links to les
All words that contain a dot (.) that is not the last character in the word are considered to be le names. If the word
is indeed the name of a documented input le, a link will automatically be created to the documentation of that le.
11.4 Links to functions
Links to functions are created if one of the following patterns is encountered:
1. <functionName>"("<argument-list>")"
2. <functionName>"()"
60 Automatic link generation
3. "::"<functionName>
4. (<className>"::")
n
<functionName>"("<argument-list>")"
5. (<className>"::")
n
<functionName>"("<argument-list>")"<modifiers>
6. (<className>"::")
n
<functionName>"()"
7. (<className>"::")
n
<functionName>
where n>0.
Note 1:
Function arguments should be specied with correct types, i.e. fun(const std::string&,bool) or () to match any
prototype.
Note 2:
Member function modiers (like const and volatile) are required to identify the target, i.e. func(int) const and
fun(int) target different member functions.
Note 3:
For JavaDoc compatibility a # may be used instead of a :: in the patterns above.
Note 4:
In the documentation of a class containing a member foo, a reference to a global variable is made using "::foo",
whereas #foo will link to the member.
For non overloaded members the argument list may be omitted.
If a function is overloaded and no matching argument list is specied (i.e. pattern 2 or 6 is used), a link will be
created to the documentation of one of the overloaded members.
For member functions the class scope (as used in patterns 4 to 7) may be omitted, if:
1. The pattern points to a documented member that belongs to the same class as the documentation block that
contains the pattern.
2. The class that corresponds to the documentation blocks that contains the pattern has a base class that
contains a documented member that matches the pattern.
11.5 Links to other members
All of these entities can be linked to in the same way as described in the previous section. For sake of clarity it is
advised to only use patterns 3 and 7 in this case.
Example:
/
*
! \file autolink.cpp
Testing automatic link generation.
A link to a member of the Test class: Test::member,
More specific links to the each of the overloaded members:
Test::member(int) and Test#member(int,int)
A link to a protected member variable of Test: Test#var,
A link to the global enumeration type #GlobEnum.
A link to the define #ABS(x).
Generated by Doxygen
11.5 Links to other members 61
A link to the destructor of the Test class: Test::~Test,
A link to the typedef ::B.
A link to the enumeration type Test::EType
A link to some enumeration values Test::Val1 and ::GVal2
*
/
/
*
!
Since this documentation block belongs to the class Test no link to
Test is generated.
Two ways to link to a constructor are: #Test and Test().
Links to the destructor are: #~Test and ~Test().
A link to a member in this class: member().
More specific links to the each of the overloaded members:
member(int) and member(int,int).
A link to the variable #var.
A link to the global typedef ::B.
A link to the global enumeration type #GlobEnum.
A link to the define ABS(x).
A link to a variable \link #var using another text\endlink as a link.
A link to the enumeration type #EType.
A link to some enumeration values: \link Test::Val1 Val1 \endlink and ::GVal1.
And last but not least a link to a file: autolink.cpp.
\sa Inside a see also section any word is checked, so EType,
Val1, GVal1, ~Test and member will be replaced by links in HTML.
*
/
class Test
{
public:
Test(); //!< constructor
~Test(); //!< destructor
void member(int); /
**
< A member function. Details.
*
/
void member(int,int); /
**
< An overloaded member function. Details
*
/
/
**
An enum type. More details
*
/
enum EType {
Val1, /
**
< enum value 1
*
/
Val2 /
**
< enum value 2
*
/
};
protected:
int var; /
**
< A member variable
*
/
};
/
*
! details.
*
/
Test::Test() { }
/
*
! details.
*
/
Test::~Test() { }
/
*
! A global variable.
*
/
int globVar;
/
*
! A global enum.
*
/
enum GlobEnum {
GVal1, /
*
!< global enum value 1
*
/
Generated by Doxygen
62 Automatic link generation
GVal2 /
*
!< global enum value 2
*
/
};
/
*
!
*
A macro definition.
*
/
#define ABS(x) (((x)>0)?(x):-(x))
typedef Test B;
/
*
! \fn typedef Test B
*
A type definition.
*
/
11.6 typedefs
Typedefs that involve classes, structs and unions, like
typedef struct StructName TypeName
create an alias for StructName, so links will be generated to StructName, when either StructName itself or Type
Name is encountered.
Example:
/
*
! \file restypedef.cpp
*
An example of resolving typedefs.
*
/
/
*
! \struct CoordStruct
*
A coordinate pair.
*
/
struct CoordStruct
{
/
*
! The x coordinate
*
/
float x;
/
*
! The y coordinate
*
/
float y;
};
/
*
! Creates a type name for CoordStruct
*
/
typedef CoordStruct Coord;
/
*
!
*
This function returns the addition of \a c1 and \a c2, i.e:
*
(c1.x+c2.x,c1.y+c2.y)
*
/
Coord add(Coord c1,Coord c2)
{
}
Generated by Doxygen
Chapter 12
Output Formats
The following output formats are directly supported by doxygen:
HTML Generated if GENERATE_HTML is set to YES in the conguration le.
L
A
T
E
X Generated if GENERATE_LATEX is set to YES in the conguration le.
Man pages Generated if GENERATE_MAN is set to YES in the conguration le.
RTF Generated if GENERATE_RTF is set to YES in the conguration le.
Note that the RTF output probably only looks nice with Microsofts Word. If you have success with other
programs, please let me know.
XML Generated if GENERATE_XML is set to YES in the conguration le.
Docbook Generated if GENERATE_DOCBOOOK is set to YES in the conguration le.
The following output formats are indirectly supported by doxygen:
Compiled HTML Help (a.k.a. Windows 98 help) Generated by Microsofts HTML Help workshop from the HTML
output if GENERATE_HTMLHELP is set to YES.
Qt Compressed Help (.qch) Generated by Qts qhelpgenerator tool from the HTML output if GENERATE_QHP
is set to YES.
Eclipse Help Generated from HTML with a special index le that is generated when GENERATE_ECLIPSEHELP
is set to YES.
XCode DocSets Compiled from HTML with a special index le that is generated when GENERATE_DOCSET is
set to YES.
PostScript Generated from the L
A
T
E
X output by running make ps in the output directory. For the best results
PDF_HYPERLINKS should be set to NO.
PDF Generated from the L
A
T
E
X output by running make pdf in the output directory. To improve the PDF out-
put, you typically would want to enable the use of pdflatex by setting USE_PDFLATEX to YES in the
conguration le. In order to get hyperlinks in the PDF le you also need to enable PDF_HYPERLINKS.
64 Output Formats
Generated by Doxygen
Chapter 13
Searching
Doxygen indexes your source code in various ways to make it easier to navigate and nd what you are looking for.
There are also situations however where you want to search for something by keyword rather than browse for it.
HTML browsers by default have no search capabilities that work across multiple pages, so either doxygen or external
tools need to help to facilitate this feature.
Doxygen has 7 different ways to add searching to the HTML output, each of which has its own advantages and
disadvantages:
1. Client side searching
The easiest way to enable searching is to enable the built-in client side search engine. This engine is implemented
using Javascript and DHTML only and runs entirely on the clients browser. So no additional tooling is required to
make it work.
To enable it set SEARCHENGINE to YES in the cong le and make sure SERVER_BASED_SEARCH is set to NO.
An additional advantage of this method is that it provides live searching, i.e. the search results are presented and
adapted as you type.
This method also has its drawbacks: it is limited to searching for symbols only. It does not provide full text search
capabilities, and it does not scale well to very large projects (then searching becomes very slow).
2. Server side searching
If you plan to put the HTML documentation on a web server, and that web server has the capability to process PHP
code, then you can also use doxygens built-in server side search engine.
To enable this set both SEARCHENGINE and SERVER_BASED_SEARCH to YES in the cong le and set EXT
ERNAL_SEARCH to NO.
Advantages over the client side search engine are that it provides full text search and it scales well to medium side
projects.
Disadvantages are that it does not work locally (i.e. using a "le://" URL) and that it does not provide live search
capabilities.
66 Searching
Note
In the future this option will probably be replaced by the next search option.
3. Server side searching with external indexing
With release 1.8.3 of doxygen, another server based search option has been added. With this option doxygen
generates the raw data that can be searched and leaves it up to external tools to do the indexing and searching,
meaning that you could use your own indexer and search engine of choice. To make life easier doxygen ships with
an example indexer (doxyindexer) and search engine (doxysearch.cgi) based on the Xapian open source search
engine library.
To enable this search method set SEARCHENGINE, SERVER_BASED_SEARCH and EXTERNAL_SEARCH all to
YES.
See External Indexing and Searching for conguration details.
Advantages over option 2 are that this method (potentially) scales to very large projects. It is also possible to
combine multiple doxygen projects and external data into one search index. The way the interaction with the search
engine is done, makes it possible to search from local HTML pages. Also the search results have better ranking
and show context information (if available).
Disadvantages are that is requires a web server that can execute a CGI binary, and an additional indexing step after
running doxygen.
4. Windows Compiled HTML Help
If you are running doxygen on Windows, then you can make a compiled HTML Help le (.chm) out of the HTML les
produced by doxygen. This is a single le containing all HTML les and it also includes a search index. There are
viewers for this format on many platforms, and Windows even supports it natively.
To enable this set GENERATE_HTMLHELP to YES in the cong le. To let doxygen compile the HTML Help le
for you, you also need to specify the path to the HTML compiler (hhc.exe) using the HHC_LOCATION cong option
and the name of the resulting CHM le using CHM_FILE.
An advantage of this method is that the result is a single le that can easily be distributed. It also provides full text
search.
Disadvantages are that compiling the CHM le only works on Windows and requires Microsofts HTML compiler,
which is not very actively supported by Microsoft. Although the tool works ne for most people, it can sometimes
crash for no apparent reason (how typical).
5. Mac OS X Doc Sets
If you are running doxygen on Mac OS X 10.5 or higher, then you can make a "doc set" out of the HTML les
produced by doxygen. A doc set consists of a single directory with a special structure containing the HTM
L les along with a precompiled search index. A doc set can be embedded in Xcode (the integrated development
environment provided by Apple).
To enable the creation of doc sets set GENERATE_DOCSET to YES in the cong le. There are a couple of other
doc set related options you may want to set. After doxygen has nished you will nd a Makele in the HTML output
directory. Running "make install" on this Makele will compile and install the doc set. See this article for
more info.
Advantage of this method is that it nicely integrates with the Xcode development environment, allowing for instance
to click on an identier in the editor and jump to the corresponding section in the doxygen documentation.
Disadvantage is that it only works in combination with Xcode on MacOSX.
Generated by Doxygen
13.1 External Indexing and Searching 67
6. Qt Compressed Help
If you develop for or want to install the Qt application framework, you will get an application called Qt assistant.
This is a help viewer for Qt Compressed Help les (.qch).
To enable this feature set GENERATE_QHP to YES. You also need to ll in the other Qt help related options, such
as QHP_NAMESPACE, QHG_LOCATION, QHP_VIRTUAL_FOLDER. See this article for more info.
Feature wise the Qt compressed help feature is comparable with the CHM output, with the additional advantage
that compiling the QCH le is not limited to Windows.
Disadvantage is that it requires setting up a Qt 4.5 (or better) for each user, or distributing the Qt help assistant
along with the documentation, which is complicated by the fact that it is not available as a separate package at this
moment.
7. Eclipse Help Plugin
If you use eclipse, you can embed the documentation generated by doxygen as a help plugin. It will then appear
as a topic in the help browser that can be started from "Help contents" in the Help menu. Eclipse will generate a
search index for the documentation when you rst search for a keyword.
To enable the help plugin set GENERATE_ECLIPSEHELP to YES, and dene a unique identier for your project
via ECLIPSE_DOC_ID, i.e.:
GENERATE_ECLIPSEHELP = YES
ECLIPSE_DOC_ID = com.yourcompany.yourproject
then create the com.yourcompany.yourproject directory (so with the same name as the value of ECLI
PSE_DOC_ID) in the plugin directory of eclipse and after doxygen completes copy to contents of the help output
directory to the com.yourcompany.yourproject directory. Then restart eclipse to make let it nd the new
plugin.
The eclipse help plugin provides similar functionality as the Qt compressed help or CHM output, but it does require
that Eclipse is installed and running.
13.1 External Indexing and Searching
13.1.1 Introduction
With release 1.8.3, doxygen provides the ability to search through HTML using an external indexing tool and search
engine. This has several advantages:
For large projects it can have signicant performance advantages over doxygens built-in search engine, as
doxygen uses a rather simple indexing algorithm.
It allows combining the search data of multiple projects into one index, allowing a global search across multiple
doxygen projects.
It allows adding additional data to the search index, i.e. other web pages not produced by doxygen.
The search engine needs to run on a web server, but clients can still browse the web pages locally.
To avoid that everyone has to start writing their own indexer and search engine, doxygen provides an example tool
for each action: doxyindexer for indexing the data and doxysearch.cgi for searching through the index.
The data ow is shown in the following diagram:
Generated by Doxygen
68 Searching
doxygen
searchdata.xml
writes
doxyindexer
doxysearch.db
writes
doxysearch.cgi
HTML page
in browser
get results query
reads
reads
Figure 13.1: External Search Data Flow
doxygen produces the raw search data
doxyindexer indexes the data into a search database doxysearch.db
when a user performs a search from a doxygen generated HTML page, the CGI binary doxysearch.cgi
will be invoked.
the doxysearch.cgi tool will perform a query on the database and return the results.
The browser will show the search results.
13.1.2 Conguring
The rst step is to make the search engine available via a web server. If you use doxysearch.cgi this means
making the CGI binary available from the web server (i.e. be able to run it from a browser via an URL starting with
http:)
How to setup a web server is outside the scope of this document, but if you for instance have Apache installed, you
could simply copy the doxysearch.cgi le from doxygens bin dir to the cgi-bin of the Apache web server.
Read the apache documentation for details.
To test if doxysearch.cgi is accessible start your web browser and point to URL to the binary and add ?test
at the end
http://yoursite.com/path/to/cgi/doxysearch.cgi?test
You should get the following message:
Test failed: cannot find search index doxysearch.db
If you use Internet Explorer you may be prompted to download a le, which will then contain this message.
Since we didnt create or install a doxysearch.db it is ok for the test to fail for this reason. How to correct this is
discussed in the next section.
Generated by Doxygen
13.1 External Indexing and Searching 69
Before continuing with the next section add the above URL (without the ?test part) to the SEARCHENGINE_URL
tag in doxygens conguration le:
SEARCHENGINE_URL = http://yoursite.com/path/to/cgi/doxysearch.cgi
13.1.2.1 Single project index
To use the external search option, make sure the following options are enabled in doxygens conguration le:
SEARCHENGINE = YES
SERVER_BASED_SEARCH = YES
EXTERNAL_SEARCH = YES
This will make doxygen generate a le called searchdata.xml in the output directory (congured with OUTP
UT_DIRECTORY). You can change the le name (and location) with the SEARCHDATA_FILE option.
The next step is to put the raw search data into an index for efcient searching. You can use doxyindexer for
this. Simply run it from the command line:
doxyindexer searchdata.xml
This will create a directory called doxysearch.db with some les in it. By default the directory will be created at
the location from which doxyindexer was started, but you can change the directory using the -o option.
Copy the doxysearch.db directory to the same directory as where the doxysearch.cgi is located and
rerun the browser test by pointing the browser to
http://yoursite.com/path/to/cgi/doxysearch.cgi?test
You should now get the following message:
Test successful.
Now you should be enable to search for words and symbols from the HTML output.
13.1.2.2 Multi project index
In case you have more than one doxygen project and these projects are related, it may be desirable to allow
searching for words in all projects from within the documentation of any of the projects.
To make this possible all that is needed is to combine the search data for all projects into a single index, e.g. for two
projects A and B for which the searchdata.xml is generated in directories project_A and project_B run:
doxyindexer project_A/searchdata.xml project_B/searchdata.xml
and then copy the resulting doxysearch.db to the directory where also doxysearch.cgi is located.
The searchdata.xml le doesnt contain any absolute paths or links, so how can the search results from
multiple projects be linked back to the right documentation set? This is where the EXTERNAL_SEARCH_ID and
EXTRA_SEARCH_MAPPINGS options come into play.
To be able to identify the different projects, one needs to set a unique ID using EXTERNAL_SEARCH_ID for each
project.
To link the search results to the right project, you need to dene a mapping per project using the EXTRA_SEAR
CH_MAPPINGS tag. With this option to can dene the mapping from IDs of other projects to the (relative) location
of documentation of those projects.
So for projects A and B the relevant part of the conguration le could look as follows:
project_A/Doxyfile
------------------
EXTERNAL_SEARCH_ID = A
EXTRA_SEARCH_MAPPINGS = B=../../project_B/html
Generated by Doxygen
70 Searching
for project A and for project B
project_B/Doxyfile
------------------
EXTERNAL_SEARCH_ID = B
EXTRA_SEARCH_MAPPINGS = A=../../project_A/html
with these settings, projects A and B can share the same search database, and the search results will link to the
right documentation set.
13.1.3 Updating the index
When you modify the source code, you should re-run doxygen to get up to date documentation again. When using
external searching you also need to update the search index by re-running doxyindexer. You could wrap the
call to doxygen and doxyindexer together in a script to make this process easier.
13.1.4 Programming interface
Previous sections have assumed you use the tools doxyindexer and doxysearch.cgi to do the indexing
and searching, but you could also write your own index and search tools if you like.
For this 3 interfaces are important
The format of the input for the index tool.
The format of the input for the search engine.
The format of the output of search engine.
The next subsections describe these interfaces in more detail.
13.1.4.1 Indexer input format
The search data produced by doxygen follows the Solr XML index message format.
The input for the indexer is an XML le, which consists of one <add> tag containing multiple <doc> tags, which
in turn contain multiple <field> tags.
Here is an example of one doc node, which contains the search data and meta data for one method:
<add>
...
<doc>
<field name="type">function</field>
<field name="name">QXmlReader::setDTDHandler</field>
<field name="args">(QXmlDTDHandler
*
handler)=0</field>
<field name="tag">qtools.tag</field>
<field name="url">de/df6/class_q_xml_reader.html#a0b24b1fe26a4c32a8032d68ee14d5dba</field>
<field name="keywords">setDTDHandler QXmlReader::setDTDHandler QXmlReader</field>
<field name="text">Sets the DTD handler to handler DTDHandler()</field>
</doc>
...
</add>
Each eld has a name. The following eld names are supported:
type: the type of the search entry; can be one of: source, function, slot, signal, variable, typedef, enum,
enumvalue, property, event, related, friend, dene, le, namespace, group, package, page, dir
name: the name of the search entry; for a method this is the qualied name of the method, for a class it is the
name of the class, etc.
Generated by Doxygen
13.1 External Indexing and Searching 71
args: the parameter list (in case of functions or methods)
tag: the name of the tag le used for this project.
url: the (relative) URL to the HTML documentation for this entry.
keywords: important words that are representative for the entry. When searching for such keyword, this entry
should get a higher rank in the search results.
text: the documentation associated with the item. Note that only words are present, no markup.
Note
Due to the potentially large size of the XML le, it is recommended to use a SAX based parser to process
it.
13.1.4.2 Search URL format
When the search engine is invoked from a doxygen generated HTML page, a number of parameters are passed to
via the query string.
The following elds are passed:
q: the query text as entered by the user
n: the number of search results requested.
p: the number of search page for which to return the results. Each page has n values.
cb: the name of the callback function, used for JSON with padding, see the next section.
From the complete list of search results, the range [np - n(p+1)-1] should be returned.
Here is an example of how a query looks like.
http://yoursite.com/path/to/cgi/doxysearch.cgi?q=list&n=20&p=1&cb=dummy
It represents a query for the word list (q=list) requesting 20 search results (n=20), starting with the result
number 20 (p=1) and using callback dummy (cb=dummy):
Note
The values are URL encoded so they have to be decoded before they can be used.
13.1.4.3 Search results format
When invoking the search engine as shown in the previous subsection, it should reply with the results. The format
of the reply is JSON with padding, which is basically a javascript struct wrapped in a function call. The name
of function should be the name of the callback (as passed with the cb eld in the query).
With the example query as shown the previous subsection the main structure of the reply should look as follows:
dummy({
"hits":179,
"first":20,
"count":20,
"page":1,
"pages":9,
"query": "list",
"items":[
...
]})
The elds have the following meaning:
Generated by Doxygen
72 Searching
hits: the total number of search results (could be more than was requested).
rst: the index of rst result returned: min(n p, hits).
count: the actual number of results returned: min(n, hits rst)
page: the page number of the result: p
pages: the total number of pages: ,
hits
n
|.
items: an array containing the search data per result.
Here is an example of how the element of the items array should look like:
{"type": "function",
"name": "QDir::entryInfoList(const QString &nameFilter, int filterSpec=DefaultFilter, int sortSpec=DefaultSort) const",
"tag": "qtools.tag",
"url": "d5/d8d/class_q_dir.html#a9439ea6b331957f38dbad981c4d050ef",
"fragments":[
"Returns a <span class=\"hl\">list</span> of QFileInfo objects for all files and directories...",
"... pointer to a QFileInfoList The <span class=\"hl\">list</span> is owned by the QDir object...",
"... to keep the entries of the <span class=\"hl\">list</span> after a subsequent call to this..."
]
},
The elds for such an item have the following meaning:
type: the type of the item, as found in the eld with name "type" in the raw search data.
name: the name of the item, including the parameter list, as found in the elds with name "name" and "args"
in the raw search data.
tag: the name of the tag le, as found in the eld with name "tag" in the raw search data.
url: the name of the (relative) URL to the documentation, as found in the eld with name "url" in the raw
search data.
"fragments": an array with 0 or more fragments of text containing words that have been search for. These
words should be wrapped in <span class="hl"> and </span> tags to highlight them in the output.
Generated by Doxygen
Chapter 14
Customizing the Output
Doxygen provides various levels of customization. The section Minor Tweaks discusses what to do if you want to
do minor tweaking to the look and feel of the output. The section Layout show how to reorder and hide certain
information on a page. The section XML output show how to generate whatever output you want based on the XML
output produced by doxygen.
14.1 Minor Tweaks
The next subsections describe some aspects that can be tweaked with little effort.
14.1.1 Overall Color
To change the overall color of the HTML output doxygen provides three options
HTML_COLORSTYLE_HUE
HTML_COLORSTYLE_SAT
HTML_COLORSTYLE_GAMMA
to change the hue, saturation, and gamma correction of the colors respectively.
For your convenience the GUI frontend Doxywizard has a control that allows you to see the effect of changing the
values of these options on the output in real time.
14.1.2 Navigation
By default doxygen shows navigation tabs on top of every HTML page, corresponding with the following settings:
DISABLE_INDEX = NO
GENERATE_TREEVIEW = NO
you can switch to an interactive navigation tree as sidebar using
DISABLE_INDEX = YES
GENERATE_TREEVIEW = YES
or even have both forms of navigation:
74 Customizing the Output
DISABLE_INDEX = NO
GENERATE_TREEVIEW = YES
if you already use an external index (i.e. have one of the following options enabled GENERATE_HTMLHELP, GE
NERATE_ECLIPSEHELP, GENERATE_QHP, or GENERATE_DOCSET) then you can also disable all indices, like
so:
DISABLE_INDEX = YES
GENERATE_TREEVIEW = NO
14.1.3 Dynamic Content
To make the HTML output more interactive, doxygen provides a number of options that are disabled by default:
enabling HTML_DYNAMIC_SECTIONS will make doxygen hide certain content (like graphs) in the HTML by
default, and let the reader expand these sections on request.
enabling HAVE_DOT along with INTERACTIVE_SVG while setting DOT_IMAGE_FORMAT to svg, will
make doxygen produce SVG images that will allow the user to zoom and pan (this only happens when the
size of the images exceeds a certain size).
14.1.4 Header, Footer, and Stylesheet changes
To tweak things like fonts or colors, margins, or other look & feel aspects of the HTML output in detail, you can
create a different cascading style sheet. You can also let doxygen use a custom header and footer for
each HTML page it generates, for instance to make the output conform to the style used on the rest of your web
site.
To do this rst run doxygen as follows:
doxygen -w html header.html footer.html customdoxygen.css
This will create 3 les:
header.html is a HTML fragment which doxygen normally uses to start a HTML page. Note that the fragment
ends with a body tag and that is contains a couple of commands of the form $word. These will be replaced
by doxygen on the y.
footer.html is a HTML fragment which doxygen normally uses to end a HTML page. Also here special com-
mands can be used. This le contain the link to www.doxygen.org and the body and html end tags.
customdoxygen.css is the default cascading style sheet used by doxygen. It is recommended only to look
into this le and overrule some settings you like by putting them in a separate stylesheets and referencing
those extra les via HTML_EXTRA_STYLESHEET.
You should edit these les and then reference them from the cong le.
HTML_HEADER = header.html
HTML_FOOTER = footer.html
HTML_STYLESHEET = customdoxygen.css obsolete
Generated by Doxygen
14.2 Changing the layout of pages 75
Note
it is not longer recommended to use HTML_STYLESHEET this way, as it make it difcult to upgrade to a newer
version of doxygen. Use HTML_EXTRA_STYLESHEET instead.
See the documentation of the HTML_HEADER tag for more information about the possible meta commands you
can use inside your custom header.
Note
You should not put the style sheet in the HTML output directory. Treat it as a source le. Doxygen will copy it
for you.
If you use images or other external content in a custom header you need to make sure these end up in the
HTML output directory yourself, for instance by writing a script that runs doxygen can then copies the images
to the output.
Warning
The structure of headers and footers may change after upgrading to a newer version of doxygen, so if you are
using a custom header or footer, it might not produce valid output anymore after upgrading.
14.2 Changing the layout of pages
In some cases you may want to change the way the output is structured. A different style sheet or custom headers
and footers do not help in such case.
The solution doxygen provides is a layout le, which you can modify and doxygen will use to control what information
is presented, in which order, and to some extent also how information is presented. The layout le is an XML le.
The default layout can be generated by doxygen using the following command:
doxygen -l
optionally the name of the layout le can be specied, if omitted DoxygenLayout.xml will be used.
The next step is to mention the layout le in the cong le
LAYOUT_FILE = DoxygenLayout.xml
To change the layout all you need to do is edit the layout le.
The toplevel structure of the le looks as follows:
<doxygenlayout version="1.0">
<navindex>
...
</navindex>
<class>
...
</class>
<namespace>
...
</namespace>
<file>
...
</file>
<group>
...
</group>
<directory>
...
</directory>
</doxygenlayout>
Generated by Doxygen
76 Customizing the Output
The root element of the XML le is doxygenlayout, it has an attribute named version, which will be used in
the future to cope with changes that are not backward compatible.
The rst section, identied by the navindex element, represents the layout of the navigation tabs displayed at the
top of each HTML page. At the same time it also controls the items in the navigation tree in case GENERATE_T
REEVIEW is enabled. Each tab is represented by a tab element in the XML le.
You can hide tabs by setting the visible attribute to no. You can also override the default title of a tab by
specifying it as the value of the title attribute. If the title eld is the empty string (the default) then doxygen will
ll in an appropriate language specic title.
You can reorder the tabs by moving the tab elements in the XML le within the navindex element and even
change the tree structure. Do not change the value of the type attribute however. Only a xed set of types are
supported, each representing a link to a specic index.
You can also add custom tabs using a type with name "user". Here is an example that shows how to add a tab with
title "Google" pointing to www.google.com:
<navindex>
...
<tab type="user" url="http://www.google.com" title="Google"/>
...
</navindex>
The url eld can also be a relative URL. If the URL starts with @ref the link will point to a documented entities,
such as a class, a function, a group, or a related page. Suppose we have dened a page using @page with label
mypage, then a tab with label "My Page" to this page would look as follows:
<navindex>
...
<tab type="user" url="@ref mypage" title="My Page"/>
...
</navindex>
You can also group tabs together in a custom group using a tab with type "usergroup". The following example puts
the above tabs in a user dened group with title "My Group":
<navindex>
...
<tab type="usergroup" title="My Group">
<tab type="user" url="http://www.google.com" title="Google"/>
<tab type="user" url="@ref mypage" title="My Page"/>
</tab>
...
</navindex>
Groups can be nested to form a hierarchy.
By default a usergroup entry in the navigation tree is a link to a landing page with the contents of the group. You
can link to a different page using the url attribute just like you can for the <tab> element and prevent any link
using url="[none]", i.e.
<tab type="usergroup" title="Group without link" url="[none]">
...
</tab>
The elements after navindex represent the layout of the different pages generated by doxygen:
The class element represents the layout of all pages generated for documented classes, structs, unions,
and interfaces.
The namespace element represents the layout of all pages generated for documented namespaces (and
also Java packages).
Generated by Doxygen
14.2 Changing the layout of pages 77
The file element represents the layout of all pages generated for documented les.
The group element represents the layout of all pages generated for documented groups (or modules).
The directory element represents the layout of all pages generated for documented directories.
Each XML element within one of the above page elements represents a certain piece of information. Some pieces
can appear in each type of page, others are specic for a certain type of page. Doxygen will list the pieces in the
order in which they appear in the XML le.
The following generic elements are possible for each page:
briefdescription Represents the brief description on a page.
detaileddescription Represents the detailed description on a page.
authorsection Represents the author section of a page (only used for man pages).
memberdecl Represents the quick overview of members on a page (member declarations). This elements has
child elements per type of member list. The possible child elements are not listed in detail in the document,
but the name of the element should be a good indication of the type of members that the element represents.
memberdef Represents the detailed member list on a page (member denition). Like the memberdecl ele-
ment, also this element has a number of possible child elements.
The class page has the following specic elements:
includes Represents the include le needed to obtain the denition for this class.
inheritancegraph Represents the inheritance relations for a class. Note that the CLASS_DIAGRAM option
determines if the inheritance relation is a list of base and derived classes or a graph.
collaborationgraph Represents the collaboration graph for a class.
allmemberslink Represents the link to the list of all members for a class.
usedfiles Represents the list of les from which documentation for the class was extracted.
The le page has the following specic elements:
includes Represents the list of #include statements contained in this le.
includegraph Represents the include dependency graph for the le.
includedbygraph Represents the included by dependency graph for the le.
sourcelink Represents the link to the source code of this le.
The group page has a specic groupgraph element which represents the graph showing the dependencies
between groups.
Similarly, the directory page has a specic directorygraph element which represents the graph showing the
dependencies between the directories based on the #include relations of the les inside the directories.
Some elements have a visible attribute which can be used to hide the fragment from the generated output, by
setting the attributes value to "no". You can also use the value of a conguration option to determine the visibility,
by using its name prexed with a dollar sign, e.g.
...
<includes visible="$SHOW_INCLUDE_FILES"/>
...
This was mainly added for backward compatibility. Note that the visible attribute is just a hint for doxygen. If no
relevant information is available for a certain piece it is omitted even if it is set to yes (i.e. no empty sections are
generated).
Some elements have a title attribute. This attribute can be used to customize the title doxygen will use as a
header for the piece.
Generated by Doxygen
78 Customizing the Output
Warning
at the moment you should not remove elements from the layout le as a way to hide information. Doing so can
cause broken links in the generated output!
14.3 Using the XML output
If the above two methods still do not provide enough exibility, you can also use the XML output produced by
doxygen as a basis to generate the output you like. To do this set GENERATE_XML to YES.
The XML output consists of an index le named index.xml which lists all items extracted by doxygen with
references to the other XML les for details. The structure of the index is described by a schema le index.xsd.
All other XML les are described by the schema le named compound.xsd. If you prefer one big XML le you
can combine the index and the other les using the XSLT le combine.xslt.
You can use any XML parser to parse the le or use the one that can be found in the addon/doxmlparser
directory of doxygen source distribution. Look at addon/doxmlparser/include/doxmlintf.h for the
interface of the parser and in addon/doxmlparser/example for examples.
The advantage of using the doxmlparser is that it will only read the index le into memory and then only those XML
les that you implicitly load via navigating through the index. As a result this works even for very large projects
where reading all XML les as one big DOM tree would not t into memory.
See the Breathe project for an example that uses doxygen XML output from Python to bridge it with the
Sphinx document generator.
Generated by Doxygen
Chapter 15
Custom Commands
Doxygen provides a large number of special commands, XML commands, and HTML commands. that can be used
to enhance or structure the documentation inside a comment block. If you for some reason have a need to dene
new commands you can do so by means of an alias denition.
The denition of an alias should be specied in the conguration le using the ALIASES conguration tag.
15.1 Simple aliases
The simplest form of an alias is a simple substitution of the form
name=value
For example dening the following alias:
ALIASES += sideeffect="\par Side Effects:\n"
will allow you to put the command \sideeffect (or @sideeffect) in the documentation, which will result in
a user-dened paragraph with heading Side Effects:.
Note that you can put \ns in the value part of an alias to insert newlines.
Also note that you can redene existing special commands if you wish.
Some commands, such as \xretem are designed to be used in combination with aliases.
15.2 Aliases with arguments
Aliases can also have one or more arguments. In the alias denition you then need to specify the number of
arguments between curly braces. In the value part of the denition you can place \x markers, where x represents
the argument number starting with 1.
Here is an example of an alias denition with a single argument:
ALIASES += l{1}="\ref \1"
Inside a comment block you can use it as follows
/
**
See \l{SomeClass} for more information.
*
/
which would be the same as writing
/
**
See \ref SomeClass for more information.
*
/
80 Custom Commands
Note that you can overload an alias by a version with multiple arguments, for instance:
ALIASES += l{1}="\ref \1"
ALIASES += l{2}="\ref \1 \"\2\""
Note that the quotes inside the alias denition have to be escaped with a backslash.
With these alias denitions, we can write
/
**
See \l{SomeClass,Some Text} for more information.
*
/
inside the comment block and it will expand to
/
**
See \ref SomeClass "Some Text" for more information.
*
/
where the command with a single argument would still work as shown before.
Aliases can also be expressed in terms of other aliases, e.g. a new command \reminder can be expressed as a
\xretem via an intermediate \xreflist command as follows:
ALIASES += xreflist{3}="\xrefitem \1 \"\2\" \"\3\" "
ALIASES += reminder="\xreflist{reminders,Reminder,Reminders}"
Note that if for aliases with more than one argument a comma is used as a separator, if you want to put a comma
inside the command, you will need to escape it with a backslash, i.e.
\l{SomeClass,Some text\, with an escaped comma}
given the alias denition of \l in the example above.
15.3 Nesting custom command
You can use commands as arguments of aliases, including commands dened using aliases.
As an example consider the following alias denitions
ALIASES += Bold{1}="<b>\1</b>"
ALIASES += Emph{1}="<em>\1</em>"
Inside a comment block you can now use:
/
**
This is a \Bold{bold \Emph{and} Emphasized} text fragment.
*
/
which will expand to
/
**
This is a <b>bold <em>and</em> Emphasized</b> text fragment.
*
/
Generated by Doxygen
Chapter 16
Link to external documentation
If your project depends on external libraries or tools, there are several reasons to not include all sources for these
with every run of doxygen:
Disk space: Some documentation may be available outside of the output directory of doxygen already, for instance
somewhere on the web. You may want to link to these pages instead of generating the documentation in your
local output directory.
Compilation speed: External projects typically have a different update frequency from your own project. It does
not make much sense to let doxygen parse the sources for these external project over and over again, even
if nothing has changed.
Memory: For very large source trees, letting doxygen parse all sources may simply take too much of your systems
memory. By dividing the sources into several "packages", the sources of one package can be parsed by
doxygen, while all other packages that this package depends on, are linked in externally. This saves a lot of
memory.
Availability: For some projects that are documented with doxygen, the sources may just not be available.
Copyright issues: If the external package and its documentation are copyright someone else, it may be better - or
even necessary - to reference it rather than include a copy of it with your projects documentation. When the
author forbids redistribution, this is necessary. If the author requires compliance with some license condition
as a precondition of redistribution, and you do not want to be bound by those conditions, referring to their
copy of their documentation is preferable to including a copy.
If any of the above apply, you can use doxygens tag le mechanism. A tag le is basically a compact representation
of the entities found in the external sources. Doxygen can both generate and read tag les.
To generate a tag le for your project, simply put the name of the tag le after the GENERATE_TAGFILE option in
the conguration le.
To combine the output of one or more external projects with your own project you should specify the name of the
tag les after the TAGFILES option in the conguration le.
A tag le typically only contains a relative location of the documentation from the point where doxygen was run.
So when you include a tag le in other project you have to specify where the external documentation is located
in relation this project. You can do this in the conguration le by assigning the (relative) location to the tag les
specied after the TAGFILES conguration option. If you use a relative path it should be relative with respect to the
directory where the HTML output of your project is generated; so a relative path from the HTML output directory of
a project to the HTML output of the other project that is linked to.
Example:
Suppose you have a project proj that uses two external projects called ext1 and ext2. The directory
structure looks as follows:
82 Link to external documentation
<root>
+- proj
| +- html HTML output directory for proj
| +- src sources for proj
| |- proj.cpp
+- ext1
| +- html HTML output directory for ext1
| |- ext1.tag tag file for ext1
+- ext2
| +- html HTML output directory for ext2
| |- ext2.tag tag file for ext2
|- proj.cfg doxygen configuration file for proj
|- ext1.cfg doxygen configuration file for ext1
|- ext2.cfg doxygen configuration file for ext2
Then the relevant parts of the conguration les look as follows:
proj.cfg:
OUTPUT_DIRECTORY = proj
INPUT = proj/src
TAGFILES = ext1/ext1.tag=../../ext1/html \
ext2/ext2.tag=../../ext2/html
ext1.cfg:
OUTPUT_DIRECTORY = ext1
GENERATE_TAGFILE = ext1/ext1.tag
ext2.cfg:
OUTPUT_DIRECTORY = ext2
GENERATE_TAGFILE = ext2/ext2.tag
Generated by Doxygen
Chapter 17
Frequently Asked Questions
17.1 How to get information on the index page in HTML?
You should use the \mainpage command inside a comment block like this:
/
*
! \mainpage My Personal Index Page
*
*
\section intro_sec Introduction
*
*
This is the introduction.
*
*
\section install_sec Installation
*
*
\subsection step1 Step 1: Opening the box
*
*
etc...
*
/
17.2 Help, some/all of the members of my class / le / namespace are not documented?
Check the following:
1. Is your class / le / namespace documented? If not, it will not be extracted from the sources unless EXTR
ACT_ALL is set to YES in the cong le.
2. Are the members private? If so, you must set EXTRACT_PRIVATE to YES to make them appear in the
documentation.
3. Is there a function macro in your class that does not end with a semicolon (e.g. MY_MACRO())? If so then
you have to instruct doxygens preprocessor to remove it.
This typically boils down to the following settings in the cong le:
ENABLE_PREPROCESSING = YES
MACRO_EXPANSION = YES
EXPAND_ONLY_PREDEF = YES
PREDEFINED = MY_MACRO()=
Please read the preprocessing section of the manual for more information.
17.3 I set EXTRACT ALL to NO none of my functions are shown in the documentation.
In order for global functions, variables, enums, typedefs, and denes to be documented you should document the
le in which these commands are located using a comment block containing a \le (or @le) command.
84 Frequently Asked Questions
Alternatively, you can put all members in a group (or module) using the \ingroup command and then document the
group using a comment block containing the \defgroup command.
For member functions or functions that are part of a namespace you should document either the class or names-
pace.
17.4 How can I make doxygen ignore some code fragment?
The new and easiest way is to add one comment block with a \cond command at the start and one comment block
with a \endcond command at the end of the piece of code that should be ignored. This should be within the same
le of course.
But you can also use Doxygens preprocessor for this: If you put
#ifndef DOXYGEN_SHOULD_SKIP_THIS
/
*
code that must be skipped by Doxygen
*
/
#endif /
*
DOXYGEN_SHOULD_SKIP_THIS
*
/
around the blocks that should be hidden and put:
PREDEFINED = DOXYGEN_SHOULD_SKIP_THIS
in the cong le then all blocks should be skipped by Doxygen as long as ENABLE_PREPROCESSING is set to
YES.
17.5 How can I change what is after the <code>#include</code> in the class docu-
mentation?
In most cases you can use STRIP_FROM_INC_PATH to strip a user dened part of a path.
You can also document your class as follows
/
*
! \class MyClassName include.h path/include.h
*
*
Docs for MyClassName
*
/
To make doxygen put
#include <path/include.h>
in the documentation of the class MyClassName regardless of the name of the actual header le in which the
denition of MyClassName is contained.
If you want doxygen to show that the include le should be included using quotes instead of angle brackets you
should type:
/
*
! \class MyClassName myhdr.h "path/myhdr.h"
*
*
Docs for MyClassName
*
/
17.6 How can I use tag les in combination with compressed HTML?
If you want to refer from one compressed HTML le a.chm to another compressed HTML le called b.chm, the
link in a.chm must have the following format:
Generated by Doxygen
17.7 I dont like the quick index that is put above each HTML page, what do I do? 85
<a href="b.chm::/file.html">
Unfortunately this only works if both compressed HTML les are in the same directory.
As a result you must rename the generated index.chm les for all projects into something unique and put all
.chm les in one directory.
Suppose you have a project a referring to a project b using tag le b.tag, then you could rename the index.chm
for project a into a.chm and the index.chm for project b into b.chm. In the conguration le for project a you
write:
TAGFILES = b.tag=b.chm::
17.7 I dont like the quick index that is put above each HTML page, what do I do?
You can disable the index by setting DISABLE_INDEX to YES. Then you can put in your own header le by writing
your own header and feed that to HTML_HEADER.
17.8 The overall HTML output looks different, while I only wanted to use my own html
header le
You probably forgot to include the stylesheet doxygen.css that doxygen generates. You can include this by
putting
<LINK HREF="doxygen.css" REL="stylesheet" TYPE="text/css">
in the HEAD section of the HTML page.
17.9 Why does doxygen use Qt?
The most important reason is to have a platform abstraction for most Unices and Windows by means of the QFile,
QFileInfo, QDir, QDate, QTime and QIODevice classes. Another reason is for the nice and bug free utility classes,
like QList, QDict, QString, QArray, QTextStream, QRegExp, QXML etc.
The GUI front-end doxywizard uses Qt for... well... the GUI!
17.10 How can I exclude all test directories from my directory tree?
Simply put an exclude pattern like this in the conguration le:
EXCLUDE_PATTERNS =
*
/test/
*
17.11 Doxygen automatically generates a link to the class MyClass somewhere in the
running text. How do I prevent that at a certain place?
Put a % in front of the class name. Like this: %MyClass. Doxygen will then remove the % and keep the word
unlinked.
Generated by Doxygen
86 Frequently Asked Questions
17.12 My favorite programming language is X. Can I still use doxygen?
No, not as such; doxygen needs to understand the structure of what it reads. If you dont mind spending some time
on it, there are several options:
If the grammar of X is close to C or C++, then it is probably not too hard to tweak src/scanner.l a bit so the
language is supported. This is done for all other languages directly supported by doxygen (i.e. Java, IDL, C#,
PHP).
If the grammar of X is somewhat different than you can write an input lter that translates X into some-
thing similar enough to C/C++ for doxygen to understand (this approach is taken for VB, Object Pascal, and
Javascript, see http://www.stack.nl/dimitri/doxygen/download.html#helpers).
If the grammar is completely different one could write a parser for X and write a backend that produces a
similar syntax tree as is done by src/scanner.l (and also by src/tagreader.cpp while reading tag les).
17.13 Help! I get the cryptic message input buffer overow, cant enlarge buffer because
scanner uses REJECT
This error happens when doxygens lexical scanner has a rule that matches more than 256K of input characters
in one go. Ive seen this happening on a very large generated le (>256K lines), where the built-in preprocessor
converted it into an empty le (with >256K of newlines). Another case where this might happen is if you have lines
in your code with more than 256K characters.
If you have run into such a case and want me to x it, you should send me a code fragment that triggers the
message. To work around the problem, put some line-breaks into your le, split it up into smaller parts, or exclude
it from the input using EXCLUDE.
17.14 When running make in the latex dir I get TeX capacity exceeded. Now what?
You can edit the texmf.cfg le to increase the default values of the various buffers and then run "texcong init".
17.15 Why are dependencies via STL classes not shown in the dot graphs?
Doxygen is unaware of the STL classes, unless the option BUILTIN_STL_SUPPORT is turned on.
17.16 I have problems getting the search engine to work with PHP5 and/or windows
Please read this for hints on where to look.
17.17 Can I congure doxygen from the command line?
Not via command line options, but doxygen can read from stdin, so you can pipe things through it. Heres an ex-
ample how to override an option in a conguration le from the command line (assuming a UNIX like environment):
( cat Doxyfile ; echo "PROJECT_NUMBER=1.0" ) | doxygen -
For Windows the following would do the same:
( type Doxyfile & echo PROJECT_NUMBER=1.0 ) | doxygen.exe -
Generated by Doxygen
17.18 How did doxygen get its name? 87
If multiple options with the same name are specied then doxygen will use the last one. To append to an existing
option you can use the += operator.
17.18 How did doxygen get its name?
Doxygen got its name from playing with the words documentation and generator.
documentation -> docs -> dox
generator -> gen
At the time I was looking into lex and yacc, where a lot of things start with "yy", so the "y" slipped in and made
things pronounceable (the proper pronouncement is Docs-ee-gen, so with a long "e").
17.19 What was the reason to develop doxygen?
I once wrote a GUI widget based on the Qt library (it is still available at http://sourceforge.
net/projects/qdbttabular/ but hasnt been updated since 2002). Qt had nicely generated documentation
(using an internal tool which they didnt want to release) and I wrote similar docs by hand. This was
a nightmare to maintain, so I wanted a similar tool. I looked at Doc++ but that just wasnt good enough (it didnt
support signals and slots and did not have the Qt look and feel I had grown to like), so I started to write my own
tool...
Generated by Doxygen
88 Frequently Asked Questions
Generated by Doxygen
Chapter 18
Troubleshooting
18.1 Known Problems
If you have problems building doxygen from sources, please read this section rst.
Doxygen is not a real compiler, it is only a lexical scanner. This means that it can and will not detect errors in
your source code.
Doxygen has a build in preprocessor, but this works slightly different than the C preprocessor. Doxygen
assumes a header le is properly guarded against multiple inclusion, and that each include le is standalone
(i.e. it could be placed at the top of a source le without causing compiler errors). As long as this is true (and
this is a good design practice) you should not encounter problems.
Since it is impossible to test all possible code fragments, it is very well possible, that some valid piece of C/
C++ code is not handled properly. If you nd such a piece, please send it to me, so I can improve doxygens
parsing capabilities. Try to make the piece of code you send as small as possible, to help me narrow down
the search.
Doxygen does not work properly if there are multiple classes, structs or unions with the same name in your
code. It should not crash however, rather it should ignore all of the classes with the same name except one.
Some commands do not work inside the arguments of other commands. Inside a HTML link (i.
e. <a href="...">...<a>) for instance other commands (including other HTML commands) do not work!
The sectioning commands are an important exception.
Redundant braces can confuse doxygen in some cases. For example:
void f (int);
is properly parsed as a function declaration, but
const int (a);
is also seen as a function declaration with name int, because only the syntax is analyzed, not the semantics.
If the redundant braces can be detected, as in
int
*
(a[20]);
then doxygen will remove the braces and correctly parse the result.
Not all names in code fragments that are included in the documentation are replaced by links (for instance
when using SOURCE_BROWSER = YES) and links to overloaded members may point to the wrong member.
This also holds for the "Referenced by" list that is generated for each function.
For a part this is because the code parser isnt smart enough at the moment. Ill try to improve this in
the future. But even with these improvements not everything can be properly linked to the corresponding
documentation, because of possible ambiguities or lack of information about the context in which the code
fragment is found.
90 Troubleshooting
It is not possible to insert a non-member function f in a class A using the \relates or \relatesalso command, if
class A already has a member with name f and the same argument list.
There is only very limited support for member specialization at the moment. It only works if there is a special-
ized template class as well.
Not all special commands are properly translated to RTF.
Version 1.8.6 of dot (and maybe earlier versions too) do not generate proper map les, causing the graphs
that doxygen generates not to be properly clickable.
PHP only: Doxygen requires that all PHP statements (i.e. code) is wrapped in a functions/methods, otherwise
you may run into parse problems.
18.2 How to Help
The development of Doxygen highly depends on your input!
If you are trying Doxygen let me know what you think of it (do you miss certain features?). Even if you decide not to
use it, please let me know why.
18.3 How to report a bug
Bugs are tracked in GNOMEs bugzilla database. Before submitting a new bug, rst search through the
database if the same bug has already been submitted by others (the doxygen product will be preselected). If you
believe you have found a new bug, please report it.
If you are unsure whether or not something is a bug, please ask help on the users mailing list rst (sub-
scription is required).
If you send only a (vague) description of a bug, you are usually not very helpful and it will cost me much more time
to gure out what you mean. In the worst-case your bug report may even be completely ignored by me, so always
try to include the following information in your bug report:
The version of doxygen you are using (for instance 1.5.3, use doxygen --version if you are not sure).
The name and version number of your operating system (for instance SuSE Linux 6.4)
It is usually a good idea to send along the conguration le as well, but please use doxygen with the -s ag
while generating it to keep it small (use doxygen -s -u [configName] to strip the comments from
an existing cong le).
The easiest (and often the only) way for me to x bugs is if you can attach a small example demonstrating the
problem you have to the bug report, so I can reproduce it on my machine. Please make sure the example is
valid source code (could potentially compile) and that the problem is really captured by the example (I often
get examples that do not trigger the actual bug!). If you intend to send more than one le please zip or tar the
les together into a single le for easier processing. Note that when reporting a new bug youll get a chance
to attach a le to it only after submitting the initial bug description.
You can (and are encouraged to) add a patch for a bug. If you do so please use PATCH as a keyword in the bug
entry form.
If you have ideas how to x existing bugs and limitations please discuss them on the developers mailing
list (subscription required). Patches can also be sent directly to [email protected] if you prefer not to send
them via the bug tracker or mailing list.
For patches please use "diff -uN" or include the les you modied. If you send more than one le please tar or zip
everything, so I only have to save and download one le.
Generated by Doxygen
Part II
Reference Manual
Chapter 19
Features
Requires very little overhead from the writer of the documentation. Plain text will do, Markdown is support,
and for more fancy or structured output HTML tags and/or some of doxygens special commands can be used.
Cross platform: works on Windows and many Unix avors (including Linux and MacOSX).
Indexes, organizes and generates browsable and cross-referenced output even from undocumented code.
Generates structured XML output for parsed sources, which can be used by external tools.
Supports C/C++, Java, (Corba and Microsoft) Java, Python, VHDL, PHP IDL, C#, Fortran, TCL, Objective-C
2.0, and to some extent D sources.
Supports documentation of les, namespaces, packages, classes, structs, unions, templates, variables, func-
tions, typedefs, enums and denes.
JavaDoc (1.1), qdoc3 (partially), and ECMA-334 (C# spec.) compatible.
Comes with a GUI frontend (Doxywizard) to ease editing the options and run doxygen. The GUI is available
on Windows, Linux, and MacOSX.
Automatically generates class and collaboration diagrams in HTML (as clickable image maps) and L
A
T
E
X (as
Encapsulated PostScript images).
Uses the dot tool of the Graphviz tool kit to generate include dependency graphs, collaboration diagrams,
call graphs, directory structure graphs, and graphical class hierarchy graphs.
Allows grouping of entities in modules and creating a hierarchy of modules.
Flexible comment placement: Allows you to put documentation in the header le (before the declaration of an
entity), source le (before the denition of an entity) or in a separate le.
Generates a list of all members of a class (including any inherited members) along with their protection level.
Outputs documentation in on-line format (XHTML and UNIX man page) and off-line format ( L
A
T
E
X and RTF)
simultaneously (any of these can be disabled if desired). All formats are optimized for ease of reading.
Furthermore, compressed HTML can be generated from HTML output using Microsofts HTML Help Work-
shop (Windows only) and PDF can be generated from the L
A
T
E
X output.
Support for various third party help formats including HTML Help, docsets, Qt-Help, and eclipse help.
Includes a full C preprocessor to allow proper parsing of conditional code fragments and to allow expansion
of all or part of macros denitions.
Automatically detects public, protected and private sections, as well as the Qt specic signal and slots sec-
tions. Extraction of private class members is optional.
Automatically generates references to documented classes, les, namespaces and members. Documentation
of global functions, global variables, typedefs, denes and enumerations is also supported.
94 Features
References to base/super classes and inherited/overridden members are generated automatically.
Includes a fast, rank based search engine to search for strings or words in the class and member documen-
tation (PHP based).
Includes an Javascript based live search feature to search for symbols as you type (for small to medium sized
projects).
You can type normal HTML tags in your documentation. Doxygen will convert them to their equivalent L
A
T
E
X,
RTF, and man-page counterparts automatically.
Allows references to documentation generated for other (doxygen documented) projects (or another part of
the same project) in a location independent way.
Allows inclusion of source code examples that are automatically cross-referenced with the documentation.
Inclusion of undocumented classes is also supported, allowing to quickly learn the structure and interfaces of
a (large) piece of code without looking into the implementation details.
Allows automatic cross-referencing of (documented) entities with their denition in the source code.
All source code fragments are syntax highlighted for ease of reading.
Allows inclusion of function/member/class denitions in the documentation.
All options are read from an easy to edit and (optionally) annotated conguration le.
Documentation and search engine can be transferred to another location or machine without regenerating the
documentation.
Supports many different character encodings and uses UTF-8 internally and for the generated output.
Doxygen can generate a layout which you can use and edit to change the layout of each page.
There more than a 100 congurable options to ne-tune the output.
Can cope with large projects easily.
Although doxygen can now be used in any project written in a language that is supported by doxygen, initially it was
specically designed to be used for projects that make use of Qt Softwares Qt toolkit. I have tried to make
doxygen Qt-compatible. That is: Doxygen can read the documentation contained in the Qt source code and create
a class browser that looks quite similar to the one that is generated by Qt Software. Doxygen understands the C++
extensions used by Qt such as signals and slots and many of the markup commands used in the Qt sources.
Doxygen can also automatically generate links to existing documentation that was generated with Doxygen or with
Qts non-public class browser generator. For a Qt based project this means that whenever you refer to members or
classes belonging to the Qt toolkit, a link will be generated to the Qt documentation. This is done independent of
where this documentation is located!
Generated by Doxygen
Chapter 20
Doxygen usage
Doxygen is a command line based utility. Calling doxygen with the --help option at the command line will give
you a brief description of the usage of the program.
All options consist of a leading character -, followed by one character and one or more arguments depending on
the option.
To generate a manual for your project you typically need to follow these steps:
1. You document your source code with special documentation blocks (see section Special comment blocks).
2. You generate a conguration le (see section Conguration) by calling doxygen with the -g option:
doxygen -g <config_file>
3. You edit the conguration le so it matches your project. In the conguration le you can specify the input
les and a lot of optional information.
4. You let doxygen generate the documentation, based on the settings in the conguration le:
doxygen <config_file>
If you have a conguration le generated with an older version of doxygen, you can upgrade it to the current version
by running doxygen with the -u option.
doxygen -u <config_file>
All conguration settings in the original conguration le will be copied to the new conguration le. Any new options
will have their default value. Note that comments that you may have added in the original conguration le will be
lost.
20.1 Fine-tuning the output
If you want to ne-tune the way the output looks, doxygen allows you generate default style sheet, header, and
footer les that you can edit afterwards:
For HTML output, you can generate the default header le (see HTML_HEADER), the default footer (see
HTML_FOOTER), and the default style sheet (see HTML_STYLESHEET), using the following command:
doxygen -w html header.html footer.html stylesheet.css <config_file>
The config_file is optional. When omitted doxygen will search for a le named Doxyfile and process
that. When this is also not found it will used the default settings.
For L
A
T
E
X output, you can generate the rst and last part of refman.tex (see LATEX_HEADER and LA
TEX_FOOTER) and the style sheet included by that header (normally doxygen.sty), using the following
command:
96 Doxygen usage
doxygen -w latex header.tex footer.tex doxygen.sty <config_file>
If you need non-default options (for instance to use extra L
A
T
E
X packages) you need to make a cong le with
those options set correctly and then specify that cong le after the generated les (make a backup of the
conguration le rst so you dont loose it in case you forget to specify one of the output les).
For RTF output, you can generate the default style sheet le (see RTF_STYLESHEET_FILE) using:
doxygen -w rtf rtfstyle.cfg
Warning
When using a custom header you are responsible for the proper inclusion of any scripts and style sheets that
doxygen needs, which is dependent on the conguration options and may changes when upgrading to a new
doxygen release.
Note
If you do not want documentation for each item inside the conguration le then you can use the optional
-s option. This can use be used in combination with the -u option, to add or strip the documentation
from an existing conguration le. Please use the -s option if you send me a conguration le as part of
a bug report!
To make doxygen read/write to standard input/output instead of from/to a le, use - for the le name.
Generated by Doxygen
Chapter 21
Doxywizard usage
Doxywizard is a GUI front-end for conguring and running doxygen.
Note it is possible to start the doxywizard with as argument the conguration le to be used.
When you start doxywizard it will display the main window (the actual look depends on the OS used).
Figure 21.1: Main window
The windows shows the steps to take to congure and run doxygen. The rst step is to choose one of the ways to
congure doxygen.
98 Doxywizard usage
Wizard Click this button to quickly congure the most important settings and leave the rest of the options to their
defaults.
Expert Click this button to gain access to the full range of conguration options.
Load Click this button to load an existing conguration le from disk.
Note that you can select multiple buttons in a row, for instance to rst congure doxygen using the Wizard and then
ne tune the settings via the Expert.
After doxygen is congured you need to save the conguration as a le to disk. This second step allows doxygen
to use the conguration and has the additional advantage that the conguration can be reused to run doxygen with
the same settings at a later point in time.
Since some conguration options may use relative paths, the next step is to select a directory from which to run
doxygen. This is typically the root of the source tree and will most of the time already be lled in correctly.
Once the conguration le is saved and the working directory is set, you can run doxygen based on the selected
settings. Do this by pressing the "Start" button. Once doxygen runs you can cancel it by clicking the same button
again. The output produced by doxygen is captured and shown in a log window. Once doxygen nishes, the log
can be saved as a text le.
The Wizard Dialog
If you select the Wizard button in step 1, then a dialog with a number of tabs will appear.
Figure 21.2: Wizard dialog: Project settings
The elds in the project tab speak for themselves. Once doxygen has nished the Destination directory is where to
look for the results. Doxygen will put each output format in a separate sub-directory.
Generated by Doxygen
99
Figure 21.3: Wizard dialog: Mode of operating
The mode tab allows you to select how doxygen will look at your sources. The default is to only look for things that
have been documented.
You can also select how doxygen should present the results. The latter does not affect the way doxygen parses
your source code.
Generated by Doxygen
100 Doxywizard usage
Figure 21.4: Wizard dialog: Output to produce
You can select one or more of the output formats that doxygen should produce. For HTML and L
A
T
E
X there are
additional options.
Figure 21.5: Wizard dialog: Diagrams to generate
Generated by Doxygen
101
Doxygen can produce a number of diagrams. Using the diagrams tab you can select which ones to generate. For
most diagrams the dot tool of the GraphViz package is needed (if you use the binary packages for MacOSX this
tool is already included).
Expert dialog
The Expert dialog has a number of tab elds, one for each section in the conguration le. Each tab-eld contains
a number of lines, one for each conguration option in that section.
The kind of input widget depends on the type of the conguration option.
For each boolean option (those options that are answered with YES or NO in the conguration le) there is a
check-box.
For items taking one of a xed set of values (like OUTPUT_LANGUAGE) a combo box is used.
For items taking an integer value from a range, a spinbox is used.
For free form string-type options there is a one line edit eld
For options taking a lists of strings, a one line edit eld is available, with a + button to add this string to the
list and a - button to remove the selected string from the list. There is also a button that, when pressed,
replaces the selected item in the list with the string entered in the edit eld.
For le and folder entries, there are special buttons that start a le selection dialog.
Figure 21.6: Some options from the Expert dialog
The get additional information about the meaning of an option, click on the "Help" button at the bottom right of the
dialog and then on the item. A tooltip with additional information will appear.
Menu options
The GUI front-end has a menu with a couple of useful items
Generated by Doxygen
102 Doxywizard usage
Figure 21.7: File menu
Open... This is the same as the "Load" button in the main window and allows to open a conguration le from disk.
Save as.. This is the same as the "Save" button in the main window and can be used to save the current congu-
ration settings to disk.
Recent congurations Allow to quickly load a recently saved conguration.
Set as default... Stores the current conguration settings as the default to use next time the GUI is started. You
will be asked to conrm the action.
Reset... Restores the factory defaults as the default settings to use. You will be asked to conrm the action.
Generated by Doxygen
Chapter 22
Conguration
22.1 Format
A conguration le is a free-form ASCII text le with a structure that is similar to that of a Makefile, with the default
name Doxyfile. It is parsed by doxygen. The le may contain tabs and newlines for formatting purposes. The
statements in the le are case-sensitive. Comments may be placed anywhere within the le (except within quotes).
Comments beginning with two hash characters (##) are kept when updating the conguration le and are placed in
front of the TAG are in front of. Comments beginning with two hash characters (##) at the end of the conguration
le are also kept and placed at the end of the le. Comments begin with the hash character (#) and ends at the end
of the line.
The le essentially consists of a list of assignment statements. Each statement consists of a TAG_NAME written in
capitals, followed by the equal sign (=) and one or more values. If the same tag is assigned more than once, the
last assignment overwrites any earlier assignment. For tags that take a list as their argument, the += operator can
be used instead of = to append new values to the list. Values are sequences of non-blanks. If the value should
contain one or more blanks it must be surrounded by quotes ("..."). Multiple lines can be concatenated by
inserting a backslash (\) as the last character of a line. Environment variables can be expanded using the pattern
$(ENV_VARIABLE_NAME).
You can also include part of a conguration le from another conguration le using a @INCLUDE tag as follows:
@INCLUDE = config_file_name
The include le is searched in the current working directory. You can also specify a list of directories that should
be searched before looking in the current working directory. Do this by putting a @INCLUDE_PATH tag with these
paths before the @INCLUDE tag, e.g.:
@INCLUDE_PATH = my_config_dir
The conguration options can be divided into several categories. Below is an alphabetical index of the tags that are
recognized followed by the descriptions of the tags grouped by category.
ABBREVIATE_BRIEF . . . . . . . . . . . . . . . . . . . . 22.2
ALIASES . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2
ALLEXTERNALS . . . . . . . . . . . . . . . . . . . . . .22.17
ALLOW_UNICODE_NAMES . . . . . . . . . . . . . . . . 22.2
ALPHABETICAL_INDEX . . . . . . . . . . . . . . . . . . 22.7
ALWAYS_DETAILED_SEC . . . . . . . . . . . . . . . . . 22.2
AUTOLINK_SUPPORT . . . . . . . . . . . . . . . . . . . 22.2
BINARY_TOC . . . . . . . . . . . . . . . . . . . . . . . . 22.8
BRIEF_MEMBER_DESC . . . . . . . . . . . . . . . . . . 22.2
BUILTIN_STL_SUPPORT . . . . . . . . . . . . . . . . . . 22.2
CALLER_GRAPH . . . . . . . . . . . . . . . . . . . . . .22.18
CALL_GRAPH . . . . . . . . . . . . . . . . . . . . . . . .22.18
CASE_SENSE_NAMES . . . . . . . . . . . . . . . . . . . 22.3
CHM_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . 22.8
CHM_INDEX_ENCODING . . . . . . . . . . . . . . . . . 22.8
CITE_BIB_FILES . . . . . . . . . . . . . . . . . . . . . . 22.3
CLANG_ASSISTED_PARSING . . . . . . . . . . . . . . . 22.6
CLANG_OPTIONS . . . . . . . . . . . . . . . . . . . . . 22.6
CLASS_DIAGRAMS . . . . . . . . . . . . . . . . . . . . .22.18
CLASS_GRAPH . . . . . . . . . . . . . . . . . . . . . . .22.18
COLLABORATION_GRAPH . . . . . . . . . . . . . . . .22.18
COLS_IN_ALPHA_INDEX . . . . . . . . . . . . . . . . . 22.7
COMPACT_LATEX . . . . . . . . . . . . . . . . . . . . . 22.9
COMPACT_RTF . . . . . . . . . . . . . . . . . . . . . . .22.10
CPP_CLI_SUPPORT . . . . . . . . . . . . . . . . . . . . 22.2
CREATE_SUBDIRS . . . . . . . . . . . . . . . . . . . . . 22.2
DIAFILE_DIRS . . . . . . . . . . . . . . . . . . . . . . .22.18
DIA_PATH . . . . . . . . . . . . . . . . . . . . . . . . . .22.18
DIRECTORY_GRAPH . . . . . . . . . . . . . . . . . . . .22.18
DISABLE_INDEX . . . . . . . . . . . . . . . . . . . . . . 22.8
DISTRIBUTE_GROUP_DOC . . . . . . . . . . . . . . . . 22.2
DOCBOOK_OUTPUT . . . . . . . . . . . . . . . . . . . .22.13
104 Conguration
DOCBOOK_PROGRAMLISTING . . . . . . . . . . . . . .22.13
DOCSET_BUNDLE_ID . . . . . . . . . . . . . . . . . . . 22.8
DOCSET_FEEDNAME . . . . . . . . . . . . . . . . . . . 22.8
DOCSET_PUBLISHER_ID . . . . . . . . . . . . . . . . . 22.8
DOCSET_PUBLISHER_NAME . . . . . . . . . . . . . . . 22.8
DOTFILE_DIRS . . . . . . . . . . . . . . . . . . . . . . .22.18
DOT_CLEANUP . . . . . . . . . . . . . . . . . . . . . . .22.18
DOT_FONTNAME . . . . . . . . . . . . . . . . . . . . . .22.18
DOT_FONTPATH . . . . . . . . . . . . . . . . . . . . . .22.18
DOT_FONTSIZE . . . . . . . . . . . . . . . . . . . . . .22.18
DOT_GRAPH_MAX_NODES . . . . . . . . . . . . . . . .22.18
DOT_IMAGE_FORMAT . . . . . . . . . . . . . . . . . . .22.18
DOT_MULTI_TARGETS . . . . . . . . . . . . . . . . . .22.18
DOT_NUM_THREADS . . . . . . . . . . . . . . . . . . .22.18
DOT_PATH . . . . . . . . . . . . . . . . . . . . . . . . .22.18
DOT_TRANSPARENT . . . . . . . . . . . . . . . . . . .22.18
DOXYFILE_ENCODING . . . . . . . . . . . . . . . . . . 22.2
ECLIPSE_DOC_ID . . . . . . . . . . . . . . . . . . . . . 22.8
ENABLED_SECTIONS . . . . . . . . . . . . . . . . . . . 22.3
ENABLE_PREPROCESSING . . . . . . . . . . . . . . . .22.16
ENUM_VALUES_PER_LINE . . . . . . . . . . . . . . . . 22.8
EXAMPLE_PATH . . . . . . . . . . . . . . . . . . . . . . 22.5
EXAMPLE_PATTERNS . . . . . . . . . . . . . . . . . . . 22.5
EXAMPLE_RECURSIVE . . . . . . . . . . . . . . . . . . 22.5
EXCLUDE . . . . . . . . . . . . . . . . . . . . . . . . . . 22.5
EXCLUDE_PATTERNS . . . . . . . . . . . . . . . . . . . 22.5
EXCLUDE_SYMBOLS . . . . . . . . . . . . . . . . . . . 22.5
EXCLUDE_SYMLINKS . . . . . . . . . . . . . . . . . . . 22.5
EXPAND_AS_DEFINED . . . . . . . . . . . . . . . . . .22.16
EXPAND_ONLY_PREDEF . . . . . . . . . . . . . . . . .22.16
EXTENSION_MAPPING . . . . . . . . . . . . . . . . . . 22.2
EXTERNAL_GROUPS . . . . . . . . . . . . . . . . . . .22.17
EXTERNAL_PAGES . . . . . . . . . . . . . . . . . . . .22.17
EXTERNAL_SEARCH . . . . . . . . . . . . . . . . . . . . 22.8
EXTERNAL_SEARCH_ID . . . . . . . . . . . . . . . . . . 22.8
EXTRACT_ALL . . . . . . . . . . . . . . . . . . . . . . . 22.3
EXTRACT_ANON_NSPACES . . . . . . . . . . . . . . . 22.3
EXTRACT_LOCAL_CLASSES . . . . . . . . . . . . . . . 22.3
EXTRACT_LOCAL_METHODS . . . . . . . . . . . . . . . 22.3
EXTRACT_PACKAGE . . . . . . . . . . . . . . . . . . . 22.3
EXTRACT_PRIVATE . . . . . . . . . . . . . . . . . . . . 22.3
EXTRACT_STATIC . . . . . . . . . . . . . . . . . . . . . 22.3
EXTRA_PACKAGES . . . . . . . . . . . . . . . . . . . . 22.9
EXTRA_SEARCH_MAPPINGS . . . . . . . . . . . . . . . 22.8
EXT_LINKS_IN_WINDOW . . . . . . . . . . . . . . . . . 22.8
FILE_PATTERNS . . . . . . . . . . . . . . . . . . . . . . 22.5
FILE_VERSION_FILTER . . . . . . . . . . . . . . . . . . 22.3
FILTER_PATTERNS . . . . . . . . . . . . . . . . . . . . 22.5
FILTER_SOURCE_FILES . . . . . . . . . . . . . . . . . . 22.5
FILTER_SOURCE_PATTERNS . . . . . . . . . . . . . . . 22.5
FORCE_LOCAL_INCLUDES . . . . . . . . . . . . . . . . 22.3
FORMULA_FONTSIZE . . . . . . . . . . . . . . . . . . . 22.8
FORMULA_TRANSPARENT . . . . . . . . . . . . . . . . 22.8
FULL_PATH_NAMES . . . . . . . . . . . . . . . . . . . . 22.2
GENERATE_AUTOGEN_DEF . . . . . . . . . . . . . . .22.14
GENERATE_BUGLIST . . . . . . . . . . . . . . . . . . . 22.3
GENERATE_CHI . . . . . . . . . . . . . . . . . . . . . . 22.8
GENERATE_DEPRECATEDLIST . . . . . . . . . . . . . . 22.3
GENERATE_DOCBOOK . . . . . . . . . . . . . . . . . .22.13
GENERATE_DOCSET . . . . . . . . . . . . . . . . . . . 22.8
GENERATE_ECLIPSEHELP . . . . . . . . . . . . . . . . 22.8
GENERATE_HTML . . . . . . . . . . . . . . . . . . . . . 22.8
GENERATE_HTMLHELP . . . . . . . . . . . . . . . . . . 22.8
GENERATE_LATEX . . . . . . . . . . . . . . . . . . . . 22.9
GENERATE_LEGEND . . . . . . . . . . . . . . . . . . .22.18
GENERATE_MAN . . . . . . . . . . . . . . . . . . . . . .22.11
GENERATE_PERLMOD . . . . . . . . . . . . . . . . . .22.15
GENERATE_QHP . . . . . . . . . . . . . . . . . . . . . . 22.8
GENERATE_RTF . . . . . . . . . . . . . . . . . . . . . .22.10
GENERATE_TAGFILE . . . . . . . . . . . . . . . . . . .22.17
GENERATE_TESTLIST . . . . . . . . . . . . . . . . . . . 22.3
GENERATE_TODOLIST . . . . . . . . . . . . . . . . . . 22.3
GENERATE_TREEVIEW . . . . . . . . . . . . . . . . . . 22.8
GENERATE_XML . . . . . . . . . . . . . . . . . . . . . .22.12
GRAPHICAL_HIERARCHY . . . . . . . . . . . . . . . . .22.18
GROUP_GRAPHS . . . . . . . . . . . . . . . . . . . . .22.18
HAVE_DOT . . . . . . . . . . . . . . . . . . . . . . . . .22.18
HHC_LOCATION . . . . . . . . . . . . . . . . . . . . . . 22.8
HIDE_FRIEND_COMPOUNDS . . . . . . . . . . . . . . . 22.3
HIDE_IN_BODY_DOCS . . . . . . . . . . . . . . . . . . . 22.3
HIDE_SCOPE_NAMES . . . . . . . . . . . . . . . . . . . 22.3
HIDE_UNDOC_CLASSES . . . . . . . . . . . . . . . . . 22.3
HIDE_UNDOC_MEMBERS . . . . . . . . . . . . . . . . . 22.3
HIDE_UNDOC_RELATIONS . . . . . . . . . . . . . . . .22.18
HTML_COLORSTYLE_GAMMA . . . . . . . . . . . . . . 22.8
HTML_COLORSTYLE_HUE . . . . . . . . . . . . . . . . 22.8
HTML_COLORSTYLE_SAT . . . . . . . . . . . . . . . . . 22.8
HTML_DYNAMIC_SECTIONS . . . . . . . . . . . . . . . 22.8
HTML_EXTRA_FILES . . . . . . . . . . . . . . . . . . . . 22.8
HTML_EXTRA_STYLESHEET . . . . . . . . . . . . . . . 22.8
HTML_FILE_EXTENSION . . . . . . . . . . . . . . . . . 22.8
HTML_FOOTER . . . . . . . . . . . . . . . . . . . . . . . 22.8
HTML_HEADER . . . . . . . . . . . . . . . . . . . . . . . 22.8
HTML_INDEX_NUM_ENTRIES . . . . . . . . . . . . . . . 22.8
HTML_OUTPUT . . . . . . . . . . . . . . . . . . . . . . . 22.8
HTML_STYLESHEET . . . . . . . . . . . . . . . . . . . . 22.8
HTML_TIMESTAMP . . . . . . . . . . . . . . . . . . . . . 22.8
IDL_PROPERTY_SUPPORT . . . . . . . . . . . . . . . . 22.2
IGNORE_PREFIX . . . . . . . . . . . . . . . . . . . . . . 22.7
IMAGE_PATH . . . . . . . . . . . . . . . . . . . . . . . . 22.5
INCLUDED_BY_GRAPH . . . . . . . . . . . . . . . . . .22.18
INCLUDE_FILE_PATTERNS . . . . . . . . . . . . . . . .22.16
INCLUDE_GRAPH . . . . . . . . . . . . . . . . . . . . .22.18
INCLUDE_PATH . . . . . . . . . . . . . . . . . . . . . .22.16
INHERIT_DOCS . . . . . . . . . . . . . . . . . . . . . . . 22.2
INLINE_GROUPED_CLASSES . . . . . . . . . . . . . . . 22.2
INLINE_INFO . . . . . . . . . . . . . . . . . . . . . . . . 22.3
INLINE_INHERITED_MEMB . . . . . . . . . . . . . . . . 22.2
INLINE_SIMPLE_STRUCTS . . . . . . . . . . . . . . . . 22.2
INLINE_SOURCES . . . . . . . . . . . . . . . . . . . . . 22.6
INPUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.5
INPUT_ENCODING . . . . . . . . . . . . . . . . . . . . . 22.5
INPUT_FILTER . . . . . . . . . . . . . . . . . . . . . . . 22.5
INTERACTIVE_SVG . . . . . . . . . . . . . . . . . . . .22.18
INTERNAL_DOCS . . . . . . . . . . . . . . . . . . . . . 22.3
JAVADOC_AUTOBRIEF . . . . . . . . . . . . . . . . . . 22.2
LATEX_BATCHMODE . . . . . . . . . . . . . . . . . . . 22.9
LATEX_BIB_STYLE . . . . . . . . . . . . . . . . . . . . . 22.9
LATEX_CMD_NAME . . . . . . . . . . . . . . . . . . . . 22.9
LATEX_EXTRA_FILES . . . . . . . . . . . . . . . . . . . 22.9
LATEX_FOOTER . . . . . . . . . . . . . . . . . . . . . . 22.9
LATEX_HEADER . . . . . . . . . . . . . . . . . . . . . . 22.9
LATEX_HIDE_INDICES . . . . . . . . . . . . . . . . . . . 22.9
LATEX_OUTPUT . . . . . . . . . . . . . . . . . . . . . . 22.9
LATEX_SOURCE_CODE . . . . . . . . . . . . . . . . . . 22.9
LAYOUT_FILE . . . . . . . . . . . . . . . . . . . . . . . 22.3
LOOKUP_CACHE_SIZE . . . . . . . . . . . . . . . . . . 22.2
MACRO_EXPANSION . . . . . . . . . . . . . . . . . . .22.16
MAKEINDEX_CMD_NAME . . . . . . . . . . . . . . . . . 22.9
MAN_EXTENSION . . . . . . . . . . . . . . . . . . . . .22.11
MAN_LINKS . . . . . . . . . . . . . . . . . . . . . . . . .22.11
MAN_OUTPUT . . . . . . . . . . . . . . . . . . . . . . .22.11
MAN_SUBDIR . . . . . . . . . . . . . . . . . . . . . . . .22.11
MARKDOWN_SUPPORT . . . . . . . . . . . . . . . . . . 22.2
MATHJAX_CODEFILE . . . . . . . . . . . . . . . . . . . 22.8
MATHJAX_EXTENSIONS . . . . . . . . . . . . . . . . . . 22.8
MATHJAX_FORMAT . . . . . . . . . . . . . . . . . . . . 22.8
MATHJAX_RELPATH . . . . . . . . . . . . . . . . . . . . 22.8
MAX_DOT_GRAPH_DEPTH . . . . . . . . . . . . . . . .22.18
MAX_INITIALIZER_LINES . . . . . . . . . . . . . . . . . 22.3
MSCFILE_DIRS . . . . . . . . . . . . . . . . . . . . . . .22.18
MSCGEN_PATH . . . . . . . . . . . . . . . . . . . . . .22.18
MULTILINE_CPP_IS_BRIEF . . . . . . . . . . . . . . . . 22.2
OPTIMIZE_FOR_FORTRAN . . . . . . . . . . . . . . . . 22.2
OPTIMIZE_OUTPUT_FOR_C . . . . . . . . . . . . . . . . 22.2
OPTIMIZE_OUTPUT_JAVA . . . . . . . . . . . . . . . . . 22.2
Generated by Doxygen
22.2 Project related conguration options 105
OPTIMIZE_OUTPUT_VHDL . . . . . . . . . . . . . . . . 22.2
OUTPUT_DIRECTORY . . . . . . . . . . . . . . . . . . . 22.2
OUTPUT_LANGUAGE . . . . . . . . . . . . . . . . . . . 22.2
PAPER_TYPE . . . . . . . . . . . . . . . . . . . . . . . . 22.9
PDF_HYPERLINKS . . . . . . . . . . . . . . . . . . . . . 22.9
PERLMOD_LATEX . . . . . . . . . . . . . . . . . . . . .22.15
PERLMOD_MAKEVAR_PREFIX . . . . . . . . . . . . . .22.15
PERLMOD_PRETTY . . . . . . . . . . . . . . . . . . . .22.15
PERL_PATH . . . . . . . . . . . . . . . . . . . . . . . .22.17
PLANTUML_JAR_PATH . . . . . . . . . . . . . . . . . .22.18
PREDEFINED . . . . . . . . . . . . . . . . . . . . . . . .22.16
PROJECT_BRIEF . . . . . . . . . . . . . . . . . . . . . . 22.2
PROJECT_LOGO . . . . . . . . . . . . . . . . . . . . . . 22.2
PROJECT_NAME . . . . . . . . . . . . . . . . . . . . . . 22.2
PROJECT_NUMBER . . . . . . . . . . . . . . . . . . . . 22.2
QCH_FILE . . . . . . . . . . . . . . . . . . . . . . . . . . 22.8
QHG_LOCATION . . . . . . . . . . . . . . . . . . . . . . 22.8
QHP_CUST_FILTER_ATTRS . . . . . . . . . . . . . . . . 22.8
QHP_CUST_FILTER_NAME . . . . . . . . . . . . . . . . 22.8
QHP_NAMESPACE . . . . . . . . . . . . . . . . . . . . . 22.8
QHP_SECT_FILTER_ATTRS . . . . . . . . . . . . . . . . 22.8
QHP_VIRTUAL_FOLDER . . . . . . . . . . . . . . . . . . 22.8
QT_AUTOBRIEF . . . . . . . . . . . . . . . . . . . . . . 22.2
QUIET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4
RECURSIVE . . . . . . . . . . . . . . . . . . . . . . . . . 22.5
REFERENCED_BY_RELATION . . . . . . . . . . . . . . 22.6
REFERENCES_LINK_SOURCE . . . . . . . . . . . . . . 22.6
REFERENCES_RELATION . . . . . . . . . . . . . . . . . 22.6
REPEAT_BRIEF . . . . . . . . . . . . . . . . . . . . . . 22.2
RTF_EXTENSIONS_FILE . . . . . . . . . . . . . . . . . .22.10
RTF_HYPERLINKS . . . . . . . . . . . . . . . . . . . . .22.10
RTF_OUTPUT . . . . . . . . . . . . . . . . . . . . . . . .22.10
RTF_STYLESHEET_FILE . . . . . . . . . . . . . . . . .22.10
SEARCHDATA_FILE . . . . . . . . . . . . . . . . . . . . 22.8
SEARCHENGINE . . . . . . . . . . . . . . . . . . . . . . 22.8
SEARCHENGINE_URL . . . . . . . . . . . . . . . . . . . 22.8
SEARCH_INCLUDES . . . . . . . . . . . . . . . . . . . .22.16
SEPARATE_MEMBER_PAGES . . . . . . . . . . . . . . 22.2
SERVER_BASED_SEARCH . . . . . . . . . . . . . . . . 22.8
SHORT_NAMES . . . . . . . . . . . . . . . . . . . . . . 22.2
SHOW_FILES . . . . . . . . . . . . . . . . . . . . . . . . 22.3
SHOW_GROUPED_MEMB_INC . . . . . . . . . . . . . . 22.3
SHOW_INCLUDE_FILES . . . . . . . . . . . . . . . . . . 22.3
SHOW_NAMESPACES . . . . . . . . . . . . . . . . . . . 22.3
SHOW_USED_FILES . . . . . . . . . . . . . . . . . . . . 22.3
SIP_SUPPORT . . . . . . . . . . . . . . . . . . . . . . . 22.2
SKIP_FUNCTION_MACROS . . . . . . . . . . . . . . . .22.16
SORT_BRIEF_DOCS . . . . . . . . . . . . . . . . . . . . 22.3
SORT_BY_SCOPE_NAME . . . . . . . . . . . . . . . . . 22.3
SORT_GROUP_NAMES . . . . . . . . . . . . . . . . . . 22.3
SORT_MEMBERS_CTORS_1ST . . . . . . . . . . . . . . 22.3
SORT_MEMBER_DOCS . . . . . . . . . . . . . . . . . . 22.3
SOURCE_BROWSER . . . . . . . . . . . . . . . . . . . . 22.6
SOURCE_TOOLTIPS . . . . . . . . . . . . . . . . . . . . 22.6
STRICT_PROTO_MATCHING . . . . . . . . . . . . . . . 22.3
STRIP_CODE_COMMENTS . . . . . . . . . . . . . . . . 22.6
STRIP_FROM_INC_PATH . . . . . . . . . . . . . . . . . 22.2
STRIP_FROM_PATH . . . . . . . . . . . . . . . . . . . . 22.2
SUBGROUPING . . . . . . . . . . . . . . . . . . . . . . . 22.2
TAB_SIZE . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2
TAGFILES . . . . . . . . . . . . . . . . . . . . . . . . . .22.17
TCL_SUBST . . . . . . . . . . . . . . . . . . . . . . . . . 22.2
TEMPLATE_RELATIONS . . . . . . . . . . . . . . . . . .22.18
TOC_EXPAND . . . . . . . . . . . . . . . . . . . . . . . 22.8
TREEVIEW_WIDTH . . . . . . . . . . . . . . . . . . . . . 22.8
TYPEDEF_HIDES_STRUCT . . . . . . . . . . . . . . . . 22.2
UML_LIMIT_NUM_FIELDS . . . . . . . . . . . . . . . . .22.18
UML_LOOK . . . . . . . . . . . . . . . . . . . . . . . . .22.18
USE_HTAGS . . . . . . . . . . . . . . . . . . . . . . . . 22.6
USE_MATHJAX . . . . . . . . . . . . . . . . . . . . . . . 22.8
USE_MDFILE_AS_MAINPAGE . . . . . . . . . . . . . . . 22.5
USE_PDFLATEX . . . . . . . . . . . . . . . . . . . . . . 22.9
VERBATIM_HEADERS . . . . . . . . . . . . . . . . . . . 22.6
WARNINGS . . . . . . . . . . . . . . . . . . . . . . . . . 22.4
WARN_FORMAT . . . . . . . . . . . . . . . . . . . . . . 22.4
WARN_IF_DOC_ERROR . . . . . . . . . . . . . . . . . . 22.4
WARN_IF_UNDOCUMENTED . . . . . . . . . . . . . . . 22.4
WARN_LOGFILE . . . . . . . . . . . . . . . . . . . . . . 22.4
WARN_NO_PARAMDOC . . . . . . . . . . . . . . . . . . 22.4
XML_OUTPUT . . . . . . . . . . . . . . . . . . . . . . .22.12
XML_PROGRAMLISTING . . . . . . . . . . . . . . . . . .22.12
22.2 Project related conguration options
DOXYFILE_ENCODING This tag species the encoding used for all characters in the cong le that follow.
The default is UTF-8 which is also the encoding used for all text before the rst occurrence of this tag.
Doxygen uses libiconv (or the iconv built into libc) for the transcoding. See http://www.gnu.
org/software/libiconv for the list of possible encodings.
The default value is: UTF-8.
PROJECT_NAME The PROJECT_NAME tag is a single word (or a sequence of words surrounded by double-
quotes, unless you are using Doxywizard) that should identify the project for which the documentation is
generated. This name is used in the title of most generated pages and in a few other places.
The default value is: My Project.
PROJECT_NUMBER The PROJECT_NUMBER tag can be used to enter a project or revision number. This could
be handy for archiving the generated documentation or if some version control system is used.
PROJECT_BRIEF Using the PROJECT_BRIEF tag one can provide an optional one line description for a project
that appears at the top of each page and should give viewer a quick idea about the purpose of the project.
Keep the description short.
PROJECT_LOGO With the PROJECT_LOGO tag one can specify an logo or icon that is included in the docu-
mentation. The maximum height of the logo should not exceed 55 pixels and the maximum width should not
exceed 200 pixels. Doxygen will copy the logo to the output directory.
Generated by Doxygen
106 Conguration
OUTPUT_DIRECTORY The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) path into
which the generated documentation will be written. If a relative path is entered, it will be relative to the
location where doxygen was started. If left blank the current directory will be used.
CREATE_SUBDIRS If the CREATE_SUBDIRS tag is set to YES, then doxygen will create 4096 sub-directories
(in 2 levels) under the output directory of each output format and will distribute the generated les over these
directories. Enabling this option can be useful when feeding doxygen a huge amount of source les, where
putting all generated les in the same directory would otherwise causes performance problems for the le
system.
The default value is: NO.
ALLOW_UNICODE_NAMES If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII
characters to appear in the names of generated les. If set to NO, non-ASCII characters will be escaped, for
example _xE3_x81_x84 will be used for Unicode U+3044.
The default value is: NO.
OUTPUT_LANGUAGE The OUTPUT_LANGUAGE tag is used to specify the language in which all documentation
generated by doxygen is written. Doxygen will use this information to generate all constant output in the
proper language.
Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese,
Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States),
Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian, Indonesian,
Italian, Japanese, Japanese-en (Japanese with English messages), Korean, Korean-en
(Korean with English messages), Latvian, Lithuanian, Macedonian, Norwegian, Persian
(Farsi), Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak,
Slovene, Spanish, Swedish, Turkish, Ukrainian and Vietnamese.
The default value is: English.
BRIEF_MEMBER_DESC If the BRIEF_MEMBER_DESC tag is set to YES doxygen will include brief member
descriptions after the members that are listed in the le and class documentation (similar to Javadoc). Set
to NO to disable this.
The default value is: YES.
REPEAT_BRIEF If the REPEAT_BRIEF tag is set to YES doxygen will prepend the brief description of a member
or function before the detailed description
Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the brief descriptions
will be completely suppressed.
The default value is: YES.
ABBREVIATE_BRIEF This tag implements a quasi-intelligent brief description abbreviator that is used to form
the text in various listings. Each string in this list, if found as the leading text of the brief description, will be
stripped from the text and the result, after processing the whole list, is used as the annotated text. Otherwise,
the brief description is used as-is. If left blank, the following values are used ($name is automatically re-
placed with the name of the entity): The $name class, The $name widget, The $name file,
is, provides, specifies, contains, represents, a, an and the.
ALWAYS_DETAILED_SEC If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES
then doxygen will generate a detailed section even if there is only a brief description.
The default value is: NO.
INLINE_INHERITED_MEMB If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
inherited members of a class in the documentation of that class as if those members were ordinary class
members. Constructors, destructors and assignment operators of the base classes will not be shown.
The default value is: NO.
FULL_PATH_NAMES If the FULL_PATH_NAMES tag is set to YES doxygen will prepend the full path before
les name in the le list and in the header les. If set to NO the shortest path that makes the le name unique
will be used
The default value is: YES.
Generated by Doxygen
22.2 Project related conguration options 107
STRIP_FROM_PATH The STRIP_FROM_PATH tag can be used to strip a user-dened part of the path. Strip-
ping is only done if one of the specied strings matches the left-hand part of the path. The tag can be used
to show relative paths in the le list. If left blank the directory from which doxygen is run is used as the path
to strip.
Note that you can specify absolute paths here, but also relative paths, which will be relative from the directory
where doxygen is started.
This tag requires that the tag FULL_PATH_NAMES is set to YES.
STRIP_FROM_INC_PATH The STRIP_FROM_INC_PATH tag can be used to strip a user-dened part of the
path mentioned in the documentation of a class, which tells the reader which header le to include in order
to use a class. If left blank only the name of the header le containing the class denition is used. Otherwise
one should specify the list of include paths that are normally passed to the compiler using the -I ag.
SHORT_NAMES If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter (but less readable)
le names. This can be useful is your le systems doesnt support long names like on DOS, Mac, or CD-ROM.
The default value is: NO.
JAVADOC_AUTOBRIEF If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the rst line
(until the rst dot) of a Javadoc-style comment as the brief description. If set to NO, the Javadoc-style will
behave just like regular Qt-style comments (thus requiring an explicit @brief command for a brief description.)
The default value is: NO.
QT_AUTOBRIEF If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the rst line (until the rst
dot) of a Qt-style comment as the brief description. If set to NO, the Qt-style will behave just like regular
Qt-style comments (thus requiring an explicit \brief command for a brief description.)
The default value is: NO.
MULTILINE_CPP_IS_BRIEF The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen
treat a multi-line C++ special comment block (i.e. a block of //! or /// comments) as a brief description.
This used to be the default behavior. The new default is to treat a multi-line C++ comment block as a detailed
description. Set this tag to YES if you prefer the old behavior instead.
Note that setting this tag to YES also means that rational rose comments are not recognized any more.
The default value is: NO.
INHERIT_DOCS If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the docu-
mentation from any documented member that it re-implements.
The default value is: YES.
SEPARATE_MEMBER_PAGES If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
a new page for each member. If set to NO, the documentation of a member will be part of the le/class/names-
pace that contains it.
The default value is: NO.
TAB_SIZE The TAB_SIZE tag can be used to set the number of spaces in a tab. Doxygen uses this value to
replace tabs by spaces in code fragments.
Minimum value: 1, maximum value: 16, default value: 4.
ALIASES This tag can be used to specify a number of aliases that act as commands in the documentation. An
alias has the form:
name=value
For example adding
"sideeffect=@par Side Effects:\n"
will allow you to put the command \sideeffect (or @sideeffect) in the documentation, which will
result in a user-dened paragraph with heading "Side Effects:". You can put \ns in the value part of an alias
to insert newlines.
Generated by Doxygen
108 Conguration
TCL_SUBST This tag can be used to specify a number of word-keyword mappings (TCL only). A mapping has the
form "name=value". For example adding "class=itcl::class" will allow you to use the command
class in the itcl::class meaning.
OPTIMIZE_OUTPUT_FOR_C Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
sources only. Doxygen will then generate output that is more tailored for C. For instance, some of the names
that are used will be different. The list of all members will be omitted, etc.
The default value is: NO.
OPTIMIZE_OUTPUT_JAVA Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java or
Python sources only. Doxygen will then generate output that is more tailored for that language. For instance,
namespaces will be presented as packages, qualied scopes will look different, etc.
The default value is: NO.
OPTIMIZE_FOR_FORTRAN Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
sources. Doxygen will then generate output that is tailored for Fortran.
The default value is: NO.
OPTIMIZE_OUTPUT_VHDL Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
sources. Doxygen will then generate output that is tailored for VHDL.
The default value is: NO.
EXTENSION_MAPPING Doxygen selects the parser to use depending on the extension of the les it parses. With
this tag you can assign which parser to use for a given extension. Doxygen has a built-in mapping, but you
can override or extend it using this tag. The format is ext=language, where ext is a le extension, and
language is one of the parsers supported by doxygen: IDL, Java, Javascript, C#, C, C++, D, PHP, Objective-C,
Python, Fortran (xed format Fortran: FortranFixed, free formatted Fortran: FortranFree, unknown formatted
Fortran: Fortran. In the later case the parser tries to guess whether the code is xed or free formatted code,
this is the default for Fortran type les), VHDL.
For instance to make doxygen treat .inc les as Fortran les (default is PHP), and .f les as C (default is
Fortran), use: inc=Fortran f=C.
Note For les without extension you can use no_extension as a placeholder.
Note that for custom extensions you also need to set FILE_PATTERNS otherwise the les are not read by
doxygen.
MARKDOWN_SUPPORT If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all com-
ments according to the Markdown format, which allows for more readable documentation. See http
://daringfireball.net/projects/markdown/ for details. The output of markdown processing
is further processed by doxygen, so you can mix doxygen, HTML, and XML commands with Markdown for-
matting. Disable only in case of backward compatibilities issues.
The default value is: YES.
AUTOLINK_SUPPORT When enabled doxygen tries to link words that correspond to documented classes, or
namespaces to their corresponding documentation. Such a link can be prevented in individual cases by by
putting a % sign in front of the word or globally by setting AUTOLINK_SUPPORT to NO.
The default value is: YES.
BUILTIN_STL_SUPPORT If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
to include (a tag le for) the STL sources as input, then you should set this tag to YES in order to let doxy-
gen match functions declarations and denitions whose arguments contain STL classes (e.g. func(std
::string); versus func(std::string) {}). This also make the inheritance and collaboration dia-
grams that involve STL classes more complete and accurate.
The default value is: NO.
CPP_CLI_SUPPORT If you use Microsofts C++/CLI language, you should set this option to YES to enable pars-
ing support.
The default value is: NO.
Generated by Doxygen
22.3 Build related conguration options 109
SIP_SUPPORT Set the SIP_SUPPORT tag to YES if your project consists of sip sources only. Doxygen will
parse them like normal C++ but will assume all classes use public instead of private inheritance when no
explicit protection keyword is present.
The default value is: NO.
IDL_PROPERTY_SUPPORT For Microsofts IDL there are propget and propput attributes to indicate getter
and setter methods for a property. Setting this option to YES will make doxygen to replace the get and set
methods by a property in the documentation. This will only work if the methods are indeed getting or setting
a simple type. If this is not the case, or you want to show the methods anyway, you should set this option to
NO.
The default value is: YES.
DISTRIBUTE_GROUP_DOC If member grouping is used in the documentation and the DISTRIBUTE_GROU
P_DOC tag is set to YES, then doxygen will reuse the documentation of the rst member in the group (if any)
for the other members of the group. By default all members of a group must be documented explicitly.
The default value is: NO.
SUBGROUPING Set the SUBGROUPING tag to YES to allow class member groups of the same type (for instance
a group of public functions) to be put as a subgroup of that type (e.g. under the Public Functions section). Set
it to NO to prevent subgrouping. Alternatively, this can be done per class using the \nosubgrouping command.
The default value is: YES.
INLINE_GROUPED_CLASSES When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs
and unions are shown inside the group in which they are included (e.g. using \ingroup) instead of on a
separate page (for HTML and Man pages) or section (for L
A
T
E
X and RTF).
Note that this feature does not work in combination with SEPARATE_MEMBER_PAGES.
The default value is: NO.
INLINE_SIMPLE_STRUCTS When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and
unions with only public data elds or simple typedef elds will be shown inline in the documentation of the
scope in which they are dened (i.e. le, namespace, or group documentation), provided this scope is docu-
mented. If set to NO, structs, classes, and unions are shown on a separate page (for HTML and Man pages)
or section (for L
A
T
E
X and RTF).
The default value is: NO.
TYPEDEF_HIDES_STRUCT When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union,
or enum is documented as struct, union, or enum with the name of the typedef. So typedef struct
TypeS {} TypeT, will appear in the documentation as a struct with name TypeT. When disabled the
typedef will appear as a member of a le, namespace, or class. And the struct will be named TypeS.
This can typically be useful for C code in case the coding convention dictates that all compound types are
typedefed and only the typedef is referenced, never the tag name.
The default value is: NO.
LOOKUP_CACHE_SIZE The size of the symbol lookup cache can be set using LOOKUP_CACHE_SIZE. This
cache is used to resolve symbols given their name and scope. Since this can be an expensive process and
often the same symbol appears multiple times in the code, doxygen keeps a cache of pre-resolved symbols.
If the cache is too small doxygen will become slower. If the cache is too large, memory is wasted. The
cache size is given by this formula: 2
(16+LOOKUP_CACHE_SIZE)
. The valid range is 0..9, the default is 0,
corresponding to a cache size of 2
16
= 65536 symbols. At the end of a run doxygen will report the cache
usage and suggest the optimal cache size from a speed point of view.
Minimum value: 0, maximum value: 9, default value: 0.
22.3 Build related conguration options
EXTRACT_ALL If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in documentation are
documented, even if no documentation was available. Private class members and static le members will be
hidden unless the EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES.
Generated by Doxygen
110 Conguration
Note
This will also disable the warnings about undocumented members that are normally produced when
WARNINGS is set to YES.
The default value is: NO.
EXTRACT_PRIVATE If the EXTRACT_PRIVATE tag is set to YES all private members of a class will be included
in the documentation.
The default value is: NO.
EXTRACT_PACKAGE If the EXTRACT_PACKAGE tag is set to YES all members with package or internal scope
will be included in the documentation.
The default value is: NO.
EXTRACT_STATIC If the EXTRACT_STATIC tag is set to YES all static members of a le will be included in
the documentation.
The default value is: NO.
EXTRACT_LOCAL_CLASSES If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) de-
ned locally in source les will be included in the documentation. If set to NO only classes dened in header
les are included. Does not have any effect for Java sources.
The default value is: YES.
EXTRACT_LOCAL_METHODS This ag is only useful for Objective-C code. When set to YES local methods,
which are dened in the implementation section but not in the interface are included in the documentation. If
set to NO only methods in the interface are included.
The default value is: NO.
EXTRACT_ANON_NSPACES If this ag is set to YES, the members of anonymous namespaces will be extracted
and appear in the documentation as a namespace called anonymous_namespace{le}, where le will be
replaced with the base name of the le that contains the anonymous namespace. By default anonymous
namespace are hidden.
The default value is: NO.
HIDE_UNDOC_MEMBERS If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all undocumented
members inside documented classes or les. If set to NO these members will be included in the various
overviews, but no documentation section is generated. This option has no effect if EXTRACT_ALL is enabled.
The default value is: NO.
HIDE_UNDOC_CLASSES If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all undocumented
classes that are normally visible in the class hierarchy. If set to NO these classes will be included in the various
overviews. This option has no effect if EXTRACT_ALL is enabled.
The default value is: NO.
HIDE_FRIEND_COMPOUNDS If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend
(class[struct[union) declarations. If set to NO these declarations will be included in the documentation.
The default value is: NO.
HIDE_IN_BODY_DOCS If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any documentation
blocks found inside the body of a function. If set to NO these blocks will be appended to the functions detailed
documentation block.
The default value is: NO.
INTERNAL_DOCS The INTERNAL_DOCS tag determines if documentation that is typed after a \internal com-
mand is included. If the tag is set to NO then the documentation will be excluded. Set it to YES to include the
internal documentation.
The default value is: NO.
Generated by Doxygen
22.3 Build related conguration options 111
CASE_SENSE_NAMES If the CASE_SENSE_NAMES tag is set to NO then doxygen will only generate le names
in lower-case letters. If set to YES upper-case letters are also allowed. This is useful if you have classes or
les whose names only differ in case and if your le system supports case sensitive le names. Windows and
Mac users are advised to set this option to NO.
The default value is: system dependent.
HIDE_SCOPE_NAMES If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with their
full class and namespace scopes in the documentation. If set to YES the scope will be hidden.
The default value is: NO.
SHOW_INCLUDE_FILES If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of the
les that are included by a le in the documentation of that le.
The default value is: YES.
SHOW_GROUPED_MEMB_INC If the SHOW_GROUPED_MEMB_INC tag is set to YES then Doxygen will add for
each grouped member an include statement to the documentation, telling the reader which le to include in
order to use the member.
The default value is: NO.
FORCE_LOCAL_INCLUDES If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include
les with double quotes in the documentation rather than with sharp brackets.
The default value is: NO.
INLINE_INFO If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the documentation for
inline members.
The default value is: YES.
SORT_MEMBER_DOCS If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the (detailed) doc-
umentation of le and class members alphabetically by member name. If set to NO the members will appear
in declaration order.
The default value is: YES.
SORT_BRIEF_DOCS If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief descriptions
of le, namespace and class members alphabetically by member name. If set to NO the members will appear
in declaration order. Note that this will also inuence the order of the classes in the class list.
The default value is: NO.
SORT_MEMBERS_CTORS_1ST If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort
the (brief and detailed) documentation of class members so that constructors and destructors are listed rst.
If set to NO the constructors will appear in the respective orders dened by SORT_BRIEF_DOCS and SO
RT_MEMBER_DOCS.
Note
If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief member documentation.
If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting detailed member documentation.
The default value is: NO.
SORT_GROUP_NAMES If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy of
group names into alphabetical order. If set to NO the group names will appear in their dened order.
The default value is: NO.
SORT_BY_SCOPE_NAME If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by fully-
qualied names, including namespaces. If set to NO, the class list will be sorted only by class name, not
including the namespace part.
Generated by Doxygen
112 Conguration
Note
This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
This option applies only to the class list, not to the alphabetical list.
The default value is: NO.
STRICT_PROTO_MATCHING If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to do
proper type resolution of all parameters of a function it will reject a match between the prototype and the
implementation of a member function even if there is only one candidate or it is obvious which candidate to
choose by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen will still accept
a match between prototype and implementation in such cases.
The default value is: NO.
GENERATE_TODOLIST The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo
list. This list is created by putting \todo commands in the documentation.
The default value is: YES.
GENERATE_TESTLIST The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test
list. This list is created by putting \test commands in the documentation.
The default value is: YES.
GENERATE_BUGLIST The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug list.
This list is created by putting \bug commands in the documentation.
The default value is: YES.
GENERATE_DEPRECATEDLIST The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
disable (NO) the deprecated list. This list is created by putting \deprecated commands in the documentation.
The default value is: YES.
ENABLED_SECTIONS The ENABLED_SECTIONS tag can be used to enable conditional documentation sec-
tions, marked by \if <section_label> ... \endif and \cond <section_label> ... \endcond blocks.
MAX_INITIALIZER_LINES The MAX_INITIALIZER_LINES tag determines the maximum number of
lines that the initial value of a variable or macro / dene can have for it to appear in the documentation.
If the initializer consists of more lines than specied here it will be hidden. Use a value of 0 to hide initializers
completely. The appearance of the value of individual variables and macros / denes can be controlled using
\showinitializer or \hideinitializer command in the documentation regardless of this setting.
Minimum value: 0, maximum value: 10000, default value: 30.
SHOW_USED_FILES Set the SHOW_USED_FILES tag to NO to disable the list of les generated at the bottom
of the documentation of classes and structs. If set to YES the list will mention the les that were used to
generate the documentation.
The default value is: YES.
SHOW_FILES Set the SHOW_FILES tag to NO to disable the generation of the Files page. This will remove the
Files entry from the Quick Index and from the Folder Tree View (if specied).
The default value is: YES.
SHOW_NAMESPACES Set the SHOW_NAMESPACES tag to NO to disable the generation of the Namespaces
page. This will remove the Namespaces entry from the Quick Index and from the Folder Tree View (if speci-
ed).
The default value is: YES.
FILE_VERSION_FILTER The FILE_VERSION_FILTER tag can be used to specify a program or script that
doxygen should invoke to get the current version for each le (typically from the version control system).
Doxygen will invoke the program by executing (via popen()) the command command input-file,
where command is the value of the FILE_VERSION_FILTER tag, and input-file is the name of an
input le provided by doxygen. Whatever the program writes to standard output is used as the le version.
Example of using a shell script as a lter for Unix:
FILE_VERSION_FILTER = "/bin/sh versionfilter.sh"
Generated by Doxygen
22.4 Conguration options related to warning and progress messages 113
Example shell script for CVS:
#!/bin/sh
cvs status $1 | sed -n s/^[ \]
*
Working revision:[ \t]
*
\([0-9][0-9\.]
*
\).
*
/\1/p
Example shell script for Subversion:
#!/bin/sh
svn stat -v $1 | sed -n s/^[ A-Z?\
*
|!]\{1,15\}/r/;s/ \{1,15\}/\/r/;s/ .
*
//p
Example lter for ClearCase:
FILE_VERSION_INFO = "cleartool desc -fmt \%Vn"
LAYOUT_FILE The LAYOUT_FILE tag can be used to specify a layout le which will be parsed by doxygen.
The layout le controls the global structure of the generated output les in an output format independent
way. To create the layout le that represents doxygens defaults, run doxygen with the -l option. You can
optionally specify a le name after the option, if omitted DoxygenLayout.xml will be used as the name
of the layout le.
Note that if you run doxygen from a directory containing a le called DoxygenLayout.xml, doxygen will
parse it automatically even if the LAYOUT_FILE tag is left empty.
CITE_BIB_FILES The CITE_BIB_FILES tag can be used to specify one or more bib les containing the
reference denitions. This must be a list of .bib les. The .bib extension is automatically appended if omit-
ted. This requires the bibtex tool to be installed. See also http://en.wikipedia.org/wiki/
BibTeX for more info. For L
A
T
E
X the style of the bibliography can be controlled using LATEX_BIB_STYLE.
To use this feature you need bibtex and perl available in the search path. See also \cite for info how to
create references.
22.4 Conguration options related to warning and progress messages
QUIET The QUIET tag can be used to turn on/off the messages that are generated to standard output by doxygen.
If QUIET is set to YES this implies that the messages are off.
The default value is: NO.
WARNINGS The WARNINGS tag can be used to turn on/off the warning messages that are generated to standard
error (stderr) by doxygen. If WARNINGS is set to YES this implies that the warnings are on.
Tip: Turn warnings on while writing the documentation.
The default value is: YES.
WARN_IF_UNDOCUMENTED If the WARN_IF_UNDOCUMENTED tag is set to YES, then doxygen will generate
warnings for undocumented members. If EXTRACT_ALL is set to YES then this ag will automatically be
disabled.
The default value is: YES.
WARN_IF_DOC_ERROR If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for
potential errors in the documentation, such as not documenting some parameters in a documented function,
or documenting parameters that dont exist or using markup commands wrongly.
The default value is: YES.
WARN_NO_PARAMDOC This WARN_NO_PARAMDOC option can be enabled to get warnings for functions that are
documented, but have no documentation for their parameters or return value. If set to NO doxygen will only
warn about wrong or incomplete parameter documentation, but not about the absence of documentation.
The default value is: NO.
Generated by Doxygen
114 Conguration
WARN_FORMAT The WARN_FORMAT tag determines the format of the warning messages that doxygen can pro-
duce. The string should contain the $file, $line, and $text tags, which will be replaced by the le
and line number from which the warning originated and the warning text. Optionally the format may contain
$version, which will be replaced by the version of the le (if it could be obtained via FILE_VERSION_FI
LTER)
The default value is: $file:$line: $text.
WARN_LOGFILE The WARN_LOGFILE tag can be used to specify a le to which warning and error messages
should be written. If left blank the output is written to standard error (stderr).
22.5 Conguration options related to the input les
INPUT The INPUT tag is used to specify the les and/or directories that contain documented source les. You
may enter le names like myfile.cpp or directories like /usr/src/myproject. Separate the les or
directories with spaces.
Note
If this tag is empty the current directory is searched.
INPUT_ENCODING This tag can be used to specify the character encoding of the source les that doxygen
parses. Internally doxygen uses the UTF-8 encoding. Doxygen uses libiconv (or the iconv built into
libc) for the transcoding. See the libiconv documentation for the list of possible encodings.
The default value is: UTF-8.
FILE_PATTERNS If the value of the INPUT tag contains directories, you can use the FILE_PATTERNS tag
to specify one or more wildcard patterns (like .cpp and .h) to lter out the source-les in the directo-
ries. If left blank the following patterns are tested: .c, .cc, .cxx, .cpp, .c++, .java, .ii,
.ixx, .ipp, .i++, .inl, .idl, .ddl, .odl, .h, .hh, .hxx, .hpp, .h++, .cs,
.d, .php, .php4, .php5, .phtml, .inc, .m, .markdown, .md, .mm, .dox, .py,
.f90, .f, .for, .tcl, .vhd, .vhdl, .ucf, .qsf, .as and .js.
RECURSIVE The RECURSIVE tag can be used to specify whether or not subdirectories should be searched for
input les as well.
The default value is: NO.
EXCLUDE The EXCLUDE tag can be used to specify les and/or directories that should be excluded from the IN
PUT source les. This way you can easily exclude a subdirectory from a directory tree whose root is specied
with the INPUT tag.
Note that relative paths are relative to the directory from which doxygen is run.
EXCLUDE_SYMLINKS The EXCLUDE_SYMLINKS tag can be used to select whether or not les or directories
that are symbolic links (a Unix le system feature) are excluded from the input.
The default value is: NO.
EXCLUDE_PATTERNS If the value of the INPUT tag contains directories, you can use the EXCLUDE_PATTE
RNS tag to specify one or more wildcard patterns to exclude certain les from those directories.
Note that the wildcards are matched against the le with absolute path, so to exclude all test directories for
example use the pattern /test/
EXCLUDE_SYMBOLS The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names (names-
paces, classes, functions, etc.) that should be excluded from the output. The symbol name can be a fully
qualied name, a word, or if the wildcard is used, a substring. Examples: ANamespace, AClass, A
Class::ANamespace, ANamespace::Test
Note that the wildcards are matched against the le with absolute path, so to exclude all test directories use
the pattern /test/
EXAMPLE_PATH The EXAMPLE_PATH tag can be used to specify one or more les or directories that contain
example code fragments that are included (see the \include command).
Generated by Doxygen
22.6 Conguration options related to source browsing 115
EXAMPLE_PATTERNS If the value of the EXAMPLE_PATH tag contains directories, you can use the EXAMPL
E_PATTERNS tag to specify one or more wildcard pattern (like .cpp and .h) to lter out the source-les
in the directories. If left blank all les are included.
EXAMPLE_RECURSIVE If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be searched for
input les to be used with the \include or \dontinclude commands irrespective of the value of the RECURSIVE
tag.
The default value is: NO.
IMAGE_PATH The IMAGE_PATH tag can be used to specify one or more les or directories that contain images
that are to be included in the documentation (see the \image command).
INPUT_FILTER The INPUT_FILTER tag can be used to specify a program that doxygen should invoke to lter
for each input le. Doxygen will invoke the lter program by executing (via popen()) the command:
<filter> <input-file>
where <filter> is the value of the INPUT_FILTER tag, and <input-file> is the name of an input
le. Doxygen will then use the output that the lter program writes to standard output. If FILTER_PATTERNS
is specied, this tag will be ignored.
Note that the lter must not add or remove lines; it is applied before the code is scanned, but not when the
output code is generated. If lines are added or removed, the anchors will not be placed correctly.
FILTER_PATTERNS The FILTER_PATTERNS tag can be used to specify lters on a per le pattern basis.
Doxygen will compare the le name with each pattern and apply the lter if there is a match. The lters are a
list of the form: pattern=lter (like .cpp=my_cpp_filter). See INPUT_FILTER for further information
on how lters are used. If the FILTER_PATTERNS tag is empty or if none of the patterns match the le
name, INPUT_FILTER is applied.
FILTER_SOURCE_FILES If the FILTER_SOURCE_FILES tag is set to YES, the input lter (if set using IN
PUT_FILTER ) will also be used to lter the input les that are used for producing the source les to browse
(i.e. when SOURCE_BROWSER is set to YES).
The default value is: NO.
FILTER_SOURCE_PATTERNS The FILTER_SOURCE_PATTERNS tag can be used to specify source lters
per le pattern. A pattern will override the setting for FILTER_PATTERN (if any) and it is also possible to
disable source ltering for a specic pattern using .ext= (so without naming a lter).
This tag requires that the tag FILTER_SOURCE_FILES is set to YES.
USE_MDFILE_AS_MAINPAGE If the USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown
le that is part of the input, its contents will be placed on the main page (index.html). This can be useful
if you have a project on for instance GitHub and want to reuse the introduction page also for the doxygen
output.
22.6 Conguration options related to source browsing
SOURCE_BROWSER If the SOURCE_BROWSER tag is set to YES then a list of source les will be generated.
Documented entities will be cross-referenced with these sources.
Note: To get rid of all source code in the generated output, make sure that also VERBATIM_HEADERS is set
to NO.
The default value is: NO.
INLINE_SOURCES Setting the INLINE_SOURCES tag to YES will include the body of functions, classes and
enums directly into the documentation.
The default value is: NO.
STRIP_CODE_COMMENTS Setting the STRIP_CODE_COMMENTS tag to YES will instruct doxygen to hide any
special comment blocks from generated source code fragments. Normal C, C++ and Fortran comments will
always remain visible.
The default value is: YES.
Generated by Doxygen
116 Conguration
REFERENCED_BY_RELATION If the REFERENCED_BY_RELATION tag is set to YES then for each docu-
mented function all documented functions referencing it will be listed.
The default value is: NO.
REFERENCES_RELATION If the REFERENCES_RELATION tag is set to YES then for each documented func-
tion all documented entities called/used by that function will be listed.
The default value is: NO.
REFERENCES_LINK_SOURCE If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BRO
WSER tag is set to YES, then the hyperlinks from functions in REFERENCES_RELATION and REFEREN
CED_BY_RELATION lists will link to the source code. Otherwise they will link to the documentation.
The default value is: YES.
SOURCE_TOOLTIPS If SOURCE_TOOLTIPS is enabled (the default) then hovering a hyperlink in the source
code will show a tooltip with additional information such as prototype, brief description and links to the deni-
tion and documentation. Since this will make the HTML le larger and loading of large les a bit slower, you
can opt to disable this feature.
The default value is: YES.
This tag requires that the tag SOURCE_BROWSER is set to YES.
USE_HTAGS If the USE_HTAGS tag is set to YES then the references to source code will point to the HTML
generated by the htags(1) tool instead of doxygen built-in source browser. The htags tool is part of
GNUs global source tagging system (see http://www.gnu.org/software/global/global.
html). You will need version 4.8.6 or higher.
To use it do the following:
1. Install the latest version of global
2. Enable SOURCE_BROWSER and USE_HTAGS in the cong le
3. Make sure the INPUT points to the root of the source tree
4. Run doxygen as normal
Doxygen will invoke htags (and that will in turn invoke gtags), so these tools must be available from
the command line (i.e. in the search path).
The result: instead of the source browser generated by doxygen, the links to source code will now point
to the output of htags.
The default value is: NO.
This tag requires that the tag SOURCE_BROWSER is set to YES.
VERBATIM_HEADERS If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a verbatim
copy of the header le for each class for which an include is specied. Set to NO to disable this.
See also
Section \class.
The default value is: YES.
CLANG_ASSISTED_PARSING If the CLANG_ASSISTED_PARSING tag is set to YES, then doxygen will use
the clang parser for more accurate parsing at the cost of reduced performance. This can be particularly
helpful with template rich C++ code for which doxygens built-in parser lacks the necessary type information.
Note
The availability of this option depends on whether or not doxygen was compiled with the
--with-libclang option.
The default value is: NO.
CLANG_OPTIONS If clang assisted parsing is enabled you can provide the compiler with command line options
that you would normally use when invoking the compiler. Note that the include paths will already be set by
doxygen for the les and directories specied with INPUT and INCLUDE_PATH.
This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES.
Generated by Doxygen
22.7 Conguration options related to the alphabetical class index 117
22.7 Conguration options related to the alphabetical class index
ALPHABETICAL_INDEX If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all com-
pounds will be generated. Enable this if the project contains a lot of classes, structs, unions or interfaces.
The default value is: YES.
COLS_IN_ALPHA_INDEX The COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
in which the alphabetical index list will be split.
Minimum value: 1, maximum value: 20, default value: 5.
This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
IGNORE_PREFIX In case all classes in a project start with a common prex, all classes will be put under the
same header in the alphabetical index. The IGNORE_PREFIX tag can be used to specify a prex (or a list
of prexes) that should be ignored while generating the index headers.
This tag requires that the tag ALPHABETICAL_INDEX is set to YES.
22.8 Conguration options related to the HTML output
GENERATE_HTML If the GENERATE_HTML tag is set to YES doxygen will generate HTML output
The default value is: YES.
HTML_OUTPUT The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a relative path is
entered the value of OUTPUT_DIRECTORY will be put in front of it.
The default directory is: html.
This tag requires that the tag GENERATE_HTML is set to YES.
HTML_FILE_EXTENSION The HTML_FILE_EXTENSION tag can be used to specify the le extension for
each generated HTML page (for example: .htm, .php, .asp).
The default value is: .html.
This tag requires that the tag GENERATE_HTML is set to YES.
HTML_HEADER The HTML_HEADER tag can be used to specify a user-dened HTML header le for each gen-
erated HTML page. If the tag is left blank doxygen will generate a standard header.
To get valid HTML the header le that includes any scripts and style sheets that doxygen needs, which is
dependent on the conguration options used (e.g. the setting GENERATE_TREEVIEW). It is highly recom-
mended to start with a default header using
doxygen -w html new_header.html new_footer.html new_stylesheet.css YourConfigFile
and then modify the le new_header.html.
See also section Doxygen usage for information on how to generate the default header that doxygen normally
uses.
Note
The header is subject to change so you typically have to regenerate the default header when upgrading
to a newer version of doxygen. The following markers have a special meaning inside the header and
footer:
$title will be replaced with the title of the page.
$datetime will be replaced with current the date and time.
$date will be replaced with the current date.
$year will be replaces with the current year.
$doxygenversion will be replaced with the version of doxygen
$projectname will be replaced with the name of the project (see PROJECT_NAME)
$projectnumber will be replaced with the project number (see PROJECT_NUMBER)
$projectbrief will be replaced with the project brief description (see PROJECT_BRIEF)
Generated by Doxygen
118 Conguration
$projectlogo will be replaced with the project logo (see PROJECT_LOGO)
$treeview will be replaced with links to the javascript and style sheets needed for the navigation tree
(or an empty string when GENERATE_TREEVIEW is disabled).
$search will be replaced with a links to the javascript and style sheets needed for the search engine
(or an empty string when SEARCHENGINE is disabled).
$mathjax will be replaced with a links to the javascript and style sheets needed for the MathJax feature
(or an empty string when USE_MATHJAX is disabled).
$relpath
doxygen.css, to
refer to the standard style sheet.
To cope with differences in the layout of the header and footer that depend on conguration settings, the
header can also contain special blocks that will be copied to the output or skipped depending on the congu-
ration. Such blocks have the following form:
<!--BEGIN BLOCKNAME-->
Some context copied when condition BLOCKNAME holds
<!--END BLOCKNAME-->
<!--BEGIN !BLOCKNAME-->
Some context copied when condition BLOCKNAME does not hold
<!--END !BLOCKNAME-->
The following block names are supported:
DISABLE_INDEX Content within this block is copied to the output when the DISABLE_INDEX option is
enabled (so when the index is disabled).
GENERATE_TREEVIEW Content within this block is copied to the output when the GENERATE_TREEVI
EW option is enabled.
SEARCHENGINE Content within this block is copied to the output when the SEARCHENGINE option is
enabled.
PROJECT_NAME Content within the block is copied to the output when the PROJECT_NAME option is not
empty.
PROJECT_NUMBER Content within the block is copied to the output when the PROJECT_NUMBER option
is not empty.
PROJECT_BRIEF Content within the block is copied to the output when the PROJECT_BRIEF option is
not empty.
PROJECT_LOGO Content within the block is copied to the output when the PROJECT_LOGO option is not
empty.
TITLEAREA Content within this block is copied to the output when a title is visible at the top of each page.
This is the case if either PROJECT_NAME, PROJECT_BRIEF, PROJECT_LOGO is lled in or if both
DISABLE_INDEX and SEARCHENGINE are enabled.
This tag requires that the tag GENERATE_HTML is set to YES.
HTML_FOOTER The HTML_FOOTER tag can be used to specify a user-dened HTML footer for each generated
HTML page. If the tag is left blank doxygen will generate a standard footer.
See HTML_HEADER for more information on how to generate a default footer and what special commands
can be used inside the footer.
See also section Doxygen usage for information on how to generate the default footer that doxygen normally
uses.
This tag requires that the tag GENERATE_HTML is set to YES.
HTML_STYLESHEET The HTML_STYLESHEET tag can be used to specify a user-dened cascading style sheet
that is used by each HTML page. It can be used to ne-tune the look of the HTML output. If left blank doxygen
will generate a default style sheet.
See also section Doxygen usage for information on how to generate the style sheet that doxygen normally
uses.
Generated by Doxygen
22.8 Conguration options related to the HTML output 119
Note
It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as it is more robust and this
tag (HTML_STYLESHEET) will in the future become obsolete.
This tag requires that the tag GENERATE_HTML is set to YES.
HTML_EXTRA_STYLESHEET The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-
dened cascading style sheets that are included after the standard style sheets created by doxygen. Using
this option one can overrule certain style aspects. This is preferred over using HTML_STYLESHEET since it
does not replace the standard style sheet and is therefor more robust against future updates. Doxygen will
copy the style sheet les to the output directory.
Note
The order of the extra stylesheet les is of importance (e.g. the last stylesheet in the list overrules the
setting of the previous ones in the list). Here is an example stylesheet that gives the contents area a xed
width:
body {
background-color: #CCC;
color: black;
margin: 0;
}
div.contents {
margin-bottom: 10px;
padding: 12px;
margin-left: auto;
margin-right: auto;
width: 960px;
background-color: white;
border-radius: 8px;
}
#titlearea {
background-color: white;
}
hr.footer {
display: none;
}
.footer {
background-color: #AAA;
}
This tag requires that the tag GENERATE_HTML is set to YES.
HTML_EXTRA_FILES The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
other source les which should be copied to the HTML output directory. Note that these les will be copied to
the base HTML output directory. Use the $relpath
=
≈ almost equal to = asymptotic to:
≠ not equal to: ,=
≡ identical to:
≤ less-than or equal to:
≥ greater-than or equal to:
⊂ subset of:
⊃ superset of:
⊄ not a subset of: ,
⊆ subset of or equal to:
⊇ superset of or equal to:
⊕ circled plus = direct sum:
⊗ circled times = vector product:
⊥ up tack = orthogonal to = perpendicular:
⋅ dot operator:
⌈ left ceiling = apl upstile: ,
⌉ right ceiling: |
⌊ left oor = apl downstile:
⌋ right oor: |
⟨ left-pointing angle bracket = bra:
⟩ right-pointing angle bracket = ket:
◊ lozenge:
♠ black spade suit:
♣ black club suit = shamrock:
♥ black heart suit = valentine:
♦ black diamond suit:
" quotation mark = APL quote: "
& ampersand: &
< less-than sign: <
> greater-than sign: >
Œ latin capital ligature OE:
œ latin small ligature oe:
Š latin capital letter S with caron:
š latin small letter s with caron:
Ÿ latin capital letter Y with diaeresis:
ˆ modier letter circumex accent:
Generated by Doxygen
192 HTML commands
˜ small tilde:
  en space:
  em space:
  thin space:
‌ zero width non-joiner:
‍ zero width joiner:
‎ left-to-right mark:
‏ right-to-left mark:
– en dash:
— em dash:
‘ left single quotation mark:
’ right single quotation mark:
‚ single low-9 quotation mark:
“ left double quotation mark:
” right double quotation mark:
„ double low-9 quotation mark:
† dagger:
‡ double dagger:
‰ per mille sign:
‹ single left-pointing angle quotation mark:
› single right-pointing angle quotation mark:
€ euro sign: C
Doxygen extensions:
&tm; trade mark sign:
' apostrophe:
Finally, to put invisible comments inside comment blocks, HTML style comments can be used:
/
*
! <!-- This is a comment with a comment block --> Visible text
*
/
Generated by Doxygen
Chapter 25
XML commands
Doxygen supports most of the XML commands that are typically used in C# code comments. The XML tags are
dened in Appendix E of the ECMA-334 standard, which denes the C# language. Unfortunately, the specication
is not very precise and a number of the examples given are of poor quality.
Here is the list of tags supported by doxygen:
<c> Identies inline text that should be rendered as a piece of code. Similar to using <tt>text</tt>.
<code> Set one or more lines of source code or program output. Note that this command behaves like
\code ... \endcode for C# code, but it behaves like the HTML equivalent <code>...</code> for other
languages.
<description> Part of a <list> command, describes an item.
<example> Marks a block of text as an example, ignored by doxygen.
<exception cref="member"> Identies the exception a method can throw.
<include>Can be used to import a piece of XML froman external le. Ignored by doxygen at the moment.
<inheritdoc> Can be used to insert the documentation of a member of a base class into the documen-
tation of a member of a derived class that reimplements it.
<item> List item. Can only be used inside a <list> context.
<list type="type"> Starts a list, supported types are bullet or number and table. A list con-
sists of a number of <item> tags. A list of type table, is a two column table which can have a header.
<listheader> Starts the header of a list of type "table".
<para> Identies a paragraph of text.
<param name="paramName"> Marks a piece of text as the documentation for parameter "param
Name". Similar to using \param.
<paramref name="paramName"> Refers to a parameter with name "paramName". Similar to using
\a.
<permission> Identies the security accessibility of a member. Ignored by doxygen.
<remarks> Identies the detailed description.
<returns> Marks a piece of text as the return value of a function or method. Similar to using \return.
<see cref="member"> Refers to a member. Similar to \ref.
<seealso cref="member"> Starts a "See also" section referring to "member". Similar to using \sa
member.
194 XML commands
<summary> Identies the brief description. Similar to using \brief.
<term> Part of a <list> command.
<typeparam name="paramName"> Marks a piece of text as the documentation for type parameter
"paramName". Similar to using \param.
<typeparamref name="paramName"> Refers to a parameter with name "paramName". Similar to
using \a.
<value> Identies a property. Ignored by doxygen.
Here is an example of a typical piece of code using some of the above commands:
/// <summary>
/// A search engine.
/// </summary>
class Engine
{
/// <summary>
/// The Search method takes a series of parameters to specify the search criterion
/// and returns a dataset containing the result set.
/// </summary>
/// <param name="connectionString">the connection string to connect to the
/// database holding the content to search</param>
/// <param name="maxRows">The maximum number of rows to
/// return in the result set</param>
/// <param name="searchString">The text that we are searching for</param>
/// <returns>A DataSet instance containing the matching rows. It contains a maximum
/// number of rows specified by the maxRows parameter</returns>
public DataSet Search(string connectionString, int maxRows, int searchString)
{
DataSet ds = new DataSet();
return ds;
}
}
Generated by Doxygen
Part III
Developers Manual
Chapter 26
Doxygens internals
Doxygens internals
Note that this section is still under construction!
The following picture shows how source les are processed by doxygen.
Config parser
Language parser C Preprocessor
HTML
LaTeX
RTF
XML
input
string
entry
tree
input files
Man
config file
drives
drives
get settings
entry
tree
drives
drives
tag file parser
Doc Parser
Source Parser
Data organiser Output generators
drives
Figure 26.1: Data ow overview
The following sections explain the steps above in more detail.
Cong parser
The conguration le that controls the settings of a project is parsed and the settings are stored in the singleton
class Config in src/config.h. The parser itself is written using flex and can be found in src/config.l.
This parser is also used directly by doxywizard, so it is put in a separate library.
Each conguration option has one of 5 possible types: String, List, Enum, Int, or Bool. The values of these
198 Doxygens internals
options are available through the global functions Config_getXXX(), where XXX is the type of the option.
The argument of these function is a string naming the option as it appears in the conguration le. For instance:
Config_getBool("GENERATE_TESTLIST") returns a reference to a boolean value that is TRUE if the test list
was enabled in the cong le.
The function readConfiguration() in src/doxygen.cpp reads the command line options and then calls
the conguration parser.
C Preprocessor
The input les mentioned in the cong le are (by default) fed to the C Preprocessor (after being piped through a
user dened lter if available).
The way the preprocessor works differs somewhat from a standard C Preprocessor. By default it does not do macro
expansion, although it can be congured to expand all macros. Typical usage is to only expand a user specied set
of macros. This is to allow macro names to appear in the type of function parameters for instance.
Another difference is that the preprocessor parses, but not actually includes code when it encounters a #include
(with the exception of #include found inside { ... } blocks). The reasons behind this deviation from the standard
is to prevent feeding multiple denitions of the same functions/classes to doxygens parser. If all source les would
include a common header le for instance, the class and type denitions (and their documentation) would be present
in each translation unit.
The preprocessor is written using flex and can be found in src/pre.l. For condition blocks (#if) evaluation of
constant expressions is needed. For this a yacc based parser is used, which can be found in src/constexp.y
and src/constexp.l.
The preprocessor is invoked for each le using the preprocessFile() function declared in src/pre.h, and
will append the preprocessed result to a character buffer. The format of the character buffer is
0x06 file name 1
0x06 preprocessed contents of file 1
...
0x06 file name n
0x06 preprocessed contents of file n
Language parser
The preprocessed input buffer is fed to the language parser, which is implemented as a big state machine using
flex. It can be found in the le src/scanner.l. There is one parser for all languages (C/C++/Java/IDL). The
state variables insideIDL and insideJava are uses at some places for language specic choices.
The task of the parser is to convert the input buffer into a tree of entries (basically an abstract syntax tree). An entry
is dened in src/entry.h and is a blob of loosely structured information. The most important eld is section
which species the kind of information contained in the entry.
Possible improvements for future versions:
Use one scanner/parser per language instead of one big scanner.
Move the rst pass parsing of documentation blocks to a separate module.
Parse denes (these are currently gathered by the preprocessor, and ignored by the language parser).
Data organizer
This step consists of many smaller steps, that build dictionaries of the extracted classes, les, namespaces, vari-
ables, functions, packages, pages, and groups. Besides building dictionaries, during this step relations (such as
inheritance relations), between the extracted entities are computed.
Each step has a function dened in src/doxygen.cpp, which operates on the tree of entries, built during
language parsing. Look at the "Gathering information" part of parseInput() for details.
Generated by Doxygen
199
The result of this step is a number of dictionaries, which can be found in the Doxygen "namespace" dened in
src/doxygen.h. Most elements of these dictionaries are derived from the class Definition; The class
MemberDef, for instance, holds all information for a member. An instance of such a class can be part of a le (
class FileDef ), a class ( class ClassDef ), a namespace ( class NamespaceDef ), a group ( class Group
Def ), or a Java package ( class PackageDef ).
Tag le parser
If tag les are specied in the conguration le, these are parsed by a SAX based XML parser, which can be found
in src/tagreader.cpp. The result of parsing a tag le is the insertion of Entry objects in the entry tree. The
eld Entry::tagInfo is used to mark the entry as external, and holds information about the tag le.
Documentation parser
Special comment blocks are stored as strings in the entities that they document. There is a string for the brief
description and a string for the detailed description. The documentation parser reads these strings and executes
the commands it nds in it (this is the second pass in parsing the documentation). It writes the result directly to the
output generators.
The parser is written in C++ and can be found in src/docparser.cpp. The tokens that are eaten by the parser come
from src/doctokenizer.l. Code fragments found in the comment blocks are passed on to the source parser.
The main entry point for the documentation parser is validatingParseDoc() declared in src/docparser.
h. For simple texts with special commands validatingParseText() is used.
Source parser
If source browsing is enabled or if code fragments are encountered in the documentation, the source parser is
invoked.
The code parser tries to cross-reference to source code it parses with documented entities. It also does syntax
highlighting of the sources. The output is directly written to the output generators.
The main entry point for the code parser is parseCode() declared in src/code.h.
Output generators
After data is gathered and cross-referenced, doxygen generates output in various formats. For this it uses the
methods provided by the abstract class OutputGenerator. In order to generate output for multiple formats at
once, the methods of OutputList are called instead. This class maintains a list of concrete output generators,
where each method called is delegated to all generators in the list.
To allow small deviations in what is written to the output for each concrete output generator, it is possible to tem-
porarily disable certain generators. The OutputList class contains various disable() and enable() methods
for this. The methods OutputList::pushGeneratorState() and OutputList::popGenerator
State() are used to temporarily save the set of enabled/disabled output generators on a stack.
The XML is generated directly from the gathered data structures. In the future XML will be used as an intermediate
language (IL). The output generators will then use this IL as a starting point to generate the specic output formats.
The advantage of having an IL is that various independently developed tools written in various languages, could
extract information from the XML output. Possible tools could be:
an interactive source browser
a class diagram generator
computing code metrics.
Generated by Doxygen
200 Doxygens internals
Debugging
Since doxygen uses a lot of flex code it is important to understand how flex works (for this one should read
the man page) and to understand what it is doing when flex is parsing some input. Fortunately, when ex is used
with the -d option it outputs what rules matched. This makes it quite easy to follow what is going on for a particular
input fragment.
To make it easier to toggle debug information for a given ex le I wrote the following perl script, which automatically
adds or removes -d from the correct line in the Makefile:
#!/usr/bin/perl
$file = shift @ARGV;
print "Toggle debugging mode for $file\n";
# add or remove the -d flex flag in the makefile
unless (rename "Makefile.libdoxygen","Makefile.libdoxygen.old") {
print STDERR "Error: cannot rename Makefile.libdoxygen!\n";
exit 1;
}
if (open(F,"<Makefile.libdoxygen.old")) {
unless (open(G,">Makefile.libdoxygen")) {
print STDERR "Error: opening file Makefile.libdoxygen for writing\n";
exit 1;
}
print "Processing Makefile.libdoxygen...\n";
while (<F>) {
if ( s/\(LEX\) (-i )?-P([a-zA-Z]+)YY -t $file/(LEX) -d \1-P\2YY -t $file/g ) {
print "Enabling debug info for $file\n";
}
elsif ( s/\(LEX\) -d (-i )?-P([a-zA-Z]+)YY -t $file/(LEX) \1-P\2YY -t $file/g ) {
print "Disabling debug info for $file\n";
}
print G "$_";
}
close F;
unlink "Makefile.libdoxygen.old";
}
else {
print STDERR "Warning file Makefile.libdoxygen.old does not exist!\n";
}
# touch the file
$now = time;
utime $now, $now, $file
Another way to get rules matching / debugging information from the ex code is in the following way:
touch src/<flex code file>.l
make LEX="flex -d"
to remove the rules / debug information again:
touch src/<flex codefile>.l
make
Note that by running doxygen with -d lex you get information about which ex codele is used.
Generated by Doxygen
Chapter 27
Perl Module Output format
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 L
A
T
E
X
generator.
Please report any bugs or problems you nd in the Perl Module backend or the Perl Module-based L
A
T
E
X generator
to the doxygen-develop mailing list. Suggestions are welcome as well.
27.1 Usage
When the GENERATE_PERLMOD tag is enabled in the Doxyle, running Doxygen generates a number of les in
the perlmod/ subdirectory of your output directory. These les 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 le contains the make rules to build and clean the les that are generated from
the Doxyle. Also contains the paths to those les and other relevant information. This le is intended to be
included by your own Makele.
Makefile: This is a simple Makele 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 L
A
T
E
X generator, see below) or
write your own customized generator. This should not be too hard if you have some knowledge of Perl and its the
main purpose of including the Perl Module backend in Doxygen. See below for details on how to do this.
< want to use L
A
T
E
X but not possible in headings >
27.2 Using the LaTeX generator.
The Perl Module-based L
A
T
E
X generator is pretty experimental and incomplete at the moment, but you could nd it
useful nevertheless. It can generate documentation for functions, typedefs and variables within les and classes
202 Perl Module Output format
and can be customized quite a lot by redening T
E
X 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 les in the
perlmod/ subdirectory of your output directory. These les contain the Perl scripts and L
A
T
E
X 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 les are also added to doxyrules.make and the Makefile.
The additional generated les are the following:
doxylatex.pl: This Perl script uses DoxyDocs.pm and DoxyModel.pm to generate doxydocs.tex,
a T
E
X le containing the documentation in a format that can be accessed by L
A
T
E
X code. This le is not directly
LaTeXable.
doxyformat.tex: This le contains the L
A
T
E
X code that transforms the documentation from doxydocs.tex
into L
A
T
E
X text suitable to be L
A
T
E
Xed and presented to the user.
doxylatex-template.pl: This Perl script uses DoxyModel.pm to generate doxytemplate.
tex, a T
E
X le dening default values for some macros. doxytemplate.tex is included by doxyformat.tex to
avoid the need of explicitly dening some macros.
doxylatex.tex: This is a very simple L
A
T
E
X document that loads some packages and includes
doxyformat.tex and doxydocs.tex. This document is L
A
T
E
Xed to produce the PDF and DVI documentation
by the rules added to doxyrules.make.
27.2.1 Creation of PDF and DVI output
To try this you need to have installed latex, pdflatex and the packages used by doxylatex.tex.
1. Update your Doxyfile to the latest version using:
doxygen -u Doxyfile
2. Set both GENERATE_PERLMOD and PERLMOD_LATEX tags to YES in your Doxyle.
3. Run Doxygen on your Doxyle:
doxygen Doxyfile
4. A perlmod/ subdirectory should have appeared in your output directory. Enter the perlmod/ subdirectory
and run:
make pdf
This should generate a doxylatex.pdf with the documentation in PDF format.
5. Run:
make dvi
This should generate a doxylatex.dvi with the documentation in DVI format.
Generated by Doxygen
27.3 Documentation format. 203
27.3 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 assignment 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.
$doxydocs contains a tree-like structure composed of three types of nodes: strings, hashes and lists.
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 elds, each with a
different key. The value of a hash eld can be a string, a hash or a list, and its semantics depends on the key
of the hash eld and the location of the hash within the tree. The values of the hash elds are the children of
the node.
Lists: These are references to anonymous Perl lists. A list has an undened 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.
27.4 Data structure
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 Doxy
Model.pm le 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 by Doxygen
204 Perl Module Output format
Generated by Doxygen
Chapter 28
Internationalization
Support for multiple languages
Doxygen has built-in support for multiple languages. This means that the text fragments, generated by doxygen, can
be produced in languages other than English (the default). The output language is chosen through the conguration
option OUTPUT_LANGUAGE in the conguration le (with default name and known as Doxyle).
Currently (version 1.8.7), 40 languages are supported (sorted alphabetically): Afrikaans, Arabic, Armenian, Brazilian
Portuguese, Catalan, Chinese, Chinese Traditional, Croatian, Czech, Danish, Dutch, English, Esperanto, Finnish,
French, German, Greek, Hungarian, Indonesian, Italian, Japanese (+En), Korean (+En), Latvian, Lithuanian, Mace-
donian, Norwegian, Persian, Polish, Portuguese, Romanian, Russian, Serbian, SerbianCyrillic, Slovak, Slovene,
Spanish, Swedish, Turkish, Ukrainian, and Vietnamese..
The table of information related to the supported languages follows. It is sorted by language alphabetically. The
Status column was generated from sources and shows approximately the last version when the translator was
updated.
Language Maintainer Contact address Status
Afrikaans Johan Prinsloo johan at zippysnoek dot com 1.6.0
Arabic Moaz Reyad [resigned] moazreyad at yahoo dot com 1.4.6
Muhammad Bashir Al-Noimi mbnoimi at gmail dot com
Armenian Armen Tangamyan armen dot tangamyan at anu dot edu dot au 1.8.0
Brazilian Portuguese Fabio "FJTC" Jun Takada Chino jun-chino at uol dot com dot br 1.8.0
Catalan Maximiliano Pin max dot pin at bitroit dot com 1.8.0
Albert Mora [unreachable] amora at iua dot upf dot es
Chinese Lian Yang lian dot yang dot cn at gmail dot com 1.8.2
Li Daobing lidaobing at gmail dot com
Wei Liu liuwei at asiainfo dot com
Chinese Traditional Daniel YC Lin dlin dot tw at gmail dot com almost up-to-date
Gary Lee garywlee at gmail dot com
Croatian Boris Bralo boris dot bralo at gmail dot com 1.8.2
Czech Petr Prikryl prikryl at atlas dot cz up-to-date
Danish Poul-Erik Hansen pouhan at gnotometrics dot dk 1.8.0
Erik Se Srensen eriksoe+doxygen at daimi dot au dot dk
Dutch Dimitri van Heesch dimitri at stack dot nl up-to-date
English Dimitri van Heesch dimitri at stack dot nl up-to-date
Esperanto Ander Martnez ander dot basaundi at gmail dot com 1.8.4
Finnish Antti Laine antti dot a dot laine at tut dot fi 1.6.0
French David Martinet contact at e-concept-applications dot fr up-to-date
Xavier Outhier xouthier at yahoo dot fr
Benot BROSSE Benoit dot BROSSE at ingenico dot com
German Peter Grotrian Peter dot Grotrian at pdv-FS dot de 1.8.4
Jens Seidel jensseidel at users dot sf dot net
Greek Paul Gessos gessos dot paul at yahoo dot gr 1.8.4
Hungarian kos Kiss akiss at users dot sourceforge dot net 1.4.6
Fldvri Gyrgy [unreachable] foldvari lost at cyberspace
Indonesian Hendy Irawan ceefour at gauldong dot net 1.8.0
Italian Alessandro Falappa alessandro at falappa dot net 1.8.2
Ahmed Aldo Faisal aaf23 at cam dot ac dot uk
Japanese Suzumizaki-Kimikata szmml at h12u.com up-to-date
Hiroki Iseri goyoki at gmail dot com
206 Internationalization
Ryunosuke Satoh sun594 at hotmail dot com
Kenji Nagamatsu [unreachable] naga at joyful dot club dot ne dot jp
Iwasa Kazmi [unreachable] iwasa at cosmo-system dot jp
JapaneseEn see the Japanese language English based
Korean Kim Taedong fly1004 at gmail dot com up-to-date
SooYoung Jung jung5000 at gmail dot com
Richard Kim [unreachable] ryk at dspwiz dot com
KoreanEn see the Korean language English based
Latvian Lauris lauris at nix.lv 1.8.4
Lithuanian Tomas Simonaitis [unreachable] haden at homelan dot lt 1.4.6
Mindaugas Radzius [unreachable] mindaugasradzius at takas dot lt
Aidas Berukstis [unreachable] aidasber at takas dot lt
searching for the maintainer [Please, try to help to find someone.]
Macedonian Slave Jovanovski slavejovanovski at yahoo dot com 1.6.0
Norwegian Lars Erik Jordet lejordet at gmail dot com 1.4.6
Persian Ali Nadalizadeh nadalizadeh at gmail dot com 1.7.5
Polish Piotr Kaminski [unreachable] Piotr dot Kaminski at ctm dot gdynia dot pl 1.8.2
Grzegorz Kowal [unreachable] g_kowal at poczta dot onet dot pl
Krzysztof Kral krzysztof dot kral at gmail dot com
Portuguese Rui Godinho Lopes [resigned] rgl at ruilopes dot com 1.8.0
Fabio "FJTC" Jun Takada Chino jun-chino at uol dot com dot br
Romanian Ionut Dumitrascu reddumy at yahoo dot com almost up-to-date
Alexandru Iosup aiosup at yahoo dot com
Russian Brilliantov Kirill Vladimirovich brilliantov at byterg dot ru almost up-to-date
Alexandr Chelpanov cav at cryptopro dot ru
Serbian Dejan Milosavljevic [unreachable] dmilos at email dot com 1.6.0
SerbianCyrillic Nedeljko Stefanovic stenedjo at yahoo dot com 1.6.0
Slovak Kali+Laco vec [the Slovak language advisors] up-to-date
Petr Prikryl prikryl at atlas dot cz
Slovene Matja Ostrovernik matjaz dot ostroversnik at ostri dot org 1.4.6
Spanish Bartomeu bartomeu at loteria3cornella dot com up-to-date
Francisco Oltra Thennet [unreachable] foltra at puc dot cl
David Vaquero david at grupoikusnet dot com
Swedish Bjrn Palmqvist bjorn.palmqvist at aidium.se almost up-to-date
Turkish Emin Ilker Cetinbas niw3 at yahoo dot com 1.7.5
Ukrainian Olexij Tkatchenko [resigned] olexij at tkatchenko dot com 1.8.4
Petro Yermolenko python at i dot ua
Vietnamese Dang Minh Tuan tuanvietkey at gmail dot com 1.6.0
Most people on the list have indicated that they were also busy doing other things, so if you want to help to speed
things up please let them (or me) know.
If you want to add support for a language that is not yet listed please read the next section.
Adding a new language to doxygen
This short HOWTO explains how to add support for the new language to doxygen:
Just follow the following steps:
1. Tell me for which language you want to add support. If no one else is already working on support for that
language, you will be assigned as the maintainer for the language.
2. Create a copy of doxygen/src/translator_en.h and name it doxygen/src/translator_
<your_2_letter_country_code>.h Ill use xx in the rest of this document (and XX for the upper-
case version).
3. Edit doxygen/src/language.cpp: Add the following code:
#ifdef LANG_XX
#include<translator_xx.h>
#endif
Remember to use the same symbol LANG_XX that was added to doxygen/src/lang_cfg.h.
Now, in setTranslator() add
Generated by Doxygen
207
#ifdef LANG_XX
else if (L_EQUAL("your_language_name"))
{
theTranslator = new TranslatorYourLanguage;
}
#endif
after the if { ... }. I.e., it must be placed after the code for creating the English translator at the
beginning, and before the else { ... } part that creates the translator for the default language (English
again).
4. Edit doxygen/src/translator_xx.h:
Use the UTF-8 capable editor and open the le using the UTF-8 mode.
Rename TRANSLATOR_EN_H to TRANSLATOR_XX_H twice (i.e. in the #ifndef and #define
preprocessor commands at the beginning of the le).
Rename TranslatorEnglish to TranslatorYourLanguage
In the member idLanguage() change "english" into the name of your language (use lower case char-
acters only). Depending on the language you may also wish to change the member functions latex
LanguageSupportCommand() and other (you will recognize them when you start the work).
Edit all the strings that are returned by the member functions that start with tr. Try to match punctuation
and capitals! To enter special characters (with accents) you can:
Enter them directly if your keyboard supports that. Recall that the text is expected to be saved using
the UTF-8 encoding. Doxygen will translate the characters to proper L
A
T
E
X and leaves the HTML
and man output in UTF-8.
Use HTML codes like ä for an a with an umlaut (i.e. ). See the HTML specication for
the codes.
5. On nix systems:
Rerun the configure script from the root (i.e. in the doxygen directory) so that it generates
doxygen/src/lang_cfg.h. This le should now contain a #define for your language
code.
Run make again from the root (i.e. in the doxygen directory) of the distribution, in order to
regenerate the Makefiles.
On Windows:
stop Visual Stdio
open a command window
goto the directory doxygen\src
give the command python languages.py > ..\winbuild\Languages.rules
close the command window
start Visual Studio again
Your language should now be selectable in the General part of the Settings of the
Properties window of lang_cfg.py, by default Your language will be on. Rebuild
doxygen (and doxywizard) now.
6. Now you can use OUTPUT_LANGUAGE = your_language_name in the cong le to generate output
in your language.
7. Send translator_xx.h to me so I can add it to doxygen. Send also your name and e-mail address to
be included in the maintainers.txt list. You can also clone the doxygen repository at GitHub and make
a Pull Request later.
Generated by Doxygen
208 Internationalization
Maintaining a language
New versions of doxygen may use new translated sentences. In such situation, the Translator class requires
implementation of new methods its interface changes. Of course, the English sentences need to be translated
to the other languages. At least, new methods have to be implemented by the language-related translator class;
otherwise, doxygen wouldnt even compile. Waiting until all language maintainers have translated the newsentences
and sent the results would not be very practical. The following text describes the usage of translator adapters to
solve the problem.
The role of Translator Adapters. Whenever the Translator class interface changes in the new release, the
new class TranslatorAdapter_x_y_z is added to the translator_adapter.h le (here x, y, and z are
numbers that correspond to the current ofcial version of doxygen). All translators that previously derived from the
Translator class now derive from this adapter class.
The TranslatorAdapter_x_y_z class implements the new, required methods. If the new method replaces
some similar but obsolete method(s) (e.g. if the number of arguments changed and/or the functionality of the older
method was changed or enriched), the TranslatorAdapter_x_y_z class may use the obsolete method to
get the result which is as close as possible to the older result in the target language. If it is not possible, the result
(the default translation) is obtained using the English translator, which is (by denition) always up-to-date.
For example, when the new trFile() method with parameters (to determine the capitalization of the rst letter
and the singular/plural form) was introduced to replace the older method trFiles() without arguments, the
following code appeared in one of the translator adapter classes:
/
*
! This is the default implementation of the obsolete method
*
used in the documentation of a group before the list of
*
links to documented files. This is possibly localized.
*
/
virtual QCString trFiles()
{ return "Files"; }
/
*
! This is the localized implementation of newer equivalent
*
using the obsolete method trFiles().
*
/
virtual QCString trFile(bool first_capital, bool singular)
{
if (first_capital && !singular)
return trFiles(); // possibly localized, obsolete method
else
return english.trFile(first_capital, singular);
}
The trFiles() is not present in the TranslatorEnglish class, because it was removed as obsolete. How-
ever, it was used until now and its call was replaced by
trFile(true, false)
in the doxygen source les. Probably, many language translators implemented the obsolete method, so it perfectly
makes sense to use the same language dependent result in those cases. The TranslatorEnglish does not
implement the old method. It derives from the abstract Translator class. On the other hand, the old translator
for a different language does not implement the new trFile() method. Because of that it is derived from another
base class TranslatorAdapter_x_y_z. The TranslatorAdapter_x_y_z class has to implement
the new, required trFile() method. However, the translator adapter would not be compiled if the trFiles()
method was not implemented. This is the reason for implementing the old method in the translator adapter class
(using the same code, that was removed from the TranslatorEnglish).
The simplest way would be to pass the arguments to the English translator and to return its result. Instead, the
adapter uses the old trFiles() in one special case when the new trFile(true, false) is called. This
is the mostly used case at the time of introducing the new method see above. While this may look too complicated,
the technique allows the developers of the core sources to change the Translator interface, while the users may not
even notice the change. Of course, when the new trFile() is used with different arguments, the English result
is returned and it will be noticed by non English users. Here the maintainer of the language translator should
implement at least that one particular method.
Generated by Doxygen
209
What says the base class of a language translator? If the language translator class inherits from any adapter
class then maintenance is needed. In such case, the language translator is considered not up-to-date. On the other
hand, if the language translator derives directly from the abstract class Translator, the language translator is
up-to-date.
The translator adapter classes are chained so that the older translator adapter class uses the one-step-newer
translator adapter as the base class. The newer adapter does less adapting work than the older one. The oldest
adapter class derives (indirectly) from all of the adapter classes. The name of the adapter class is chosen so that
its sufx is derived from the previous ofcial version of doxygen that did not need the adapter. This way, one can
say approximately, when the language translator class was last updated see details below.
The newest translator adapter derives from the abstract TranslatorAdapterBase class that derives directly
from the abstract Translator class. It adds only the private English-translator member for easy implementation
of the default translation inside the adapter classes, and it also enforces implementation of one method for notifying
the user that the language translation is not up-to-date (because of that some sentences in the generated les may
appear in English).
Once the oldest adapter class is not used by any of the language translators, it can be removed from the doxygen
project. The maintainers should try to reach the state with the minimal number of translator adapter classes.
To simplify the maintenance of the language translator classes for the supported languages, the
translator.py Python script was developed (located in doxygen/doc directory). It extracts the impor-
tant information about obsolete and new methods from the source les for each of the languages. The information
is stored in the translator report ASCII le (translator_report.txt).
Looking at the base class of the language translator, the script guesses also the status of the translator see the
last column of the table with languages above. The translator.py is called automatically when the doxygen
documentation is generated. You can also run the script manually whenever you feel that it can help you. Of course,
you are not forced to use the results of the script. You can nd the same information by looking at the adapter class
and its base classes.
How should I update my language translator? First, you should be the language maintainer, or you should
let him/her know about the changes. The following text was written for the language maintainers as the primary
audience.
There are several approaches to be taken when updating your language. If you are not extremely busy, you should
always chose the most radical one. When the update takes much more time than you expected, you can always
decide use some suitable translator adapter to nish the changes later and still make your translator working.
The most radical way of updating the language translator is to make your translator class derive directly from
the abstract class Translator and provide translations for the methods that are required to be implemented the
compiler will tell you if you forgot to implement some of them. If you are in doubt, have a look at the Translator
English class to recognize the purpose of the implemented method. Looking at the previously used adapter class
may help you sometimes, but it can also be misleading because the adapter classes do implement also the obsolete
methods (see the previous trFiles() example).
In other words, the up-to-date language translators do not need the TranslatorAdapter_x_y_z classes at
all, and you do not need to implement anything else than the methods required by the Translator class (i.e. the pure
virtual methods of the Translator they end with =0;).
If everything compiles ne, try to run translator.py, and have a look at the translator report (ASCII le) at
the doxygen/doc directory. Your translator is marked as up-to-date only if the script does not detect anything
special. If the translator uses the Translator base class, there still may be some remarks related to your source
code. In the case, the translator is marked as almost up-to-date. Namely, the obsolete methodsthat are not used
at allmay be listed in the section for your language. Simply, remove their code (and run the translator.py
again). Also, you will be informed when you forgot to change the base class of your translator class to some newer
adapter class or directly to the Translator class.
If you do not have time to nish all the updates you should still start with the most radical approach as described
above. You can always change the base class to the translator adapter class that implements all of the not-yet-
implemented methods.
If you prefer to update your translator gradually, have a look at TranslatorEnglish (the translator
_en.h le). Inside, you will nd the comments like new since 1.2.4 that separate always a number of
methods that were implemented in the stated version. Do implement the group of methods that are placed below
Generated by Doxygen
210 Internationalization
the comment that uses the same version numbers as your translator adapter class. (For example, your translator
class have to use the TranslatorAdapter_1_2_4, if it does not implement the methods below the comment
new since 1.2.4. When you implement them, your class should use a newer translator adapter.
Run the translator.py script occasionally and give it your xx identication (from translator_xx.h) to
create the translator report shorter (also produced faster) it will contain only the information related to your trans-
lator. Once you reach the state when the base class should be changed to some newer adapter, you will see the
note in the translator report.
Warning: Dont forget to compile doxygen to discover, whether it is compilable. The translator.py does not
check if everything is correct with respect to the compiler. Because of that, it may lie sometimes about the necessary
base class.
The most obsolete language translators would lead to implementation of too complicated adapters. Because of
that, doxygen developers may decide to derive such translators from the TranslatorEnglish class, which is
by denition always up-to-date.
When doing so, all the missing methods will be replaced by the English translation. This means that not-
implemented methods will always return the English result. Such translators are marked using the word obsolete.
You should read it really obsolete. No guess about the last update can be done.
Often, it is possible to construct better result from the obsolete methods. Because of that, the translator adapter
classes should be used if possible. On the other hand, implementation of adapters for really obsolete translators
brings too much maintenance and run-time overhead.
Generated by Doxygen
Index
\", 180
\#, 180
\$, 180
\&, 180
\--, 181
\---, 181
\., 181
\::, 181
\<, 180
\>, 180
\\, 179
\%, 180
\|, 181
\, 179
\a, 168
\addindex, 162
\addtogroup, 138, 152
\anchor, 162
\arg, 168
\attention, 152
\author, 152
\authors, 152
\b, 169
\brief, 152
\bug, 153
\c, 169
\callergraph, 139
\callgraph, 139
\category, 140
\cite, 162
\class, 140
\code, 169
\cond, 153
\copybrief, 170
\copydetails, 171
\copydoc, 170
\copyright, 154
\date, 154
\def, 140
\defgroup, 141
\deprecated, 154
\details, 154
\diale, 173
\dir, 141
\docbookonly, 171
\dontinclude, 165
\dot, 171
\dotle, 173
\e, 173
\else, 154
\elseif, 154
\em, 174
\endcode, 174
\endcond, 155
\enddocbookonly, 174
\enddot, 174
\endhtmlonly, 174
\endif, 155
\endinternal, 142
\endlatexonly, 175
\endlink, 162
\endmanonly, 175
\endmsc, 174
\endparblock, 158
\endrtfonly, 175
\endsecreist, 163
\enduml, 174
\endverbatim, 175
\endxmlonly, 175
\enum, 141
\example, 141
\exception, 155
\extends, 142
\f$, 175
\f[, 175
\f{, 176
\f}, 176
\f], 176
\le, 142
\fn, 143
\headerle, 144
\hideinitializer, 144
\htmlinclude, 168
\htmlonly, 176
\idlexcept, 144
\if, 155
\ifnot, 156
\image, 177
\implements, 144
\include, 166
\includelineno, 166
\ingroup, 145
\interface, 145
\internal, 145
\invariant, 156
\latexinclude, 168
\latexonly, 177
\li, 178
212 INDEX
\line, 166
\link, 162
\mainpage, 145
\manonly, 177
\memberof, 146
\msc, 171
\mscle, 173
\n, 178
\name, 146
\namespace, 146
\nosubgrouping, 146
\note, 156
\overload, 146
\p, 178
\package, 147
\page, 147
\par, 157
\paragraph, 165
\param, 157
\parblock, 158
\post, 158
\pre, 158
\private, 148
\privatesection, 148
\property, 148
\protected, 148
\protectedsection, 149
\protocol, 149
\public, 149
\publicsection, 149
\pure, 149
\ref, 162
\retem, 163
\related, 150
\relatedalso, 150
\relates, 150
\relatesalso, 150
\remark, 159
\remarks, 159
\result, 159
\return, 159
\returns, 159
\retval, 159
\rtfonly, 179
\sa, 159
\secreist, 163
\section, 164
\see, 160
\short, 160
\showinitializer, 150
\since, 160
\skip, 166
\skipline, 167
\snippet, 167
\startuml, 172
\static, 151
\struct, 151
\subpage, 163
\subsection, 164
\subsubsection, 164
\tableofcontents, 164
\test, 160
\throw, 160
\throws, 160
\todo, 160
\tparam, 158
\typedef, 151
\union, 151
\until, 167
\var, 151
\verbatim, 179
\verbinclude, 168
\version, 160
\vhdlow, 151
\warning, 161
\xmlonly, 179
\xretem, 161
ABBREVIATE_BRIEF, 106
acknowledgments, 5
ALIASES, 107
ALLEXTERNALS, 131
ALLOW_UNICODE_NAMES, 106
ALPHABETICAL_INDEX, 117
ALWAYS_DETAILED_SEC, 106
AUTOLINK_SUPPORT, 108
BINARY_TOC, 121
bison, 7
BRIEF_MEMBER_DESC, 106
browser, 15
BUILTIN_STL_SUPPORT, 108
CALL_GRAPH, 133
CALLER_GRAPH, 133
CASE_SENSE_NAMES, 111
CHM_FILE, 121
CHM_INDEX_ENCODING, 121
CITE_BIB_FILES, 113
CLANG_ASSISTED_PARSING, 116
CLANG_OPTIONS, 116
CLASS_DIAGRAMS, 131
CLASS_GRAPH, 132
COLLABORATION_GRAPH, 132
COLS_IN_ALPHA_INDEX, 117
COMPACT_LATEX, 125
COMPACT_RTF, 127
CPP_CLI_SUPPORT, 108
CREATE_SUBDIRS, 106
DIA_PATH, 131
DIAFILE_DIRS, 134
DIRECTORY_GRAPH, 133
DISABLE_INDEX, 122
DISTRIBUTE_GROUP_DOC, 109
Doc++, 5
docbook, 16
Generated by Doxygen
INDEX 213
DOCBOOK_OUTPUT, 129
DOCBOOK_PROGRAMLISTING, 129
DOCSET_BUNDLE_ID, 120
DOCSET_FEEDNAME, 120
DOCSET_PUBLISHER_ID, 120
DOCSET_PUBLISHER_NAME, 121
DOT_CLEANUP, 134
DOT_FONTNAME, 132
DOT_FONTPATH, 132
DOT_FONTSIZE, 132
DOT_GRAPH_MAX_NODES, 134
DOT_IMAGE_FORMAT, 133
DOT_MULTI_TARGETS, 134
DOT_NUM_THREADS, 131
DOT_PATH, 133
DOT_TRANSPARENT, 134
DOTFILE_DIRS, 134
DOXYFILE_ENCODING, 105
ECLIPSE_DOC_ID, 122
ENABLE_PREPROCESSING, 129
ENABLED_SECTIONS, 112
ENUM_VALUES_PER_LINE, 123
EXAMPLE_PATH, 114
EXAMPLE_PATTERNS, 115
EXAMPLE_RECURSIVE, 115
EXCLUDE, 114
EXCLUDE_PATTERNS, 114
EXCLUDE_SYMBOLS, 114
EXCLUDE_SYMLINKS, 114
EXPAND_AS_DEFINED, 130
EXPAND_ONLY_PREDEF, 130
EXT_LINKS_IN_WINDOW, 123
EXTENSION_MAPPING, 108
EXTERNAL_GROUPS, 131
EXTERNAL_PAGES, 131
EXTERNAL_SEARCH, 124
EXTERNAL_SEARCH_ID, 125
EXTRA_PACKAGES, 126
EXTRA_SEARCH_MAPPINGS, 125
EXTRACT_ALL, 109
EXTRACT_ANON_NSPACES, 110
EXTRACT_LOCAL_CLASSES, 110
EXTRACT_LOCAL_METHODS, 110
EXTRACT_PACKAGE, 110
EXTRACT_PRIVATE, 110
EXTRACT_STATIC, 110
features, 93
FILE_PATTERNS, 114
FILE_VERSION_FILTER, 112
FILTER_PATTERNS, 115
FILTER_SOURCE_FILES, 115
FILTER_SOURCE_PATTERNS, 115
ex, 7
FORCE_LOCAL_INCLUDES, 111
FORMULA_FONTSIZE, 123
FORMULA_TRANSPARENT, 123
FULL_PATH_NAMES, 106
GENERATE_AUTOGEN_DEF, 129
GENERATE_BUGLIST, 112
GENERATE_CHI, 121
GENERATE_DEPRECATEDLIST, 112
GENERATE_DOCBOOK, 128
GENERATE_DOCSET, 120
GENERATE_ECLIPSEHELP, 122
GENERATE_HTML, 117
GENERATE_HTMLHELP, 121
GENERATE_LATEX, 125
GENERATE_LEGEND, 134
GENERATE_MAN, 128
GENERATE_PERLMOD, 129
GENERATE_QHP, 121
GENERATE_RTF, 127
GENERATE_TAGFILE, 131
GENERATE_TESTLIST, 112
GENERATE_TODOLIST, 112
GENERATE_TREEVIEW, 122
GENERATE_XML, 128
GPL, 4
GRAPHICAL_HIERARCHY, 133
GROUP_GRAPHS, 132
HAVE_DOT, 131
HHC_LOCATION, 121
HIDE_FRIEND_COMPOUNDS, 110
HIDE_IN_BODY_DOCS, 110
HIDE_SCOPE_NAMES, 111
HIDE_UNDOC_CLASSES, 110
HIDE_UNDOC_MEMBERS, 110
HIDE_UNDOC_RELATIONS, 131
HTML_COLORSTYLE_GAMMA, 120
HTML_COLORSTYLE_HUE, 119
HTML_COLORSTYLE_SAT, 119
HTML_DYNAMIC_SECTIONS, 120
HTML_EXTRA_FILES, 119
HTML_EXTRA_STYLESHEET, 119
HTML_FILE_EXTENSION, 117
HTML_FOOTER, 118
HTML_HEADER, 117
HTML_INDEX_NUM_ENTRIES, 120
HTML_OUTPUT, 117
HTML_STYLESHEET, 118
HTML_TIMESTAMP, 120
IDL_PROPERTY_SUPPORT, 109
IGNORE_PREFIX, 117
IMAGE_PATH, 115
INCLUDE_FILE_PATTERNS, 130
INCLUDE_GRAPH, 132
INCLUDE_PATH, 130
INCLUDED_BY_GRAPH, 133
INHERIT_DOCS, 107
INLINE_GROUPED_CLASSES, 109
INLINE_INFO, 111
INLINE_INHERITED_MEMB, 106
INLINE_SIMPLE_STRUCTS, 109
INLINE_SOURCES, 115
Generated by Doxygen
214 INDEX
INPUT, 114
INPUT_ENCODING, 114
INPUT_FILTER, 115
installation, 7
INTERACTIVE_SVG, 133
INTERNAL_DOCS, 110
JAVADOC_AUTOBRIEF, 107
LaTeX, 16
LATEX_BATCHMODE, 126
LATEX_BIB_STYLE, 127
LATEX_CMD_NAME, 125
LATEX_EXTRA_FILES, 126
LATEX_FOOTER, 126
LATEX_HEADER, 126
LATEX_HIDE_INDICES, 127
LATEX_OUTPUT, 125
LATEX_SOURCE_CODE, 127
LAYOUT_FILE, 113
libiconv, 7
license, 4
LOOKUP_CACHE_SIZE, 109
MACRO_EXPANSION, 129
make, 7
MAKEINDEX_CMD_NAME, 125
man, 16
MAN_EXTENSION, 128
MAN_LINKS, 128
MAN_OUTPUT, 128
MAN_SUBDIR, 128
MARKDOWN_SUPPORT, 108
MATHJAX_CODEFILE, 124
MATHJAX_EXTENSIONS, 124
MATHJAX_FORMAT, 123
MATHJAX_RELPATH, 123
MAX_DOT_GRAPH_DEPTH, 134
MAX_INITIALIZER_LINES, 112
MSCFILE_DIRS, 134
MSCGEN_PATH, 131
MULTILINE_CPP_IS_BRIEF, 107
OPTIMIZE_FOR_FORTRAN, 108
OPTIMIZE_OUTPUT_FOR_C, 108
OPTIMIZE_OUTPUT_JAVA, 108
OPTIMIZE_OUTPUT_VHDL, 108
output formats, 63
OUTPUT_DIRECTORY, 106
OUTPUT_LANGUAGE, 106
PAPER_TYPE, 126
parsing, 17
PDF_HYPERLINKS, 126
perl, 7
PERL_PATH, 131
perlmod, 201
PERLMOD_LATEX, 129
PERLMOD_MAKEVAR_PREFIX, 129
PERLMOD_PRETTY, 129
PLANTUML_JAR_PATH, 134
PREDEFINED, 130
PROJECT_BRIEF, 105
PROJECT_LOGO, 105
PROJECT_NAME, 105
PROJECT_NUMBER, 105
QCH_FILE, 121
QHG_LOCATION, 122
QHP_CUST_FILTER_ATTRS, 122
QHP_CUST_FILTER_NAME, 122
QHP_NAMESPACE, 122
QHP_SECT_FILTER_ATTRS, 122
QHP_VIRTUAL_FOLDER, 122
Qt, 7
QT_AUTOBRIEF, 107
QUIET, 113
RECURSIVE, 114
REFERENCED_BY_RELATION, 116
REFERENCES_LINK_SOURCE, 116
REFERENCES_RELATION, 116
REPEAT_BRIEF, 106
RTF, 16
RTF_EXTENSIONS_FILE, 127
RTF_HYPERLINKS, 127
RTF_OUTPUT, 127
RTF_STYLESHEET_FILE, 127
SEARCH_INCLUDES, 130
SEARCHDATA_FILE, 125
SEARCHENGINE, 124
SEARCHENGINE_URL, 125
SEPARATE_MEMBER_PAGES, 107
SERVER_BASED_SEARCH, 124
SHORT_NAMES, 107
SHOW_FILES, 112
SHOW_GROUPED_MEMB_INC, 111
SHOW_INCLUDE_FILES, 111
SHOW_NAMESPACES, 112
SHOW_USED_FILES, 112
SIP_SUPPORT, 109
SKIP_FUNCTION_MACROS, 130
SORT_BRIEF_DOCS, 111
SORT_BY_SCOPE_NAME, 111
SORT_GROUP_NAMES, 111
SORT_MEMBER_DOCS, 111
SORT_MEMBERS_CTORS_1ST, 111
SOURCE_BROWSER, 115
SOURCE_TOOLTIPS, 116
STRICT_PROTO_MATCHING, 112
strip, 7
STRIP_CODE_COMMENTS, 115
STRIP_FROM_INC_PATH, 107
STRIP_FROM_PATH, 107
SUBGROUPING, 109
TAB_SIZE, 107
Generated by Doxygen
INDEX 215
TAGFILES, 130
TCL_SUBST, 108
TEMPLATE_RELATIONS, 132
TOC_EXPAND, 121
TREEVIEW_WIDTH, 123
TYPEDEF_HIDES_STRUCT, 109
UML_LIMIT_NUM_FIELDS, 132
UML_LOOK, 132
USE_HTAGS, 116
USE_MATHJAX, 123
USE_MDFILE_AS_MAINPAGE, 115
USE_PDFLATEX, 126
VERBATIM_HEADERS, 116
WARN_FORMAT, 114
WARN_IF_DOC_ERROR, 113
WARN_IF_UNDOCUMENTED, 113
WARN_LOGFILE, 114
WARN_NO_PARAMDOC, 113
WARNINGS, 113
XML, 16
XML_OUTPUT, 128
XML_PROGRAMLISTING, 128
Generated by Doxygen