LinuxCommandLibrary
GitHubF-DroidGoogle Play Store

doxygen

documentation generator for source code

TLDR

Generate default config file
$ doxygen -g [Doxyfile]
copy
Generate documentation
$ doxygen [Doxyfile]
copy
Generate with updates to config
$ doxygen -u [Doxyfile]
copy
Generate a minimal config without the explanatory comments
$ doxygen -g -s [Doxyfile]
copy
Read the config from stdin and generate
$ cat [Doxyfile] | doxygen -
copy
Launch the GUI front end
$ doxywizard
copy

SYNOPSIS

doxygen [configfile]doxygen [-g|-u|-s|-l|-w|-x] [file]

DESCRIPTION

Doxygen is the standard documentation generator for C++, C, Java, Python, and other languages. It extracts documentation from specially-formatted comments in source code and generates output in HTML, LaTeX, RTF, and other formats.The tool parses source code, builds a cross-referenced documentation structure, and renders it with class diagrams, call graphs, and inheritance trees. Special comment markers (///, /**, etc.) identify documentation blocks.Doxygen understands Markdown inside comments, and it will happily document a codebase that has no documentation comments at all, producing a browsable, cross-referenced index of every class, function, and file from the declarations alone. That is often reason enough to run it on an unfamiliar project.Beyond C++ and C it handles Java, Python, C#, PHP, Objective-C, Fortran, and IDL, and it will read Javadoc- and Qt-style comment blocks as well as its own.

PARAMETERS

CONFIGFILE

The configuration file to use. Defaults to `Doxyfile` in the current directory. A single - reads the configuration from standard input.
-g [FILE]
Generate a template configuration file, fully commented. Writes `Doxyfile` if no name is given.
-u [FILE]
Update an existing configuration file to the current Doxygen version, preserving your settings and adding any new options with their defaults.
-s
Omit the explanatory comments. Combines with -g and -u to produce a short config that is far easier to keep in version control.
-x [FILE]
Print the differences between the given configuration and the defaults. The quickest way to see what a project has actually customised.
-l [FILE]
Generate a layout file (`DoxygenLayout.xml`) that controls the ordering and presence of sections in the output.
-w FORMAT ...
Generate style sheet or template files. FORMAT is `html`, `latex`, or `rtf`.
-d MODE
Enable a debug mode, such as `Preprocessor` or `FilterOutput`.
-b
Run with unbuffered output, so progress appears immediately when piped.
-v, --version
Show the version and exit.
--help
Display help information.

CONFIGURATION

Doxyfile

Main configuration file for project documentation settings, output formats, and parsing options.

INSTALL

sudo apt install doxygen
copy
sudo dnf install doxygen
copy
sudo pacman -S doxygen
copy
sudo apk add doxygen
copy
sudo zypper install doxygen
copy
brew install doxygen
copy
nix profile install nixpkgs#doxygen
copy

CAVEATS

The generated `Doxyfile` is enormous, several hundred settings with page after page of comments. Generating it with -g -s and keeping only what you change makes it reviewable; -x shows what an inherited config actually alters.Diagrams are the usual disappointment. Class hierarchies, collaboration diagrams, call graphs, and include graphs all require Graphviz, so `HAVE_DOT` must be set to `YES` and `dot` must be on the PATH, otherwise Doxygen silently falls back to crude built-in images. Call graphs on a large codebase also generate an enormous number of images and can make a build take hours.Doxygen only documents what it can parse. Heavy preprocessor use, template metaprogramming, and macros that expand into declarations routinely confuse it, which is what `ENABLEPREPROCESSING`, `MACROEXPANSION`, and `PREDEFINED` exist to work around. And the output is only as good as the comments: run with `WARNIFUNDOCUMENTED` and `WARNASERROR` in CI if the documentation is meant to stay complete.

HISTORY

Doxygen was written by Dimitri van Heesch and first released in 1997, originally as a tool for generating Qt-style documentation for his own C++ code. It filled an obvious gap, since Java had Javadoc but C++ had nothing comparable, and it became the de facto standard for C and C++ documentation almost by default. It is still maintained by van Heesch, now on GitHub, close to three decades on.

SEE ALSO

dot(1), cppcheck(1), javadoc(1), sphinx-build(1)

RESOURCES

Copied to clipboard
Kai