index : cpython.git	2.7 3.3 3.4 3.5 3.6 benjamin-clang benjamin-iteration-torture buildbot-custom master
	https://github.com/python/cpython.git

summaryrefslogtreecommitdiffstats

log msg author committer range

path: root/Demo/stdwin

stat options

Period:	week month quarter
Authors:	102550100all

Commits per author per week (path 'Demo/stdwin')

Author	W50 2025	W51 2025	W52 2025	W01 2026	Total
Total	0	0	0	0	0

generated by cgit v0.12 at 2025-12-31 17:27:30 (GMT)

<doxygenconfig>
  <header>
    <docs doxywizard='0' doxyfile='0'>
      <![CDATA[
/*
 *
 *
 *
 * 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 (<code>=</code>) 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 <code>+=</code> operator can be used instead of <code>=</code> 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 (<code>&quot;...&quot;</code>).
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 <code>\$(ENV_VARIABLE_NAME)</code>.

You can also include part of a configuration file from another configuration
file using a <code>\@INCLUDE</code> 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 <code>\@INCLUDE_PATH</code> tag
with these paths before the <code>\@INCLUDE</code> 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'>
      <![CDATA[
This file describes the settings to be used by the documentation system
doxygen (www.doxygen.org) for a project.
<br>
All text after a double hash (##) is considered a comment and is placed
in front of the TAG it is preceding.<br>
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'>
      <![CDATA[
\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 <code>/usr/bin</code>, a more realistic configuration file would be:
\verbatim
PROJECT_NAME     = Example
INPUT            = example.cc example.h
WARNINGS         = YES
TAGFILES         = qt.tag
SEARCHENGINE     = NO
\endverbatim

To generate the documentation for the
<a href="https://sourceforge.net/projects/qdbttabular/">QdbtTabular</a> 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
SEARCHENGINE     = YES
\endverbatim

To regenerate the Qt-1.44 documentation from the sources, you could use the
following configuration 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 <a href="commands.html">next</a> section or return to the
 <a href="index.html">index</a>.
\endhtmlonly

*/
]]>
    </docs>
  </footer>

  <group name='Project' docs='Project related configuration options'>
    <option type='string' id='DOXYFILE_ENCODING' format='string' defval='UTF-8'>
      <docs>
