<doxygenconfig>

  <header>

    <docs doxywizard='0' doxyfile='0'>

/*

 *

 * 

 *

 * Copyright (C) 1997-2015 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.

 *

 */

/*! \page config Configuration

\tableofcontents

\section config_format Format

A configuration file is a free-form ASCII text file with a structure

that is similar to that of a \c Makefile, with the default name \c Doxyfile. It is

parsed by \c doxygen. The file may contain tabs and newlines for

formatting purposes. The statements in the file are case-sensitive.

Comments may be placed anywhere within the file (except within quotes).

Comments beginning with two hash characters (\c \#\#) are kept when updating

the configuration file and are placed in front of the TAG they are in front of.

Comments beginning with two hash characters (\c \#\#) at the beginning of the

configuration file are also kept and placed at the beginning of the file.

Comments beginning with two hash characters (\c \#\#) at the end of the

configuration file are also kept and placed at the end of the file.

Comments begin with the hash character (\c \#) and ends at the end of the line.

The file essentially consists of a list of assignment statements.

Each statement consists of a \c 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 (\c \\)

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 configuration file from another configuration

file using a \@INCLUDE tag as follows:

\verbatim

@INCLUDE = config_file_name

\endverbatim 

The include file 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.:

\verbatim

@INCLUDE_PATH = my_config_dir

\endverbatim

The configuration 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.

]]>

    </docs>

    <docs doxywizard='0' documentation='0'>

This file describes the settings to be used by the documentation system

doxygen (www.doxygen.org) for a project.

All text after a double hash (##) is considered a comment and is placed

in front of the TAG it is preceding.

All text after a single hash (#) is considered a comment and will be ignored.

The format is:

\verbatim

      TAG = value [value, ...]

\endverbatim

For lists, items can also be appended using:

\verbatim

      TAG += value [value, ...]

\endverbatim

Values that contain spaces should be placed between quotes (\" \").

]]>

    </docs>

  </header>

  <footer>

    <docs doxywizard='0' doxyfile='0'>

\section config_examples Examples

Suppose you have a simple project consisting of two files: a source file 

\c example.cc and a header file \c example.h.

Then a minimal configuration file is as simple as:

\verbatim

INPUT            = example.cc example.h

\endverbatim

Assuming the example makes use of Qt classes and \c perl is located 

in /usr/bin, a more realistic configuration file would be:

\verbatim

PROJECT_NAME     = Example

INPUT            = example.cc example.h

WARNINGS         = YES

TAGFILES         = qt.tag

PERL_PATH        = /usr/local/bin/perl

SEARCHENGINE     = NO

\endverbatim

To generate the documentation for the 

QdbtTabular package

I have used the following configuration file:

\verbatim

PROJECT_NAME     = QdbtTabular

OUTPUT_DIRECTORY = html

WARNINGS         = YES

INPUT            = examples/examples.doc src

FILE_PATTERNS    = *.cc *.h

INCLUDE_PATH     = examples

TAGFILES         = qt.tag

PERL_PATH        = /usr/bin/perl

SEARCHENGINE     = YES

\endverbatim

To regenerate the Qt-1.44 documentation from the sources, you could use the

following config file:

\verbatim

PROJECT_NAME         = Qt

OUTPUT_DIRECTORY     = qt_docs

HIDE_UNDOC_MEMBERS   = YES

HIDE_UNDOC_CLASSES   = YES

ENABLE_PREPROCESSING = YES

MACRO_EXPANSION      = YES

EXPAND_ONLY_PREDEF   = YES

SEARCH_INCLUDES      = YES

FULL_PATH_NAMES      = YES

STRIP_FROM_PATH      = $(QTDIR)/

PREDEFINED           = USE_TEMPLATECLASS Q_EXPORT= \

                       QArrayT:=QArray \

                       QListT:=QList \

                       QDictT:=QDict \

                       QQueueT:=QQueue \

                       QVectorT:=QVector \

                       QPtrDictT:=QPtrDict \

                       QIntDictT:=QIntDict \

                       QStackT:=QStack \

                       QDictIteratorT:=QDictIterator \

                       QListIteratorT:=QListIterator \

                       QCacheT:=QCache \

                       QCacheIteratorT:=QCacheIterator \

                       QIntCacheT:=QIntCache \

                       QIntCacheIteratorT:=QIntCacheIterator \

                       QIntDictIteratorT:=QIntDictIterator \

                       QPtrDictIteratorT:=QPtrDictIterator

INPUT                = $(QTDIR)/doc \

                       $(QTDIR)/src/widgets \

                       $(QTDIR)/src/kernel \

                       $(QTDIR)/src/dialogs \

                       $(QTDIR)/src/tools

FILE_PATTERNS        = *.cpp *.h q*.doc

INCLUDE_PATH         = $(QTDIR)/include 

RECURSIVE            = YES

\endverbatim

For the Qt-2.1 sources I recommend to use the following settings:

\verbatim

PROJECT_NAME          = Qt

PROJECT_NUMBER        = 2.1

HIDE_UNDOC_MEMBERS    = YES

HIDE_UNDOC_CLASSES    = YES

SOURCE_BROWSER        = YES

INPUT                 = $(QTDIR)/src

FILE_PATTERNS         = *.cpp *.h q*.doc

RECURSIVE             = YES

EXCLUDE_PATTERNS      = *codec.cpp moc_* */compat/* */3rdparty/*

ALPHABETICAL_INDEX    = YES

COLS_IN_ALPHA_INDEX   = 3

IGNORE_PREFIX         = Q

ENABLE_PREPROCESSING  = YES

MACRO_EXPANSION       = YES

INCLUDE_PATH          = $(QTDIR)/include

PREDEFINED            = Q_PROPERTY(x)= \

                        Q_OVERRIDE(x)= \

                        Q_EXPORT= \

                        Q_ENUMS(x)= \

                        "QT_STATIC_CONST=static const " \

                        _WS_X11_ \

                        INCLUDE_MENUITEM_DEF

EXPAND_ONLY_PREDEF    = YES

EXPAND_AS_DEFINED     = Q_OBJECT_FAKE Q_OBJECT ACTIVATE_SIGNAL_WITH_PARAM \

                        Q_VARIANT_AS

\endverbatim

Here doxygen's preprocessor is used to substitute some

macro names that are normally substituted by the C preprocessor,

but without doing full macro expansion.

\htmlonly

Go to the next section or return to the

 index.

\endhtmlonly

*/

]]>

    </docs>

  </footer>

  <group name='Project' docs='Project related configuration options'>

    <option type='string' id='DOXYFILE_ENCODING' format='string' defval='UTF-8'>

      <docs>

 This tag specifies the encoding used for all characters in the config file that 

 follow. The default is UTF-8 which is also the encoding used for all text before

 the first occurrence of this tag. Doxygen uses \c libiconv (or the iconv built into

 \c libc) for the transcoding. See https://www.gnu.org/software/libiconv/ for the list of

 possible encodings.

]]>

      </docs>

    </option>

    <option type='string' id='PROJECT_NAME' format='string' defval='My Project'>

      <docs>

 The \c 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.

]]>

      </docs>

    </option>

    <option type='string' id='PROJECT_NUMBER' format='string' defval=''>

      <docs>

 The \c 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.

]]>

      </docs>

    </option>

    <option type='string' id='PROJECT_BRIEF' format='string' defval=''>

      <docs>

 Using the \c 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. 

]]>

      </docs>

    </option>

    <option type='string' id='PROJECT_LOGO' format='image' defval=''>

      <docs>

 With the \c PROJECT_LOGO tag one can specify a logo or an icon that is 

 included in the documentation. 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.

]]>

      </docs>

    </option>

    <option type='string' id='OUTPUT_DIRECTORY' format='dir' defval=''>

      <docs>

 The \c 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.

]]>

      </docs>

    </option>

    <option type='bool' id='CREATE_SUBDIRS' defval='0'>

      <docs>

 If the \c CREATE_SUBDIRS tag is set to \c YES then doxygen will create

 4096 sub-directories (in 2 levels) under the output directory of each output 

 format and will distribute the generated files over these directories. 

 Enabling this option can be useful when feeding doxygen a huge amount of source

 files, where putting all generated files in the same directory would otherwise

 causes performance problems for the file system. 

]]>

      </docs>

    </option>

    <option type='bool' id='ALLOW_UNICODE_NAMES' defval='0'>

      <docs>

 If the \c ALLOW_UNICODE_NAMES tag is set to \c YES,

 doxygen will allow non-ASCII characters to appear in the names of generated files. 

 If set to \c NO, non-ASCII characters will be escaped, for example _xE3_x81_x84 

 will be used for Unicode U+3044.

]]>

      </docs>

    </option>

    <option type='enum' id='OUTPUT_LANGUAGE' defval='English'>

      <docs>

 The \c 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.

]]>

      </docs>

      <value name='Afrikaans'/>

      <value name='Arabic'/>

      <value name='Armenian'/>

      <value name='Brazilian'/>

      <value name='Catalan'/>

      <value name='Chinese'/>

      <value name='Chinese-Traditional'/>

      <value name='Croatian'/>

      <value name='Czech'/>

      <value name='Danish'/>

      <value name='Dutch'/>

      <value name='English' desc='(United States)'/>

      <value name='Esperanto'/>

      <value name='Farsi' desc='(Persian)'/>

      <value name='Finnish'/>

      <value name='French'/>

      <value name='German'/>

      <value name='Greek'/>

      <value name='Hungarian'/>

      <value name='Indonesian'/>

      <value name='Italian'/>

      <value name='Japanese'/>

      <value name='Japanese-en' desc='(Japanese with English messages)'/>

      <value name='Korean'/>

      <value name='Korean-en' desc='(Korean with English messages)'/>

      <value name='Latvian'/>

      <value name='Lithuanian'/>

      <value name='Macedonian'/>

      <value name='Norwegian'/>

      <value name='Persian' desc='(Farsi)'/>

      <value name='Polish'/>

      <value name='Portuguese'/>

      <value name='Romanian'/>

      <value name='Russian'/>

      <value name='Serbian'/>

      <value name='Serbian-Cyrillic'/>

      <value name='Slovak'/>

      <value name='Slovene'/>

      <value name='Spanish'/>

      <value name='Swedish'/>

      <value name='Turkish'/>

      <value name='Ukrainian'/>

      <value name='Vietnamese'/>

    </option>

    <option type='bool' id='BRIEF_MEMBER_DESC' defval='1'>

      <docs>

 If the \c BRIEF_MEMBER_DESC tag is set to \c YES, doxygen will

 include brief member descriptions after the members that are listed in

 the file and class documentation (similar to \c Javadoc).

 Set to \c NO to disable this.

]]>

      </docs>

    </option>

    <option type='bool' id='REPEAT_BRIEF' defval='1'>

      <docs>

 If the \c REPEAT_BRIEF tag is set to \c YES, doxygen will 

 prepend the brief description of a member or function before the detailed 

 description 

 
