/
config.xml
3561 lines (3507 loc) · 140 KB
/
config.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<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>"..."</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
PERL_PATH = /usr/local/bin/perl
SEARCHENGINE = NO
\endverbatim
To generate the documentation for the
<a href="http://www.stack.nl/~dimitri/qdbttabular/index.html">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
PERL_PATH = /usr/bin/perl
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='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='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>
</option>
<option type='list' id='TCL_SUBST' format='string'>
<docs>
<![CDATA[
This tag can be used to specify a number of word-keyword mappings (TCL only).
A mapping has the form <code>"name=value"</code>. For example adding
<code>"class=itcl::class"</code> will allow you to use the command class in the
<code>itcl::class</code> meaning.
]]>
</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='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, 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
<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.
]]>
</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 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>
<![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>
</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_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='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 (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>
<![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[
If the \c CASE_SENSE_NAMES tag is set to \c NO then doxygen
will only generate file names in lower-case letters. If set to
\c YES, upper-case letters are also allowed. This is useful if you have
classes or files whose names only differ in case and if your file system
supports case sensitive file names. Windows and Mac users are advised to set this
option to \c NO.
]]>
</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.