You should use the \mainpage command inside a comment block like this:
/*! \mainpage My Personal Index Page * * \section intro_sec Introduction * * This is the introduction. * * \section install_sec Installation * * \subsection step1 Step 1: Opening the box * * etc... */
Check the following:
YES
in the configuration file. YES
to make them appear in the documentation. Is there a function macro in your class that does not end with a semicolon (e.g. MY_MACRO())? If so then you have to instruct Doxygen's preprocessor to remove it.
This typically boils down to the following settings in the configuration file:
ENABLE_PREPROCESSING = YES MACRO_EXPANSION = YES EXPAND_ONLY_PREDEF = YES PREDEFINED = MY_MACRO()=
Please read the preprocessing section of the manual for more information.
In order for global functions, variables, enums, typedefs, and defines to be documented you should document the file in which these commands are located using a comment block containing a \file (or @file) command.
Alternatively, you can put all members in a group (or topic) using the \ingroup command and then document the group using a comment block containing the \defgroup command.
For member functions or functions that are part of a namespace you should document either the class or namespace.
Doxygen only parses files that are specified as input (via the INPUT tag) and that match a specified extension (mentioned in FILE_PATTERNS) The list of files is then reduced by excluding files listed as EXCLUDE or files that match the patterns set by EXCLUDE_PATTERNS.
In the past Doxygen parsed all files with an unknown extension as C files which could lead to undesired results. Since version 1.8.8, Doxygen requires that you specify a mapping that tells for a certain file extension, which parser to use. This mapping is specified using the EXTENSION_MAPPING tag. If no mapping is specified the file's contents will be ignored.
The new and easiest way is to add one comment block with a \cond command at the start and one comment block with a \endcond command at the end of the piece of code that should be ignored. This should be within the same file of course.
But you can also use Doxygen's preprocessor for this: If you put
#ifndef DOXYGEN_SHOULD_SKIP_THIS /* code that must be skipped by Doxygen */ #endif /* DOXYGEN_SHOULD_SKIP_THIS */
around the blocks that should be hidden and put:
PREDEFINED = DOXYGEN_SHOULD_SKIP_THIS
in the configuration file then all blocks should be skipped by Doxygen as long as ENABLE_PREPROCESSING is set to YES
.
In most cases you can use STRIP_FROM_INC_PATH to strip a user defined part of a path.
You can also document your class as follows
/*! \class MyClassName include.h path/include.h * * Docs for MyClassName */
To make Doxygen put
#include <path/include.h>
in the documentation of the class MyClassName regardless of the name of the actual header file in which the definition of MyClassName is contained.
If you want Doxygen to show that the include file should be included using quotes instead of angle brackets you should type:
/*! \class MyClassName myhdr.h "path/myhdr.h" * * Docs for MyClassName */
If you want to refer from one compressed HTML file a.chm
to another compressed HTML file called b.chm
, the link in a.chm
must have the following format:
<a href="mk:@MSITStore:b.chm::/file.html">
Unfortunately this only works if both compressed HTML files are in the same directory.
As a result you must rename the generated index.chm
files for all projects into something unique and put all .chm
files in one directory.
Suppose you have a project a referring to a project b using tag file b.tag
, then you could rename the index.chm
for project a into a.chm
and the index.chm
for project b into b.chm
. In the configuration file for project a you write:
TAGFILES = b.tag=mk:@MSITStore:b.chm::
You can disable the index by setting DISABLE_INDEX to YES
. Then you can put in your own header file by writing your own header and feed that to HTML_HEADER.
You probably forgot to include the stylesheet doxygen.css
that Doxygen generates. You can include this by putting
<LINK HREF="doxygen.css" REL="stylesheet" TYPE="text/css">
in the HEAD section of the HTML page.
In the past (prior to version 1.9.2) Doxygen used a part of Qt 2.x for various utility classes. These have been replaced by STL container classes in the meantime.
The GUI front-end called Doxywizard is based on a modern version of Qt. Doxygen itself can also be used without the GUI.
Simply put an exclude pattern like this in the configuration file:
EXCLUDE_PATTERNS = */test/*
Put a % in front of the class name. Like this: %MyClass. Doxygen will then remove the % and keep the word unlinked.
No, not as such; Doxygen needs to understand the structure of what it reads. If you don't mind spending some time on it, there are several options:
src/scanner.l
a bit so the language is supported. This is done for all other languages directly supported by Doxygen (i.e. Java, IDL, C#, PHP).src/scanner.l
(and also by src/tagreader.cpp
while reading tag files).This error happens when Doxygen's lexical scanner has a rule that matches more than 256K of input characters in one go. I've seen this happening on a very large generated file (>256K lines), where the built-in preprocessor converted it into an empty file (with >256K of newlines). Another case where this might happen is if you have lines in your code with more than 256K characters.
If you have run into such a case and want me to fix it, you should send me a code fragment that triggers the message. To work around the problem, put some line-breaks into your file, split it up into smaller parts, or exclude it from the input using EXCLUDE.
Another way to work around this problem is to use the cmake command with the option:
where <size>
is the new size of the input (YY_BUF_SIZE
) and read (YY_READ_BUF_SIZE
) buffer. In case this option is not given the default value of 262144 (i.e. 256K) will be used.
You can edit the texmf.cfg file to increase the default values of the various buffers and then run "texconfig init".
Doxygen is unaware of the STL classes, unless the option BUILTIN_STL_SUPPORT is turned on.
Please read this for hints on where to look.
Not via command line options, but Doxygen can read from stdin
, so you can pipe things through it. Here's an example how to override an option in a configuration file from the command line (assuming a UNIX like environment):
( cat Doxyfile ; echo "PROJECT_NUMBER=1.0" ) | doxygen -
For Windows command line the following would do the same:
( type Doxyfile & echo PROJECT_NUMBER=1.0 ) | doxygen.exe -
For Windows Powershell (checked with version 5.1) the following would do the same:
&{ type Doxyfile ; echo "PROJECT_NUMBER=1.0" } | doxygen -
If multiple options with the same name are specified then Doxygen will use the last one. To append to an existing option you can use the += operator.
Doxygen got its name from playing with the words documentation and generator.
documentation -> docs -> dox generator -> gen
At the time I was looking into lex
and yacc
, where a lot of things start with "yy", so the "y" slipped in and made things pronounceable (the proper pronouncement is Docs-ee-gen, so with a long "e").
I once wrote a GUI widget based on the Qt library (it is still available at https://sourceforge.net/projects/qdbttabular/ but hasn't been updated since 2002). Qt had nicely generated documentation (using an internal tool which they didn't want to release) and I wrote similar docs by hand. This was a nightmare to maintain, so I wanted a similar tool. I looked at Doc++ but that just wasn't good enough (it didn't support signals and slots and did not have the Qt look and feel I had grown to like), so I started to write my own tool...
When redirecting all the console output of Doxygen, i.e. messages and warnings, this can be interleaved or in a non-expected order. The, technical, reason for this is that the stdout
can be buffered. It is possible to overcome this by means of the -b
of Doxygen, like e.g doxygen -b > out.txt 2>&1
. Note this might cost a little more time though.