Note: 

 If both \ref cfg_hide_undoc_members "HIDE_UNDOC_MEMBERS" and

 \ref cfg_brief_member_desc "BRIEF_MEMBER_DESC" are set to \c NO, the 

 brief descriptions will be completely suppressed.

]]>

      </docs>

    </option>

    <option type='list' id='ABBREVIATE_BRIEF' format='string'>

      <docs>

 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 replaced with the

 name of the entity): 

]]>

      </docs>

      <value name='The $name class'/>

      <value name='The $name widget'/>

      <value name='The $name file'/>

      <value name='is'/>

      <value name='provides'/>

      <value name='specifies'/>

      <value name='contains'/>

      <value name='represents'/>

      <value name='a'/>

      <value name='an'/>

      <value name='the'/>

    </option>

    <option type='bool' id='ALWAYS_DETAILED_SEC' defval='0'>

      <docs>

 If the \c ALWAYS_DETAILED_SEC and \ref cfg_repeat_brief "REPEAT_BRIEF" tags 

 are both set to \c YES then

 doxygen will generate a detailed section even if there is only a brief

 description.

]]>

      </docs>

    </option>

    <option type='bool' id='INLINE_INHERITED_MEMB' defval='0'>

      <docs>

 If the \c INLINE_INHERITED_MEMB tag is set to \c 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.

]]>

      </docs>

    </option>

    <option type='bool' id='FULL_PATH_NAMES' defval='1'>

      <docs>

 If the \c FULL_PATH_NAMES tag is set to \c YES, doxygen will prepend the full

 path before files name in the file list and in the header files. If set

 to \c NO the shortest path that makes the file name unique will be used

]]>

      </docs>

    </option>

    <option type='list' id='STRIP_FROM_PATH' format='string' depends='FULL_PATH_NAMES'>

      <docs>

 The \c STRIP_FROM_PATH tag

 can be used to strip a user-defined part of the path. Stripping is

 only done if one of the specified strings matches the left-hand part of the 

 path. The tag can be used to show relative paths in the file 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.

]]>

      </docs>

      <value name=''/>

    </option>

    <option type='list' id='STRIP_FROM_INC_PATH' format='string'>

      <docs>

 The \c STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of 

 the path mentioned in the documentation of a class, which tells

 the reader which header file to include in order to use a class. 

 If left blank only the name of the header file containing the class

 definition is used. Otherwise one should specify the list of include paths that 

 are normally passed to the compiler using the `-I` flag.

]]>

      </docs>

    </option>

    <option type='bool' id='SHORT_NAMES' defval='0'>

      <docs>

 If the \c SHORT_NAMES tag is set to \c YES, doxygen will generate much shorter

 (but less readable) file names. This can be useful is your file systems

 doesn't support long names like on DOS, Mac, or CD-ROM.

]]>

      </docs>

    </option>

    <option type='bool' id='JAVADOC_AUTOBRIEF' defval='0'>

      <docs>

  If the \c JAVADOC_AUTOBRIEF tag is set to \c YES then doxygen

  will interpret the first line (until the first dot) of a Javadoc-style

  comment as the brief description. If set to \c NO, the 

  Javadoc-style will behave just like regular Qt-style comments

  (thus requiring an explicit \ref cmdbrief "\@brief" command for a brief description.)

]]>

      </docs>

    </option>

    <option type='bool' id='QT_AUTOBRIEF' defval='0'>

      <docs>

  If the \c QT_AUTOBRIEF tag is set to \c YES then doxygen

  will interpret the first line (until the first dot) of a Qt-style

  comment as the brief description. If set to \c NO, the

  Qt-style will behave just like regular Qt-style comments (thus

  requiring an explicit \ref cmdbrief "\\brief" command for a brief description.)

]]>

      </docs>

    </option>

    <option type='bool' id='MULTILINE_CPP_IS_BRIEF' defval='0'>

      <docs>

  The \c MULTILINE_CPP_IS_BRIEF tag can be set to \c YES to make doxygen

  treat a multi-line C++ special comment block (i.e. a block of \c //! or \c ///

  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 \c YES if you prefer the old behavior instead.

  
Note that setting this tag to \c YES also means that rational rose comments

  are not recognized any more.

]]>

      </docs>

    </option>

    <option type='bool' id='INHERIT_DOCS' defval='1'>

      <docs>

 If the \c INHERIT_DOCS tag is set to \c YES then an undocumented

 member inherits the documentation from any documented member that it

 re-implements.

]]>

      </docs>

    </option>

    <option type='bool' id='SEPARATE_MEMBER_PAGES' defval='0'>

      <docs>

 If the \c SEPARATE_MEMBER_PAGES tag is set to \c YES then doxygen will produce

 a new page for each member. If set to \c NO, the documentation of a member will

 be part of the file/class/namespace that contains it.

]]>

      </docs>

    </option>

    <option type='int' id='TAB_SIZE' minval='1' maxval='16' defval='4'>

      <docs>

 The \c 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.

]]>

      </docs>

    </option>

    <option type='list' id='ALIASES' format='string'>

      <docs>

 This tag can be used to specify a number of aliases that act

 as commands in the documentation. An alias has the form: 