<![CDATA[
 This tag specifies the encoding used for all characters in the configuration 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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='enum' id='OUTPUT_TEXT_DIRECTION' defval='None'>
      <docs>
<![CDATA[
 The \c OUTPUT_TEXT_DIRECTION tag is used to specify the direction in which all
 documentation generated by doxygen is written. Doxygen will use this
 information to generate all generated output in the proper direction.
]]>
      </docs>
      <value name='None'/>
      <value name='LTR'/>
      <value name='RTL'/>
      <value name='Context'/>
    </option>
    <option type='bool' id='BRIEF_MEMBER_DESC' defval='1'>
      <docs>
<![CDATA[
 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>
<![CDATA[
 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
 <br>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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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.
 <br>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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
  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='JAVADOC_BANNER' defval='0'>
      <docs>
<![CDATA[
  If the \c JAVADOC_BANNER tag is set to \c YES then doxygen
  will interpret a line such as \verbatim /***************\endverbatim as being the
  beginning of a Javadoc-style comment "banner". If set to \c NO, the
  Javadoc-style will behave just like regular comments and it will
  not be interpreted by doxygen.
]]>
      </docs>
    </option>
    <option type='bool' id='QT_AUTOBRIEF' defval='0'>
      <docs>
<![CDATA[
  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>
<![CDATA[
  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.
  <br>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='PYTHON_DOCSTRING' defval='1'>
      <docs>
<![CDATA[
  By default Python docstrings are displayed as preformatted text
  and doxygen's special commands cannot be used. By setting \c PYTHON_DOCSTRING to
  \c NO the doxygen's special commands can be used and the contents of the docstring
  documentation blocks is shown as doxygen documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='INHERIT_DOCS' defval='1'>
      <docs>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
      <docs doxyfile='0' documentation='0'>
<![CDATA[
 When you need a literal `{` or `}` or `,` in the value part of an alias you have to
 escape them by means of a backslash, this can lead to conflicts with the
 commands \c \\{ and \c \\} for these it is advised to use the version \c @{ and \c @} or
 use a double escape (\c \\\\{ and \c \\\\})
]]>
      </docs>
      <docs doxywizard='0' documentation='0'>
<![CDATA[
 When you need a literal `{` or `}` or `,` in the value part of an alias you have to
 escape them by means of a backslash (\c \\), this can lead to conflicts with the
 commands \c \\{ and \c \\} for these it is advised to use the version \c @{ and \c @} or
 use a double escape (\c \\\\{ and \c \\\\})
]]>
      </docs>
      <docs doxyfile='0' doxywizard='0'>
<![CDATA[
 When you need a literal `{` or `}` or `,` in the value part of an alias you have to
 escape them by means of a backslash (`\`), this can lead to conflicts with the
 commands \c \\{ and \c \\} for these it is advised to use the version \c @@{ and \c @@} or
 use a double escape (\c \\\\{ and \c \\\\})
]]>
      </docs>
    </option>
    <option type='bool' id='OPTIMIZE_OUTPUT_FOR_C' defval='0'>
      <docs>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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='bool' id='OPTIMIZE_OUTPUT_SLICE' defval='0'>
      <docs>
<![CDATA[
 Set the \c OPTIMIZE_OUTPUT_SLICE tag to \c YES if your project consists of Slice
 sources only. Doxygen will then generate output that is more tailored
 for that language. For instance, namespaces will be presented as modules,
 types will be separated into more groups, etc.
]]>
      </docs>
    </option>
    <option type='list' id='EXTENSION_MAPPING' format='string'>
      <docs>
<![CDATA[
 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 <code>ext=language</code>, where \c ext is a file extension, and language is one of
 the parsers supported by doxygen: IDL, Java, JavaScript, Csharp (C#), C, C++, D, PHP,
 md (Markdown), Objective-C, Python, Slice, VHDL, 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).

 For instance to make doxygen treat
 <code>.inc</code> files as Fortran files (default is PHP), and <code>.f</code> files as C (default is Fortran),
 use: `inc=Fortran f=C`.

 <br>Note: For files without extension you can use `no_extension` as a placeholder.
 <br>Note that for custom extensions you also need to set \ref cfg_file_patterns "FILE_PATTERNS" otherwise the
 files are not read by doxygen. When specifying `no_extension` you should add `*`
 to the \ref cfg_file_patterns "FILE_PATTERNS".
 <br>Note see also the list of \ref default_file_extension_mapping "default file extension mappings".
]]>
      </docs>
    </option>
    <option type='bool' id='MARKDOWN_SUPPORT' defval='1'>
      <docs>
<![CDATA[
 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 https://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='5' depends='MARKDOWN_SUPPORT'>
      <docs>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 Set the \c SIP_SUPPORT tag to \c YES if your project consists
 of <a href="https://www.riverbankcomputing.com/software/sip/intro">sip</a> 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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).
 <br>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>
<![CDATA[
 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>
<![CDATA[
 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
 <code>typedef struct TypeS {} TypeT</code>, 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'>
      <!-- be careful when changing these formulas as they are hard coded in the conversion script -->
      <docs>
<![CDATA[
 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>
    <option type='int' id='NUM_PROC_THREADS' defval='1' minval='0' maxval='32'>
      <docs>
<![CDATA[
 The \c NUM_PROC_THREADS specifies the number threads doxygen is allowed to use during
 processing. When set to \c 0 doxygen will based this on the number of cores
 available in the system. You can set it explicitly to a value larger than 0
 to get more control over the balance between CPU load and processing speed.
 At this moment only the input processing can be done using multiple threads.
 Since this is still an experimental feature the default is set to 1,
 which efficively disables parallel processing. Please report any issues you
 encounter.
 Generating dot graphs in parallel is controlled by the \c DOT_NUM_THREADS setting.
]]>
      </docs>
    </option>
  </group>
  <group name='Build' docs='Build related configuration options'>
    <option type='bool' id='EXTRACT_ALL' defval='0'>
      <docs>
<![CDATA[
 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>
<![CDATA[
 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_PRIV_VIRTUAL' defval='0'>
      <docs>
<![CDATA[
 If the \c EXTRACT_PRIV_VIRTUAL tag is set to \c YES, documented private
 virtual methods of a class will be included in the documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='EXTRACT_PACKAGE' defval='0'>
      <docs>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 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='RESOLVE_UNNAMED_PARAMS' defval='1'>
      <docs>
<![CDATA[
 If this flag is set to \c YES, the name of an unnamed parameter in a declaration will be
 determined by the corresponding definition. By default unnamed parameters remain unnamed
 in the output.
]]>
      </docs>
    </option>
    <option type='bool' id='HIDE_UNDOC_MEMBERS' defval='0'>
      <docs>
<![CDATA[
 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>
<![CDATA[
 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>
<![CDATA[
 If the \c HIDE_FRIEND_COMPOUNDS tag is set to \c YES, doxygen will hide all
 friend 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>
<![CDATA[
 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
 function's detailed documentation block.
]]>
      </docs>
    </option>
    <option type='bool' id='INTERNAL_DOCS' defval='0'>
      <docs>
<![CDATA[
 The \c INTERNAL_DOCS tag determines if documentation
 that is typed after a \ref cmdinternal "\\internal" command is included. If the tag is set
 to \c NO then the documentation will be excluded.
 Set it to \c YES to include the internal documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='CASE_SENSE_NAMES' defval='0' altdefval='Portable::fileSystemIsCaseSensitive()'>
      <docs>
<![CDATA[
 With the correct setting of option \c CASE_SENSE_NAMES doxygen will better be able to match the
 capabilities of the underlying filesystem. 

 In case the filesystem is case sensitive (i.e. it supports files in the same directory 
 whose names only differ in casing), the option must be set to \c YES to properly deal with such files
 in case they appear in the input. 
 
 For filesystems that are not case sensitive the option should be be set to \c NO to properly 
 deal with output files written for symbols that only differ in casing, such as for two classes, 
 one named \c CLASS and the other named \c Class, and to also support references to files without
 having to specify the exact matching casing.

 On Windows (including Cygwin) and MacOS, users should typically set this option to \c NO,
 whereas on Linux or other Unix flavors it should typically be set to \c YES.
]]>
      </docs>
    </option>
    <option type='bool' id='HIDE_SCOPE_NAMES' defval='0'>
      <docs>
<![CDATA[
 If the \c HIDE_SCOPE_NAMES tag is set to \c NO then doxygen
 will show members with their full class and namespace scopes in the
 documentation. If set to \c YES, the scope will be hidden.
]]>
      </docs>
    </option>
    <option type='bool' id='HIDE_COMPOUND_REFERENCE' defval='0'>
      <docs>
<![CDATA[
 If the \c HIDE_COMPOUND_REFERENCE tag is set to \c NO (default) then
 doxygen will append additional text to a page's title, such as Class Reference.
 If set to \c YES the compound reference will be hidden.
]]>
      </docs>
    </option>
    <option type='bool' id='SHOW_INCLUDE_FILES' defval='1'>
      <docs>
<![CDATA[
 If the \c SHOW_INCLUDE_FILES tag is set to \c YES then doxygen
 will put a list of the files that are included by a file in the documentation
 of that file.
]]>
      </docs>
    </option>
    <option type='bool' id='SHOW_GROUPED_MEMB_INC' defval='0'>
      <docs>
<![CDATA[
 If the SHOW_GROUPED_MEMB_INC tag is set to \c YES then Doxygen
 will add for each grouped member an include statement to the documentation,
 telling the reader which file to include in order to use the member.
]]>
      </docs>
    </option>
    <option type='bool' id='FORCE_LOCAL_INCLUDES' defval='0'>
      <docs>
<![CDATA[
 If the \c FORCE_LOCAL_INCLUDES tag is set to \c YES then doxygen
 will list include files with double quotes in the documentation
 rather than with sharp brackets.
]]>
      </docs>
    </option>
    <option type='bool' id='INLINE_INFO' defval='1'>
      <docs>
<![CDATA[
 If the \c INLINE_INFO tag is set to \c YES then a tag [inline]
 is inserted in the documentation for inline members.
]]>
      </docs>
    </option>
    <option type='bool' id='SORT_MEMBER_DOCS' defval='1'>
      <docs>
<![CDATA[
 If the \c SORT_MEMBER_DOCS tag is set to \c YES then doxygen
 will sort the (detailed) documentation of file and class members
 alphabetically by member name. If set to \c NO, the members will appear in
 declaration order.
]]>
      </docs>
    </option>
    <option type='bool' id='SORT_BRIEF_DOCS' defval='0'>
      <docs>
<![CDATA[
 If the \c SORT_BRIEF_DOCS tag is set to \c YES then doxygen will sort the
 brief descriptions of file, namespace and class members alphabetically
 by member name. If set to \c NO, the members will appear in
 declaration order. Note that this will also influence the order of the
 classes in the class list.
]]>
      </docs>
    </option>
    <option type='bool' id='SORT_MEMBERS_CTORS_1ST' defval='0'>
      <docs>
<![CDATA[
 If the \c SORT_MEMBERS_CTORS_1ST tag is set to \c YES then doxygen
 will sort the (brief and detailed) documentation of class members so that
 constructors and destructors are listed first. If set to \c NO
 the constructors will appear in the respective orders defined by
 \ref cfg_sort_brief_docs "SORT_BRIEF_DOCS" and \ref cfg_sort_member_docs "SORT_MEMBER_DOCS".
 \note If \ref cfg_sort_brief_docs "SORT_BRIEF_DOCS" is set to \c NO this option is ignored for
       sorting brief member documentation.
 \note If \ref cfg_sort_member_docs "SORT_MEMBER_DOCS" is set to \c NO this option is ignored for
       sorting detailed member documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='SORT_GROUP_NAMES' defval='0'>
      <docs>
<![CDATA[
 If the \c SORT_GROUP_NAMES tag is set to \c YES then doxygen will sort the
 hierarchy of group names into alphabetical order. If set to \c NO
 the group names will appear in their defined order.
]]>
      </docs>
    </option>
    <option type='bool' id='SORT_BY_SCOPE_NAME' defval='0'>
      <docs>
<![CDATA[
 If the \c SORT_BY_SCOPE_NAME tag is set to \c YES, the class list will be
 sorted by fully-qualified names, including namespaces. If set to
 \c NO, the class list will be sorted only by class name,
 not including the namespace part.
 \note This option is not very useful if \ref cfg_hide_scope_names "HIDE_SCOPE_NAMES" is set to \c YES.
 \note This option applies only to the class list, not to the
       alphabetical list.
]]>
      </docs>
    </option>
    <option type='bool' id='STRICT_PROTO_MATCHING' defval='0'>
      <docs>
<![CDATA[
 If the \c 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 \c STRICT_PROTO_MATCHING doxygen
 will still accept a match between prototype and implementation in such cases.
]]>
      </docs>
    </option>
    <option type='bool' id='GENERATE_TODOLIST' defval='1'>
      <docs>
<![CDATA[
 The \c GENERATE_TODOLIST tag can be used to enable (\c YES) or
 disable (\c NO) the todo list. This list is created by
 putting \ref cmdtodo "\\todo" commands in the documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='GENERATE_TESTLIST' defval='1'>
      <docs>
<![CDATA[
 The \c GENERATE_TESTLIST tag can be used to enable (\c YES) or
 disable (\c NO) the test list. This list is created by
 putting \ref cmdtest "\\test" commands in the documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='GENERATE_BUGLIST' defval='1'>
      <docs>
<![CDATA[
 The \c GENERATE_BUGLIST tag can be used to enable (\c YES) or
 disable (\c NO) the bug list. This list is created by
 putting \ref cmdbug "\\bug" commands in the documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='GENERATE_DEPRECATEDLIST' defval='1'>
      <docs>
<![CDATA[
 The \c GENERATE_DEPRECATEDLIST tag can be used to enable (\c YES) or
 disable (\c NO) the deprecated list. This list is created by
 putting \ref cmddeprecated "\\deprecated"
 commands in the documentation.
]]>
      </docs>
    </option>
    <option type='list' id='ENABLED_SECTIONS' format='string'>
      <docs>
<![CDATA[
 The \c ENABLED_SECTIONS tag can be used to enable conditional
 documentation sections, marked by \ref cmdif "\\if" \<section_label\> ...
 \ref cmdendif "\\endif" and \ref cmdcond "\\cond" \<section_label\> ...
 \ref cmdendcond "\\endcond" blocks.
]]>
      </docs>
    </option>
    <option type='int' id='MAX_INITIALIZER_LINES' minval='0' maxval='10000' defval='30'>
      <docs>
<![CDATA[
 The \c MAX_INITIALIZER_LINES tag determines the maximum number of lines
 that the initial value of a variable or macro / define can have for it to appear in
 the documentation. If the initializer
 consists of more lines than specified here it will be hidden. Use a value
 of 0 to hide initializers completely. The appearance of the value of
 individual variables and macros / defines can be controlled using \ref cmdshowinitializer "\\showinitializer"
 or \ref cmdhideinitializer "\\hideinitializer" command in the documentation regardless of this setting.
]]>
      </docs>
    </option>
    <option type='bool' id='SHOW_USED_FILES' defval='1'>
      <docs>
<![CDATA[
 Set the \c SHOW_USED_FILES tag to \c NO to disable the list of files generated
 at the bottom of the documentation of classes and structs. If set to \c YES, the
 list will mention the files that were used to generate the documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='SHOW_FILES' defval='1'>
      <docs>
<![CDATA[
 Set the \c SHOW_FILES tag to \c 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 specified).
]]>
      </docs>
    </option>
    <option type='bool' id='SHOW_NAMESPACES' defval='1'>
      <docs>
<![CDATA[
 Set the \c SHOW_NAMESPACES tag to \c 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 specified).
]]>
      </docs>
    </option>
    <option type='string' id='FILE_VERSION_FILTER' format='file' defval=''>
      <docs>
<![CDATA[
 The \c FILE_VERSION_FILTER tag can be used to specify a program or script that
 doxygen should invoke to get the current version for each file (typically from the
 version control system). Doxygen will invoke the program by executing (via
 <code>popen()</code>) the command <code>command input-file</code>, where \c command is
 the value of the \c FILE_VERSION_FILTER tag, and \c input-file is the name
 of an input file provided by doxygen.
 Whatever the program writes to standard output is used as the file version.
]]>
      </docs>
      <docs doxywizard='0' doxyfile='0'>
<![CDATA[
<br>
<br>
Example of using a shell script as a filter for Unix:
\verbatim
 FILE_VERSION_FILTER = "/bin/sh versionfilter.sh"
\endverbatim
<br>
Example shell script for CVS:
\verbatim
#!/bin/sh
cvs status $1 | sed -n 's/^[ \]*Working revision:[ \t]*\([0-9][0-9\.]*\).*/\1/p'
\endverbatim
<br>
Example shell script for Subversion:
\verbatim
#!/bin/sh
svn stat -v $1 | sed -n 's/^[ A-Z?\*|!]\{1,15\}/r/;s/ \{1,15\}/\/r/;s/ .*//p'
\endverbatim
<br>
Example filter for ClearCase:
\verbatim
FILE_VERSION_FILTER = "cleartool desc -fmt \%Vn"
\endverbatim
]]>
      </docs>
      <docs documentation='0'>
<![CDATA[
 For an example see the documentation.
]]>
      </docs>
    </option>
    <option type='string' id='LAYOUT_FILE' format='file' defval=''>
      <docs>
<![CDATA[
 The \c LAYOUT_FILE tag can be used to specify a layout file which will be parsed by
 doxygen. The layout file controls the global structure of the generated output files
 in an output format independent way. To create the layout file that represents
 doxygen's defaults, run doxygen with the `-l` option. You can optionally specify a
 file name after the option, if omitted \c DoxygenLayout.xml will be used as the name
 of the layout file.
 <br>Note that if you run doxygen from a directory containing
 a file called \c DoxygenLayout.xml, doxygen will parse it automatically even if
 the \c LAYOUT_FILE tag is left empty.
]]>
      </docs>
    </option>
    <option type='list' id='CITE_BIB_FILES' format='file'>
      <docs>
<![CDATA[
 The \c CITE_BIB_FILES tag can be used to specify one or more \c bib files
 containing the reference definitions. This must be a list of <code>.bib</code> files. The
 <code>.bib</code> extension is automatically appended if omitted. This requires the
 \c bibtex tool to be installed. See also https://en.wikipedia.org/wiki/BibTeX for
 more info. For \f$\mbox{\LaTeX}\f$ the style of the bibliography can be controlled
 using \ref cfg_latex_bib_style "LATEX_BIB_STYLE".
 To use this feature you need \c bibtex and \c perl available in the search path.
 See also \ref cmdcite "\\cite" for info how to create references.
]]>
      </docs>
    </option>
  </group>
  <group name='Messages' docs='Configuration options related to warning and progress messages'>
    <option type='bool' id='QUIET' defval='0'>
      <docs>
<![CDATA[
 The \c QUIET tag can be used to turn on/off the messages that are generated
 to standard output by doxygen. If \c QUIET is set to \c YES this implies that the messages are off.
]]>
      </docs>
    </option>
    <option type='bool' id='WARNINGS' defval='1'>
      <docs>
<![CDATA[
 The \c WARNINGS tag can be used to turn on/off the warning messages that are
 generated to standard error (\c stderr) by doxygen. If \c WARNINGS is set to
 \c YES this implies that the warnings are on.
<br>
 \b Tip: Turn warnings on while writing the documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='WARN_IF_UNDOCUMENTED' defval='1'>
      <docs>
<![CDATA[
 If the \c WARN_IF_UNDOCUMENTED tag is set to \c YES then doxygen will generate warnings
 for undocumented members. If \ref cfg_extract_all "EXTRACT_ALL" is set to \c YES then this flag will
 automatically be disabled.
]]>
      </docs>
    </option>
    <option type='bool' id='WARN_IF_DOC_ERROR' defval='1'>
      <docs>
<![CDATA[
 If the \c WARN_IF_DOC_ERROR tag is set to \c 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
 don't exist or using markup commands wrongly.
]]>
      </docs>
    </option>
    <option type='bool' id='WARN_NO_PARAMDOC' defval='0'>
      <docs>
<![CDATA[
 This \c 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 \c NO, doxygen will only warn about
 wrong or incomplete parameter documentation, but not about the absence of
 documentation.
 If \ref cfg_extract_all "EXTRACT_ALL" is set to \c YES then this flag will
 automatically be disabled.
]]>
      </docs>
    </option>
    <option type='bool' id='WARN_AS_ERROR' defval='0'>
      <docs>
<![CDATA[
 If the \c WARN_AS_ERROR tag is set to \c YES then doxygen will immediately stop
 when a warning is encountered.
]]>
      </docs>
    </option>
    <option type='string' id='WARN_FORMAT' format='string' defval='$file:$line: $text'>
      <docs>
<![CDATA[
 The \c WARN_FORMAT tag determines the format of the warning messages that
 doxygen can produce. The string should contain the <code>\$file</code>,
 <code>\$line</code>, and <code>\$text</code>
 tags, which will be replaced by the file and line number from which the
 warning originated and the warning text.
 Optionally the format may contain
 <code>$version</code>, which will be replaced by the version of the file (if it could
 be obtained via \ref cfg_file_version_filter "FILE_VERSION_FILTER")
]]>
      </docs>
    </option>
    <option type='string' id='WARN_LOGFILE' format='file' defval=''>
      <docs>
<![CDATA[
 The \c WARN_LOGFILE tag can be used to specify a file to which warning
 and error messages should be written. If left blank the output is written
 to standard error (`stderr`).
]]>
      </docs>
    </option>
  </group>
  <group name='Input' docs='Configuration options related to the input files'>
    <option type='list' id='INPUT' format='filedir'>
      <docs>
<![CDATA[
 The \c INPUT tag is used to specify the files and/or directories that contain
 documented source files. You may enter file names like
 \c myfile.cpp or directories like \c /usr/src/myproject.
 Separate the files or directories with spaces. See also
 \ref cfg_file_patterns "FILE_PATTERNS"  and
 \ref cfg_extension_mapping "EXTENSION_MAPPING"

 \note If this tag is empty the current directory is searched.
]]>
      </docs>
      <value name=''/>
    </option>
    <option type='string' id='INPUT_ENCODING' format='string' defval='UTF-8'>
      <docs>
<![CDATA[
 This tag can be used to specify the character encoding of the source files that
 doxygen parses. Internally doxygen uses the UTF-8 encoding.
 Doxygen uses `libiconv` (or the `iconv` built into `libc`) for the transcoding.
 See <a href="https://www.gnu.org/software/libiconv/">the libiconv documentation</a> for
 the list of possible encodings.
]]>
      </docs>
    </option>
    <option type='list' id='FILE_PATTERNS' format='string'>
      <docs>
<![CDATA[
 If the value of the \ref cfg_input "INPUT" tag contains directories, you can use the
 \c FILE_PATTERNS tag to specify one or more wildcard patterns
 (like `*.cpp` and `*.h`) to filter out the source-files
 in the directories.<br>
 Note that for custom extensions or not directly supported extensions you also
 need to set \ref cfg_extension_mapping "EXTENSION_MAPPING" for the extension
 otherwise the files are not read by doxygen.<br>
 Note the list of default checked file patterns might differ from the list of
 \ref default_file_extension_mapping "default file extension mappings".<br>
 If left blank the following patterns are tested:
]]>
      </docs>
      <value name='*.c'/>
      <value name='*.cc'/>
      <value name='*.cxx'/>
      <value name='*.cpp'/>
      <value name='*.c++'/>
      <value name='*.java'/>
      <value name='*.ii'/>
      <value name='*.ixx'/>
      <value name='*.ipp'/>
      <value name='*.i++'/>
      <value name='*.inl'/>
      <value name='*.idl'/>
      <value name='*.ddl'/>
      <value name='*.odl'/>
      <value name='*.h'/>
      <value name='*.hh'/>
      <value name='*.hxx'/>
      <value name='*.hpp'/>
      <value name='*.h++'/>
      <value name='*.cs'/>
      <value name='*.d'/>
      <value name='*.php'/>
      <value name='*.php4'/>
      <value name='*.php5'/>
      <value name='*.phtml'/>
      <value name='*.inc'/>
      <value name='*.m'/>
      <value name='*.markdown'/>
      <value name='*.md'/>
      <value name='*.mm'/>
      <value name='*.dox' desc='(to be provided as doxygen C comment)'/>
      <value name='*.py'/>
      <value name='*.pyw'/>
      <value name='*.f90'/>
      <value name='*.f95'/>
      <value name='*.f03'/>
      <value name='*.f08'/>
      <value name='*.f18'/>
      <value name='*.f'/>
      <value name='*.for'/>
      <value name='*.vhd'/>
      <value name='*.vhdl'/>
      <value name='*.ucf'/>
      <value name='*.qsf'/>
      <value name='*.ice'/>
    </option>
    <option type='bool' id='RECURSIVE' defval='0'>
      <docs>
<![CDATA[
 The \c RECURSIVE tag can be used to specify whether or not subdirectories
 should be searched for input files as well.
]]>
      </docs>
    </option>
    <option type='list' id='EXCLUDE' format='filedir'>
      <docs>
<![CDATA[
 The \c EXCLUDE tag can be used to specify files and/or directories that should be
 excluded from the \ref cfg_input "INPUT" source files. This way you can easily exclude a
 subdirectory from a directory tree whose root is specified with the \ref cfg_input "INPUT" tag.
 <br>Note that relative paths are relative to the directory from which doxygen is run.
]]>
      </docs>
    </option>
    <option type='bool' id='EXCLUDE_SYMLINKS' defval='0'>
      <docs>
<![CDATA[
 The \c EXCLUDE_SYMLINKS tag can be used to select whether or not files or directories
 that are symbolic links (a Unix file system feature) are excluded from the input.
]]>
      </docs>
    </option>
    <option type='list' id='EXCLUDE_PATTERNS' format='string'>
      <docs>
<![CDATA[
 If the value of the \ref cfg_input "INPUT" tag contains directories, you can use the
 \c EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
 certain files from those directories.
 <br>Note that the wildcards are matched
 against the file with absolute path, so to exclude all test directories
 for example use the pattern `*``/test/``*`
]]>
      </docs>
    </option>
    <option type='list' id='EXCLUDE_SYMBOLS' format='string'>
      <docs>
<![CDATA[
 The \c EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
 (namespaces, classes, functions, etc.) that should be excluded from the
 output. The symbol name can be a fully qualified name, a word, or if the
 wildcard `*` is used, a substring. Examples: `ANamespace`, `AClass`,
 `AClass::ANamespace`, `ANamespace::*Test`
 <br>Note that the wildcards are matched against the file with absolute path,
 so to exclude all test directories use the pattern
 `*``/test/``*`
]]>
      </docs>
    </option>
    <option type='list' id='EXAMPLE_PATH' format='filedir'>
      <docs>
<![CDATA[
 The \c EXAMPLE_PATH tag can be used to specify one or more files or
 directories that contain example code fragments that are included (see
 the \ref cmdinclude "\\include" command).
]]>
      </docs>
    </option>
    <option type='list' id='EXAMPLE_PATTERNS' format='string'>
      <docs>
<![CDATA[
 If the value of the \ref cfg_example_path "EXAMPLE_PATH" tag contains directories,
 you can use the
 \c EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like `*.cpp`
 and `*.h`) to filter out the source-files in the directories. If left
 blank all files are included.
]]>
      </docs>
      <value name='*' show_docu='NO'/>
    </option>
    <option type='bool' id='EXAMPLE_RECURSIVE' defval='0'>
      <docs>
<![CDATA[
 If the \c EXAMPLE_RECURSIVE tag is set to \c YES then subdirectories will be
 searched for input files to be used with the \ref cmdinclude "\\include" or
 \ref cmddontinclude "\\dontinclude"
 commands irrespective of the value of the \ref cfg_recursive "RECURSIVE" tag.
]]>
      </docs>
    </option>
    <option type='list' id='IMAGE_PATH' format='filedir'>
      <docs>
<![CDATA[
 The \c IMAGE_PATH tag can be used to specify one or more files or
 directories that contain images that are to be included in the
 documentation (see the \ref cmdimage "\\image" command).
]]>
      </docs>
    </option>
    <option type='string' id='INPUT_FILTER' format='file' defval=''>
      <docs>
<![CDATA[
 The \c INPUT_FILTER tag can be used to specify a program that doxygen should
 invoke to filter for each input file. Doxygen will invoke the filter program
 by executing (via <code>popen()</code>) the command:
 <br>
   <code>\<filter\> \<input-file\></code>
 <br>
 where <code>\<filter\></code>
 is the value of the \c INPUT_FILTER tag, and <code>\<input-file\></code> is the name of an
 input file. Doxygen will then use the output that the filter program writes
 to standard output.  If \ref cfg_filter_patterns "FILTER_PATTERNS" is specified, this tag will be ignored.
 <br>Note that the filter 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.
 <br>Note that for custom extensions or not directly supported extensions you also
 need to set \ref cfg_extension_mapping "EXTENSION_MAPPING" for the extension
 otherwise the files are not properly processed by doxygen.<br>

]]>
      </docs>
    </option>
    <option type='list' id='FILTER_PATTERNS' format='string'>
      <docs>
<![CDATA[
 The \c FILTER_PATTERNS tag can be used to specify filters on a per file pattern
 basis. Doxygen will compare the file name with each pattern and apply the
 filter if there is a match. The filters are a list of the form:
 pattern=filter (like `*.cpp=my_cpp_filter`). See \ref cfg_input_filter "INPUT_FILTER" for further
 information on how filters are used. If the \c FILTER_PATTERNS tag is empty or if
 none of the patterns match the file name, \ref cfg_input_filter "INPUT_FILTER" is
 applied.
 <br>Note that for custom extensions or not directly supported extensions you also
 need to set \ref cfg_extension_mapping "EXTENSION_MAPPING" for the extension
 otherwise the files are not properly processed by doxygen.<br>
]]>
      </docs>
    </option>
    <option type='bool' id='FILTER_SOURCE_FILES' defval='0'>
      <docs>
<![CDATA[
 If the \c FILTER_SOURCE_FILES tag is set to \c YES, the input filter (if set using
 \ref cfg_input_filter "INPUT_FILTER") will also be used to filter the input
 files that are used for producing the source files to browse
 (i.e. when \ref cfg_source_browser "SOURCE_BROWSER" is set to \c YES).
]]>
      </docs>
    </option>
    <option type='list' id='FILTER_SOURCE_PATTERNS' format='string' depends='FILTER_SOURCE_FILES'>
      <docs>
<![CDATA[
 The \c FILTER_SOURCE_PATTERNS tag can be used to specify source filters per
 file pattern. A pattern will override the setting
 for \ref cfg_filter_patterns "FILTER_PATTERN" (if any)
 and it is also possible to disable source filtering for a specific pattern
 using `*.ext=` (so without naming a filter).
]]>
      </docs>
    </option>
    <option type='string' id='USE_MDFILE_AS_MAINPAGE' format='string' defval=''>
      <docs>
<![CDATA[
 If the \c USE_MDFILE_AS_MAINPAGE tag refers to the name of a markdown file 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.
]]>
      </docs>
    </option>
  </group>
  <group name='Source_Browser' docs='Configuration options related to source browsing'>
    <option type='bool' id='SOURCE_BROWSER' defval='0'>
      <docs>
<![CDATA[
 If the \c SOURCE_BROWSER tag is set to \c YES then a list of source files will
 be generated. Documented entities will be cross-referenced with these sources.
 <br>Note: To get rid of all source code in the generated output, make sure that also
 \ref cfg_verbatim_headers "VERBATIM_HEADERS" is set to \c NO.
]]>
      </docs>
    </option>
    <option type='bool' id='INLINE_SOURCES' defval='0'>
      <docs>
<![CDATA[
 Setting the \c INLINE_SOURCES tag to \c YES will include the body
 of functions, classes and enums directly into the documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='STRIP_CODE_COMMENTS' defval='1'>
      <docs>
<![CDATA[
 Setting the \c STRIP_CODE_COMMENTS tag to \c 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.
]]>
      </docs>
    </option>
    <option type='bool' id='REFERENCED_BY_RELATION' defval='0'>
      <docs>
<![CDATA[
 If the \c REFERENCED_BY_RELATION tag is set to \c YES
 then for each documented entity all documented
 functions referencing it will be listed.
]]>
      </docs>
    </option>
    <option type='bool' id='REFERENCES_RELATION' defval='0'>
      <docs>
<![CDATA[
 If the \c REFERENCES_RELATION tag is set to \c YES
 then for each documented function all documented entities
 called/used by that function will be listed.
]]>
      </docs>
    </option>
    <option type='bool' id='REFERENCES_LINK_SOURCE' defval='1'>
      <docs>
<![CDATA[
 If the \c REFERENCES_LINK_SOURCE tag is set to \c YES
 and \ref cfg_source_browser "SOURCE_BROWSER" tag is set to \c YES then the hyperlinks from
 functions in \ref cfg_references_relation "REFERENCES_RELATION" and
 \ref cfg_referenced_by_relation "REFERENCED_BY_RELATION" lists will
 link to the source code.  Otherwise they will link to the documentation.
]]>
      </docs>
    </option>
    <option type='bool' id='SOURCE_TOOLTIPS' defval='1' depends='SOURCE_BROWSER'>
      <docs>
<![CDATA[
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 definition and documentation. Since this will
make the HTML file larger and loading of large files a bit slower, you can opt
to disable this feature.
]]>
      </docs>
    </option>
    <option type='bool' id='USE_HTAGS' defval='0' depends='SOURCE_BROWSER'>
      <docs>
<![CDATA[
 If the \c USE_HTAGS tag is set to \c YES then the references to source code
 will point to the HTML generated by the \c htags(1) tool instead of doxygen
 built-in source browser. The \c htags tool is part of GNU's global source
 tagging system (see https://www.gnu.org/software/global/global.html). You
 will need version 4.8.6 or higher.
<br>
 To use it do the following:
 -# Install the latest version of \c global
 -# Enable \ref cfg_source_browser "SOURCE_BROWSER" and \c USE_HTAGS in the configuration file
 -# Make sure the \ref cfg_input "INPUT" points to the root of the source tree
 -# Run \c doxygen as normal
<br>
 Doxygen will invoke \c htags (and that will in turn invoke \c gtags), so these tools
 must be available from the command line (i.e. in the search path).
<br>
 The result: instead of the source browser generated by doxygen, the links to
 source code will now point to the output of \c htags.
]]>
      </docs>
    </option>

    <option type='bool' id='VERBATIM_HEADERS' defval='1'>
      <docs>
<![CDATA[
  If the \c VERBATIM_HEADERS tag is set the \c YES then doxygen
  will generate a verbatim copy of the header file for each class for
  which an include is specified. Set to \c NO to disable this.
  \sa Section \ref cmdclass "\\class".
]]>
      </docs>
    </option>
    <option type='bool' id='CLANG_ASSISTED_PARSING' setting='USE_LIBCLANG' defval='0'>
      <docs>
<![CDATA[
  If the \c CLANG_ASSISTED_PARSING tag is set to \c YES then doxygen will use the
  <a href="http://clang.llvm.org/">clang parser</a> for more accurate parsing
  at the cost of reduced performance. This can be particularly helpful with
  template rich C++ code for which doxygen's built-in parser lacks the
  necessary type information.

  @note The availability of this option depends on whether or not doxygen
  was generated with the `-Duse_libclang=ON` option for CMake.
]]>
      </docs>
    </option>
    <option type='list' id='CLANG_OPTIONS' format='string' setting='USE_LIBCLANG' depends='CLANG_ASSISTED_PARSING'>
      <docs>
<![CDATA[
 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 files and directories
 specified with \ref cfg_input "INPUT" and \ref cfg_include_path "INCLUDE_PATH".
]]>
      </docs>
    </option>
    <option type='string' id='CLANG_DATABASE_PATH' setting='USE_LIBCLANG' defval=''>
      <docs>
<![CDATA[
 If clang assisted parsing is enabled you can provide the clang parser with the
 path to the directory containing a file called `compile_commands.json`.
 This file is the <a href="http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html">
 compilation database</a> containing the options used when the source files were built.
 This is equivalent to specifying the `-p` option to a clang tool, such as `clang-check`.
 These options will then be passed to the parser. Any options specified with
 \ref cfg_clang_options "CLANG_OPTIONS" will be added as well.

 @note The availability of this option depends on whether or not doxygen
 was generated with the `-Duse_libclang=ON` option for CMake.
 ]]>
        </docs>
    </option>
  </group>
  <group name='Index' docs='Configuration options related to the alphabetical class index'>
    <option type='bool' id='ALPHABETICAL_INDEX' defval='1'>
      <docs>
<![CDATA[
 If the \c ALPHABETICAL_INDEX tag is set to \c YES, an alphabetical index
 of all compounds will be generated. Enable this if the project contains
 a lot of classes, structs, unions or interfaces.
]]>
      </docs>
    </option>