\verbatim

 name=value

\endverbatim

 For example adding 

\verbatim

 "sideeffect=@par Side Effects:\n" 

\endverbatim

 will allow you to

 put the command \c \\sideeffect (or \c \@sideeffect) in the documentation, which 

 will result in a user-defined paragraph with heading "Side Effects:".

 You can put \ref cmdn "\\n"'s in the value part of an alias to insert newlines

 (in the resulting output).

 You can put `^^` in the value part of an alias to insert a newline as if 

 a physical newline was in the original file.

]]>

      </docs>

    </option>

    <option type='list' id='TCL_SUBST' format='string'>

      <docs>

 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.

]]>

      </docs>

    </option>

    <option type='bool' id='OPTIMIZE_OUTPUT_FOR_C' defval='0'>

      <docs>

 Set the \c OPTIMIZE_OUTPUT_FOR_C tag to \c 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. 

]]>

      </docs>

    </option>

    <option type='bool' id='OPTIMIZE_OUTPUT_JAVA' defval='0'>

      <docs>

 Set the \c OPTIMIZE_OUTPUT_JAVA tag to \c 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, 

 qualified scopes will look different, etc. 

]]>

      </docs>

    </option>

    <option type='bool' id='OPTIMIZE_FOR_FORTRAN' defval='0'>

      <docs>

 Set the \c OPTIMIZE_FOR_FORTRAN tag to \c YES if your project consists of Fortran 

 sources. Doxygen will then generate output that is tailored for Fortran.

]]>

      </docs>

    </option>

    <option type='bool' id='OPTIMIZE_OUTPUT_VHDL' defval='0'>

      <docs>

 Set the \c OPTIMIZE_OUTPUT_VHDL tag to \c YES if your project consists of VHDL 

 sources. Doxygen will then generate output that is tailored for VHDL.

]]>

      </docs>

    </option>

    <option type='list' id='EXTENSION_MAPPING' format='string'>

      <docs>

 Doxygen selects the parser to use depending on the extension of the files 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 \c ext is a file extension, and language is one of

 the parsers supported by doxygen: IDL, Java, Javascript, C#, C, C++, D, PHP,

 Objective-C, Python, Fortran (fixed format Fortran: FortranFixed,

 free formatted Fortran: FortranFree, unknown formatted Fortran: Fortran. In

 the later case the parser tries to guess whether the code is fixed or free

 formatted code, this is the default for Fortran type files), VHDL. 

 For instance to make doxygen treat

 .inc files as Fortran files (default is PHP), and .f files as C (default is Fortran),

 use: `inc=Fortran f=C`.

 
Note: For files without extension you can use `no_extension` as a placeholder.

 
Note that for custom extensions you also need to set \ref cfg_file_patterns "FILE_PATTERNS" otherwise the 

 files are not read by doxygen.

]]>

      </docs>

    </option>

    <option type='bool' id='MARKDOWN_SUPPORT' defval='1'>

      <docs>

 If the \c MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all 

 comments 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 formatting. 

 Disable only in case of backward compatibilities issues. 

]]>

      </docs>

    </option>

    <option type='int' id='TOC_INCLUDE_HEADINGS' minval='0' maxval='99' defval='0' depends='MARKDOWN_SUPPORT'>

      <docs>

 When the \c TOC_INCLUDE_HEADINGS tag is set to a non-zero value, all headings

 up to that level are automatically included in the table of contents, even if

 they do not have an id attribute.

 \note This feature currently applies only to Markdown headings.

]]>

      </docs>

    </option>

    <option type='bool' id='AUTOLINK_SUPPORT' defval='1'>

      <docs>

 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 putting a \c % sign in front of the word or 

 globally by setting \c AUTOLINK_SUPPORT to \c NO.

]]>

      </docs>

    </option>

    <option type='bool' id='BUILTIN_STL_SUPPORT' defval='0'>

      <docs>

 If you use STL classes (i.e. `std::string`, `std::vector`, etc.) but do not want to

 include (a tag file for) the STL sources as input, then you should

 set this tag to \c YES in order to let doxygen match functions declarations and

 definitions whose arguments contain STL classes (e.g. `func(std::string`); versus

 `func(std::string) {}`). This also make the inheritance and collaboration

 diagrams that involve STL classes more complete and accurate.

]]>

      </docs>

    </option>

    <option type='bool' id='CPP_CLI_SUPPORT' defval='0'>

      <docs>

 If you use Microsoft's C++/CLI language, you should set this option to \c YES to

 enable parsing support.

]]>

      </docs>

    </option>

    <option type='bool' id='SIP_SUPPORT' defval='0'>

      <docs>

 Set the \c SIP_SUPPORT tag to \c 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. 

]]>

      </docs>

    </option>

    <option type='bool' id='IDL_PROPERTY_SUPPORT' defval='1'>

      <docs>

 For Microsoft's IDL there are \c propget and \c propput attributes to indicate getter

 and setter methods for a property. Setting this option to \c 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 \c NO.

]]>

      </docs>

    </option>

    <option type='bool' id='DISTRIBUTE_GROUP_DOC' defval='0'>

      <docs>

 If member grouping is used in the documentation and the \c DISTRIBUTE_GROUP_DOC

 tag is set to \c YES then doxygen will reuse the documentation of the first

 member in the group (if any) for the other members of the group. By default

 all members of a group must be documented explicitly.

]]>

      </docs>

    </option>

    <option type='bool' id='GROUP_NESTED_COMPOUNDS' defval='0'>

      <docs>

 If one adds a struct or class to a group and this option is enabled, then also

 any nested class or struct is added to the same group. By default this option

 is disabled and one has to add nested compounds explicitly via \ref cmdingroup "\\ingroup".

]]>

      </docs>

    </option>

    <option type='bool' id='SUBGROUPING' defval='1'>

      <docs>

 Set the \c SUBGROUPING tag to \c 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

 \c NO to prevent subgrouping. Alternatively, this can be done per class using

 the \ref cmdnosubgrouping "\\nosubgrouping" command. 

]]>

      </docs>

    </option>

    <option type='bool' id='INLINE_GROUPED_CLASSES' defval='0'>

      <docs>

 When the \c INLINE_GROUPED_CLASSES tag is set to \c YES, classes, structs and 

 unions are shown inside the group in which they are included 

 (e.g. using \ref cmdingroup "\\ingroup") instead of on a separate page (for HTML and Man pages) 

 or section (for \f$\mbox{\LaTeX}\f$ and RTF).

 
Note that this feature does not work in

 combination with \ref cfg_separate_member_pages "SEPARATE_MEMBER_PAGES".

]]>

      </docs>

    </option>

    <option type='bool' id='INLINE_SIMPLE_STRUCTS' defval='0'>

      <docs>

 When the \c INLINE_SIMPLE_STRUCTS tag is set to \c YES, structs, classes, and 

 unions with only public data fields or simple typedef fields will be shown 

 inline in the documentation of the scope in which they are defined (i.e. file, 

 namespace, or group documentation), provided this scope is documented. If set 

 to \c NO, structs, classes, and unions are shown on a separate 

 page (for HTML and Man pages) or section (for \f$\mbox{\LaTeX}\f$ and RTF).

]]>

      </docs>

    </option>

    <option type='bool' id='TYPEDEF_HIDES_STRUCT' defval='0'>

      <docs>

 When \c 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 \c TypeT. When disabled the typedef will appear as a member of a file, 

 namespace, or class. And the struct will be named \c TypeS. This can typically 

 be useful for C code in case the coding convention dictates that all compound 

 types are typedef'ed and only the typedef is referenced, never the tag name.

]]>

      </docs>

    </option>

    <option type='int' id='LOOKUP_CACHE_SIZE' minval='0' maxval='9' defval='0'>

      <docs>

 The size of the symbol lookup cache can be 

 set using \c 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: \f$2^{(16+\mbox{LOOKUP\_CACHE\_SIZE})}\f$. The valid range is 0..9, the default is 0, 

 corresponding to a cache size of \f$2^{16} = 65536\f$ 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.

]]>

      </docs>

    </option>

  </group>

  <group name='Build' docs='Build related configuration options'>

    <option type='bool' id='EXTRACT_ALL' defval='0'>

      <docs>

 If the \c EXTRACT_ALL tag is set to \c YES, doxygen will assume all 

 entities in documentation are documented, even if no documentation was 

 available. Private class members and static file members will be hidden 

 unless the \ref cfg_extract_private "EXTRACT_PRIVATE" respectively 

 \ref cfg_extract_static "EXTRACT_STATIC" tags are set to \c YES.

 \note This will also disable the warnings about undocumented members 

 that are normally produced when \ref cfg_warnings "WARNINGS" is 

 set to \c YES.

]]>

      </docs>

    </option>

    <option type='bool' id='EXTRACT_PRIVATE' defval='0'>

      <docs>

 If the \c EXTRACT_PRIVATE tag is set to \c YES, all private members of a 

 class will be included in the documentation.

]]>

      </docs>

    </option>

    <option type='bool' id='EXTRACT_PACKAGE' defval='0'>

      <docs>

 If the \c EXTRACT_PACKAGE tag is set to \c YES, all members with package 

 or internal scope will be included in the documentation. 

]]>

      </docs>

    </option>

    <option type='bool' id='EXTRACT_STATIC' defval='0'>

      <docs>

 If the \c EXTRACT_STATIC tag is set to \c YES, all static members of a file

 will be included in the documentation.

]]>

      </docs>

    </option>

    <option type='bool' id='EXTRACT_LOCAL_CLASSES' defval='1'>

      <docs>

 If the \c EXTRACT_LOCAL_CLASSES tag is set to \c YES, classes (and structs) 

 defined locally in source files will be included in the documentation. 

 If set to \c NO, only classes defined in header files are included. Does not

 have any effect for Java sources.

]]>

      </docs>

    </option>

    <option type='bool' id='EXTRACT_LOCAL_METHODS' defval='0'>

      <docs>

 This flag is only useful for Objective-C code. If set to \c YES, local 

 methods, which are defined in the implementation section but not in

 the interface are included in the documentation.

 If set to \c NO, only methods in the interface are included.

]]>

      </docs>

    </option>

    <option type='bool' id='EXTRACT_ANON_NSPACES' defval='0'>

      <docs>

 If this flag is set to \c YES, the members of anonymous namespaces will be extracted

 and appear in the documentation as a namespace called 'anonymous_namespace{file}',

 where file will be replaced with the base name of the file that contains the anonymous

 namespace. By default anonymous namespace are hidden.

]]>

      </docs>

    </option>

    <option type='bool' id='HIDE_UNDOC_MEMBERS' defval='0'>

      <docs>

 If the \c HIDE_UNDOC_MEMBERS tag is set to \c YES, doxygen will hide all

 undocumented members inside documented classes or files. 

 If set to \c NO these members will be included in the

 various overviews, but no documentation section is generated.

 This option has no effect if \ref cfg_extract_all "EXTRACT_ALL" is enabled.

]]>

      </docs>

    </option>

    <option type='bool' id='HIDE_UNDOC_CLASSES' defval='0'>

      <docs>

 If the \c HIDE_UNDOC_CLASSES tag is set to \c YES, doxygen will hide all

 undocumented classes that are normally visible in the class hierarchy. 

 If set to \c NO, these classes will be included in the

 various overviews.

 This option has no effect if \ref cfg_extract_all "EXTRACT_ALL" is enabled.

]]>

      </docs>

    </option>

    <option type='bool' id='HIDE_FRIEND_COMPOUNDS' defval='0'>

      <docs>

 If the \c HIDE_FRIEND_COMPOUNDS tag is set to \c YES, doxygen will hide all

 friend (class|struct|union) declarations.

 If set to \c NO, these declarations will be included in the

 documentation.

]]>

      </docs>

    </option>

    <option type='bool' id='HIDE_IN_BODY_DOCS' defval='0'>

      <docs>

 If the \c HIDE_IN_BODY_DOCS tag is set to \c YES, doxygen will hide any 

 documentation blocks found inside the body of a function.

 If set to \c NO, these blocks will be appended to the