diff --git a/.github/workflows/docbuild.yaml b/.github/workflows/docbuild.yaml new file mode 100644 index 00000000000000..a12a0567e222cf --- /dev/null +++ b/.github/workflows/docbuild.yaml @@ -0,0 +1,50 @@ +name: Documentation Build + +on: + push: + branches: + - master + +permissions: + contents: write + +jobs: + build-and-deploy: + runs-on: ubuntu-latest + + steps: + - name: Checkout the code + uses: actions/checkout@v2 + with: + path: matter + fetch-depth: 0 + - name: Install Python + uses: actions/setup-python@v2 + with: + python-version: 3.8 + - name: cache-pip + uses: actions/cache@v1 + with: + path: ~/.cache/pip + key: ${{ runner.os }}-doc-pip + - name: Install base dependencies + working-directory: matter + run: | + sudo apt update + sudo pip3 install -U pip + pip3 install -r docs/requirements.txt + - name: Build documentation + working-directory: matter/docs + run: | + mkdir -p _build/src + make html + touch _build/html/.nojekyll + - name: Deploy to gh-pages + if: github.repository == 'project-chip/connectedhomeip' + uses: peaceiris/actions-gh-pages@v3 + with: + deploy_key: ${{ secrets.DOXYGEN_DEPLOY_KEY }} + external_repository: project-chip/connectedhomeip-doc + publish_dir: matter/docs/_build/html + # Keep only the latest version of the documentation + force_orphan: true \ No newline at end of file diff --git a/.gitignore b/.gitignore index 5baec0fd0ed020..bba10433b503e3 100644 --- a/.gitignore +++ b/.gitignore @@ -47,8 +47,11 @@ __pycache__ *.pyc *.egg-info -# Doxygen outputs -docs/html +# Python venv +.venv + +# Documentation +docs/_build # VSCode java extensions .project diff --git a/.spellcheck.yml b/.spellcheck.yml index 225ab2ed951c8f..31535866750a72 100644 --- a/.spellcheck.yml +++ b/.spellcheck.yml @@ -46,7 +46,11 @@ matrix: # ```python # content # ``` - - open: '(?s)^(?P *`{3,})[a-z]*$' + # + # Allow MyST extended syntax like: + # ```{include} my/file.md + # ``` + - open: '(?s)^(?P *`{3,})([a-z]*$|{[a-z]*?}\s*[^\n]*?$)' close: '^(?P=open)$' # Ignore text between inline back ticks - open: '(?P`+)' diff --git a/docs/Doxyfile b/docs/Doxyfile index 279399498d80c2..9cb29526498d3c 100644 --- a/docs/Doxyfile +++ b/docs/Doxyfile @@ -830,7 +830,7 @@ INPUT = README.md \ docs/guides/BUILDING.md \ docs/VSCODE_DEVELOPMENT.md \ docs/PROJECT_FLOW.md \ - docs/STYLE_GUIDE.md \ + docs/style/style_guide.md \ src/ble \ src/controller \ src/crypto \ diff --git a/docs/Makefile b/docs/Makefile new file mode 100644 index 00000000000000..30826e465ad549 --- /dev/null +++ b/docs/Makefile @@ -0,0 +1,21 @@ +# Minimal makefile for Sphinx documentation +# + +# You can set these variables from the command line, and also +# from the environment for the first two. +SPHINXOPTS ?= -W -c . -d _build/doctrees +SPHINXBUILD ?= sphinx-build +SOURCEDIR = _build/src +BUILDDIR = _build + +# Put it first so that "make" without argument is like "make help". +help: + @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) + +.PHONY: help Makefile + +# Catch-all target: route all unknown targets to Sphinx using the new +# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS). +%: Makefile + mkdir -p "$(SOURCEDIR)" + @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O) diff --git a/docs/README.md b/docs/README.md index dcb17c3552e56c..e4ec9c8f3a5523 100644 --- a/docs/README.md +++ b/docs/README.md @@ -24,7 +24,7 @@ ## Style Guide - Documentation about style is documented in - [the style guide](./STYLE_GUIDE.md) + [the style guide](./style/style_guide.md) - Additional documentation about more specific files are in the [style folder](./style/) diff --git a/docs/_extensions/external_content.py b/docs/_extensions/external_content.py new file mode 100644 index 00000000000000..a4018c7d577b99 --- /dev/null +++ b/docs/_extensions/external_content.py @@ -0,0 +1,241 @@ +""" +External content +################ + +Copyright (c) 2021 Nordic Semiconductor ASA +SPDX-License-Identifier: Apache-2.0 + +Introduction +============ + +This extension allows to import sources from directories out of the Sphinx +source directory. They are copied to the source directory before starting the +build. Note that the copy is *smart*, that is, only updated files are actually +copied. Therefore, incremental builds detect changes correctly and behave as +expected. + +Links to external content not included in the generated documentation are +transformed to external links as needed. + +Configuration options +===================== + +- ``external_content_contents``: A list of external contents. Each entry is + a tuple with two fields: the external base directory and a file glob pattern. +- ``external_content_link_prefixes``: A list of link prefixes out of scope. + All links to content with these prefixes are made external. +- ``external_content_link_extensions``: A list of file extensions in scope of + the documentation. All links to content without these file extensions are + made external. +- ``external_content_keep``: A list of file globs (relative to the destination + directory) that should be kept even if they do not exist in the source + directory. This option can be useful for auto-generated files in the + destination directory. +""" + +import filecmp +import os +from pathlib import Path +import re +import shutil +import tempfile +from typing import Dict, Any, List, Optional + +from sphinx.application import Sphinx + +__version__ = "0.1.0" + +DIRECTIVES = ("figure", "image", "include", "literalinclude") +"""Default directives for included content.""" + +EXTERNAL_LINK_URL_PREFIX = ( + "https://github.com/project-chip/connectedhomeip/blob/master/" +) + + +def adjust_includes( + fname: Path, + basepath: Path, + encoding: str, + link_prefixes: List[str], + extensions: List[str], + dstpath: Optional[Path] = None, +) -> None: + """Adjust included content paths. + + Args: + fname: File to be processed. + basepath: Base path to be used to resolve content location. + encoding: Sources encoding. + link_prefixes: Prefixes of links that are made external. + extensions: Filename extensions links to which are not made external. + dstpath: Destination path for fname if its path is not the actual destination. + """ + + if fname.suffix != ".md": + return + + dstpath = dstpath or fname.parent + + def _adjust_path(path): + # ignore absolute paths, section links, hyperlinks and same folder + if path.startswith(("/", "#", "http", "www")) or not "/" in path: + return path + return Path(os.path.relpath(basepath / path, dstpath)).as_posix() + + def _adjust_links(m): + displayed, fpath = m.groups() + fpath_adj = _adjust_path(fpath) + return f"[{displayed}]({fpath_adj})" + + def _adjust_external(m): + displayed, target = m.groups() + return f"[{displayed}]({EXTERNAL_LINK_URL_PREFIX}{target})" + + def _adjust_filetype(m): + displayed, target, extension = m.groups() + if extension.lower() in extensions or target.startswith("http"): + return m.group(0) + + return f"[{displayed}]({EXTERNAL_LINK_URL_PREFIX}{target})" + + def _remove_section_links(m): + (file_link,) = m.groups() + return file_link + ")" + + def _adjust_image_link(m): + prefix, fpath, postfix = m.groups() + fpath_adj = _adjust_path(fpath) + return f"{prefix}{fpath_adj}{postfix}" + + rules = [ + # Find any links and adjust the path + (r"\[([^\[\]]*)\]\s*\((.*)\)", _adjust_links), + + # Find links that lead to an external folder and transform it + # into an external link. + ( + r"\[([^\[\]]*)\]\s*\((?:\.\./)*((?:" + "|".join(link_prefixes) + r")[^)]*)\)", + _adjust_external, + ), + + # Find links that lead to a section within another file and + # remove the section part of the link. + (r"(\[[^\[\]]*\]\s*\([^)]*\.md)#.*\)", _remove_section_links), + + # Find links that lead to a non-presentable filetype and transform + # it into an external link. + ( + r"\[([^\[\]]*)\]\s*\((?:\.\./)*((?:[^()]+?/)*[^.()]+?(\.[^)/]+))\)", + _adjust_filetype, + ), + + # Find links that lead to a folder and transform it into an external link. + ( + r"\[([^\[\]]*)\]\s*\((?:\.\./)*((?:[^()]+?/)+[^).#/]+)(\))", + _adjust_filetype, + ), + + # Find image links in img tags and adjust them + (r"(]*src=[\"'])([^ >]+)([\"'][^>]*>)", _adjust_image_link) + ] + + with open(fname, "r+", encoding=encoding) as f: + content = f.read() + modified = False + + for pattern, sub_func in rules: + content, changes_made = re.subn(pattern, sub_func, content) + modified = modified or changes_made + + if modified: + f.seek(0) + f.write(content) + f.truncate() + + +def sync_contents(app: Sphinx) -> None: + """Synhronize external contents. + + Args: + app: Sphinx application instance. + """ + + srcdir = Path(app.srcdir).resolve() + to_copy = [] + to_delete = set(f for f in srcdir.glob("**/*") if not f.is_dir()) + to_keep = set( + f + for k in app.config.external_content_keep + for f in srcdir.glob(k) + if not f.is_dir() + ) + + for content in app.config.external_content_contents: + prefix_src, glob = content + for src in prefix_src.glob(glob): + if src.is_dir(): + to_copy.extend( + [(f, prefix_src) for f in src.glob("**/*") if not f.is_dir()] + ) + else: + to_copy.append((src, prefix_src)) + + for entry in to_copy: + src, prefix_src = entry + dst = (srcdir / src.relative_to(prefix_src)).resolve() + + if dst in to_delete: + to_delete.remove(dst) + + if not dst.parent.exists(): + dst.parent.mkdir(parents=True) + + # just copy if it does not exist + if not dst.exists(): + shutil.copy(src, dst) + adjust_includes( + dst, + src.parent, + app.config.source_encoding, + app.config.external_content_link_prefixes, + app.config.external_content_link_extensions, + ) + # if origin file is modified only copy if different + elif src.stat().st_mtime > dst.stat().st_mtime: + with tempfile.TemporaryDirectory() as td: + # adjust origin includes before comparing + src_adjusted = Path(td) / src.name + shutil.copy(src, src_adjusted) + adjust_includes( + src_adjusted, + src.parent, + app.config.source_encoding, + app.config.external_content_link_prefixes, + app.config.external_content_link_extensions, + dstpath=dst.parent, + ) + + if not filecmp.cmp(src_adjusted, dst): + dst.unlink() + shutil.move(os.fspath(src_adjusted), os.fspath(dst)) + + # remove any previously copied file not present in the origin folder, + # excepting those marked to be kept. + for file in to_delete - to_keep: + file.unlink() + + +def setup(app: Sphinx) -> Dict[str, Any]: + app.add_config_value("external_content_contents", [], "env") + app.add_config_value("external_content_keep", [], "") + app.add_config_value("external_content_link_prefixes", [], "env") + app.add_config_value("external_content_link_extensions", [], "env") + + app.connect("builder-inited", sync_contents) + + return { + "version": __version__, + "parallel_read_safe": True, + "parallel_write_safe": True, + } diff --git a/docs/_static/images/favicon.ico b/docs/_static/images/favicon.ico new file mode 100644 index 00000000000000..16f3d88dcc98c7 Binary files /dev/null and b/docs/_static/images/favicon.ico differ diff --git a/docs/_static/images/logo.png b/docs/_static/images/logo.png new file mode 100644 index 00000000000000..88bcee2d157f8f Binary files /dev/null and b/docs/_static/images/logo.png differ diff --git a/docs/api/index.md b/docs/api/index.md new file mode 100644 index 00000000000000..d642d6505ca432 --- /dev/null +++ b/docs/api/index.md @@ -0,0 +1,7 @@ +# API + +```{toctree} +:glob: + +* +``` \ No newline at end of file diff --git a/docs/conf.py b/docs/conf.py new file mode 100644 index 00000000000000..c386f4a19de058 --- /dev/null +++ b/docs/conf.py @@ -0,0 +1,67 @@ +# Configuration file for the Sphinx documentation builder. + +from pathlib import Path +import sys + +# -- Paths ------------------------------------------------------------------- + +MATTER_BASE = Path(__file__).resolve().parents[1] + +sys.path.insert(0, str(MATTER_BASE / "docs" / "_extensions")) + +# -- Project information ----------------------------------------------------- + +project = "Matter" +copyright = "2022, Matter Contributors" +author = "Matter Contributors" +version = "1.0.0" + +# -- General configuration --------------------------------------------------- + +extensions = [ + "myst_parser", + "external_content", +] +exclude_patterns = [ + "_build", + "**/nxp/linux-imx/imx8m/README.md", + "examples/ota-requestor-app/efr32/README.md", + "**/android/App/app/libs*", + "examples/providers/README.md", +] + + +# -- Options for HTML output ------------------------------------------------- + +html_theme = "sphinx_book_theme" +html_logo = "_static/images/logo.png" +html_favicon = "_static/images/favicon.ico" +html_static_path = ["_static"] +html_theme_options = { + "logo_only": True, + "github_url": "https://github.com/project-chip/connectedhomeip", + "repository_url": "https://github.com/project-chip/connectedhomeip", + "use_edit_page_button": True, + "repository_branch": "master", + "path_to_docs": "docs", +} + +# -- Options for MyST -------------------------------------------------------- + +myst_heading_anchors = 6 +suppress_warnings = ["myst.header"] +myst_enable_extensions = ["html_image"] + + +# -- Options for external_content -------------------------------------------- + +external_content_contents = [ + (MATTER_BASE / "docs", "[!_R]*"), + (MATTER_BASE, "README.md"), + (MATTER_BASE, "examples/**/*.md"), + (MATTER_BASE, "examples/**/*.png"), + (MATTER_BASE, "examples/**/*.jpg"), + (MATTER_BASE, "examples/**/*.JPG"), +] +external_content_link_prefixes = ["src/", r"\.vscode/", "CONTRIBUTING"] +external_content_link_extensions = [".md", ".png", ".jpg", ".svg"] diff --git a/docs/discussion/index.md b/docs/discussion/index.md new file mode 100644 index 00000000000000..a954e84ae1d522 --- /dev/null +++ b/docs/discussion/index.md @@ -0,0 +1,7 @@ +# Discussion + +```{toctree} +:glob: + +* +``` \ No newline at end of file diff --git a/docs/examples/discussion/PID_allocation_for_example_apps.md b/docs/examples/discussion/PID_allocation_for_example_apps.md index 18e71a20698964..2ebb169e60f099 100644 --- a/docs/examples/discussion/PID_allocation_for_example_apps.md +++ b/docs/examples/discussion/PID_allocation_for_example_apps.md @@ -1,3 +1,7 @@ +--- +orphan: true +--- + # PID allocation for example apps Unless specifically overridden by the platform, example apps in this SDK use the diff --git a/docs/examples/index.md b/docs/examples/index.md new file mode 100644 index 00000000000000..83fee053520c33 --- /dev/null +++ b/docs/examples/index.md @@ -0,0 +1,217 @@ +# Examples + +The Matter SDK provides examples of Matter devices for different development platforms. + +## All clusters example + +```{toctree} +:glob: +:maxdepth: 1 + +all-clusters-app/**/README +``` + +## All clusters minimal example + +```{toctree} +:glob: +:maxdepth: 1 + +all-clusters-minimal-app/**/README +``` + +## Bridge example + +```{toctree} +:glob: +:maxdepth: 1 + +bridge-app/**/README +``` + +## CHEF example + +```{toctree} +:glob: +:maxdepth: 1 + +chef/README* +chef/**/README +``` + +## CHIP Tool example + +```{toctree} +:glob: +:maxdepth: 1 + +chip-tool/README +``` + +## CHIP Tool Darwin example + +```{toctree} +:glob: +:maxdepth: 1 + +darwin-framework-tool/README +``` + +## Lighting example + +```{toctree} +:glob: +:maxdepth: 1 + +lighting-app/**/README +lighting-app/qpg/APPLICATION +``` + +## Light switch example + +```{toctree} +:glob: +:maxdepth: 1 + +light-switch-app/**/README +``` + +## Lock example + +```{toctree} +:glob: +:maxdepth: 1 + +lock-app/**/README +lock-app/qpg/APPLICATION +``` + +## Log source example + +```{toctree} +:glob: +:maxdepth: 1 + +log-source-app/**/README +``` + +## Minimal MDNS example + +```{toctree} +:glob: +:maxdepth: 1 + +minimal-mdns/README +``` + +## OTA Provider example + +```{toctree} +:glob: +:maxdepth: 1 + +ota-provider-app/**/README +``` + +## OTA Requestor example + +```{toctree} +:glob: +:maxdepth: 1 + +ota-requestor-app/**/README +``` + +## Persistent storage example + +```{toctree} +:glob: +:maxdepth: 1 + +persistent-storage/**/README +persistent-storage/**/APPLICATION +``` + +## Pigweed example + +```{toctree} +:glob: +:maxdepth: 1 + +pigweed-app/**/README +``` + +## Pump example + +```{toctree} +:glob: +:maxdepth: 1 + +pump-app/**/README +pump-app/cc13x2x7_26x2x7/doc/programming* +``` + +## Pump controller example + +```{toctree} +:glob: +:maxdepth: 1 + +pump-controller-app/**/README +pump-controller-app/cc13x2x7_26x2x7/doc/programming* +``` + +## Shell example + +```{toctree} +:glob: +:maxdepth: 1 + +shell/README* +shell/**/README +``` + +## Temperature measurement example + +```{toctree} +:glob: +:maxdepth: 1 + +temperature-measurement-app/**/README +``` + +## Thermostat example + +```{toctree} +:glob: +:maxdepth: 1 + +thermostat/**/README +``` + +## TV example + +```{toctree} +:glob: +:maxdepth: 1 + +tv-app/**/README +``` + +## TV casting example + +```{toctree} +:glob: +:maxdepth: 1 + +tv-casting-app/**/README +``` + +## Window example + +```{toctree} +:glob: +:maxdepth: 1 + +window-app/**/README +``` diff --git a/docs/guides/android_building.md b/docs/guides/android_building.md index 6ca2d91dd54a1a..c845319518673d 100644 --- a/docs/guides/android_building.md +++ b/docs/guides/android_building.md @@ -15,14 +15,14 @@ There are following Apps on Android
-- [Source files](#source) -- [Requirements for building](#requirements) - - [ABIs and TARGET_CPU](#abi) - - [Gradle & JDK Version](#jdk) -- [Preparing for build](#preparing) -- [Building Android CHIPTool from scripts](#building-scripts) -- [Building Android CHIPTool from Android Studio](#building-studio) -- [Building Android CHIPTest from scripts](#building-chiptest-scripts) +- [Source files](#source-files) +- [Requirements for building](#requirements-for-building) + - [ABIs and TARGET_CPU](#abis-and-target_cpu) + - [Gradle & JDK Version](#gradle--jdk-version) +- [Preparing for build](#preparing-for-build) +- [Building Android CHIPTool from scripts](#building-android-chiptool-from-scripts) +- [Building Android CHIPTool from Android Studio](#building-android-chiptool-from-android-studio) +- [Building Android CHIPTest from scripts](#building-android-chiptest-from-scripts)
@@ -167,7 +167,7 @@ or ## Building Android CHIPTest from scripts Currently, the CHIPTest can only be built from scripts. The steps are similar to -[building CHIPTool from scripts](#building-scripts). +[building CHIPTool from scripts](#building-android-chiptool-from-scripts). ```shell ./scripts/build/build_examples.py --target android-arm64-chip-test build diff --git a/docs/guides/chip_tool_guide.md b/docs/guides/chip_tool_guide.md index 5dbeb5f3b1b678..f1d222768281ac 100644 --- a/docs/guides/chip_tool_guide.md +++ b/docs/guides/chip_tool_guide.md @@ -8,15 +8,13 @@ the setup payload or performing discovery actions.
-- [Source files](#source) -- [Building and running the CHIP Tool](#building) -- [Using the CHIP Tool for Matter device testing](#using) -- [Supported commands and options](#commands) +- [Source files](#source-files) +- [Building and running the CHIP Tool](#building-and-running-the-chip-tool) +- [Using the CHIP Tool for Matter device testing](#using-chip-tool-for-matter-device-testing) +- [Supported commands and options](#supported-commands-and-options)
- - ## Source files You can find source files of the CHIP Tool in the `examples/chip-tool` @@ -28,8 +26,6 @@ directory.
- - ## Building and running the CHIP Tool Before you can use the CHIP Tool, you must compile it from source on Linux @@ -69,12 +65,10 @@ _clusters_ in this context, but not all listed commands correspond to the _clusters_ in the Data Model (for example, pairing or discover commands). Each listed command can however become the root of the new more complex command by appending it with sub-commands. Examples of specific commands and their use -cases are described in the [Supported commands and options](#commands) section. +cases are described in the [Supported commands and options](#supported-commands-and-options) section.
- - ## Using CHIP Tool for Matter device testing This section describes how to use CHIP Tool to test the Matter device. The @@ -385,8 +379,6 @@ $ ./chip-tool basic
- - ## Supported commands and options This section contains a general list of various CHIP Tool commands and options, @@ -770,7 +762,7 @@ The `pairing` command supports different means regarding Matter device commissioning procedure. Thread and Wi-Fi commissioning use cases are described in the -[Using the CHIP Tool for Matter device testing](#using) section. +[Using the CHIP Tool for Matter device testing](#using-chip-tool-for-matter-device-testing) section. To list all `pairing` sub-commands, run the following command: @@ -780,7 +772,7 @@ $ ./chip-tool pairing ### Interacting with Data Model clusters -As mentioned in the [Using the CHIP Tool for Matter device testing](#using) +As mentioned in the [Using the CHIP Tool for Matter device testing](#using-chip-tool-for-matter-device-testing) section, executing the `chip-tool` command with a particular cluster name lists all operations supported for this cluster, as in the following command pattern: diff --git a/docs/guides/darwin.md b/docs/guides/darwin.md index b28a9925d53cd0..0d9e16b4253c16 100644 --- a/docs/guides/darwin.md +++ b/docs/guides/darwin.md @@ -200,7 +200,7 @@ requirements [examples](https://github.com/project-chip/connectedhomeip/tree/master/examples) to support the fixed device types [above](#ensuring-your-matter-accessory-works-with-iosipadostvos) -3. Read the [platform guides](.) on how set up the hardware +3. Read the [platform guides](README.md) on how set up the hardware ##### Guides diff --git a/docs/guides/esp32/README.md b/docs/guides/esp32/README.md index 0cdead51a8c289..ebdfaac513209d 100644 --- a/docs/guides/esp32/README.md +++ b/docs/guides/esp32/README.md @@ -1,6 +1,11 @@ ## Espressif (ESP32) Getting Started Guide ---- +```{toctree} +:glob: +:maxdepth: 1 + +* +``` Please follow the steps below to create and test a fully functional Matter example on ESP32 series of SoCs @@ -11,5 +16,3 @@ example on ESP32 series of SoCs - [Flash and NVS encryption for securing factory data](flash_nvs_encryption.md) - [RPC Console and Device Tracing](rpc_console.md) - [Matter OTA](ota.md) - ---- diff --git a/docs/guides/index.md b/docs/guides/index.md new file mode 100644 index 00000000000000..aa955c8e9ce7ec --- /dev/null +++ b/docs/guides/index.md @@ -0,0 +1,11 @@ +# Guides + +Read the following guides for general information about Matter SDK configuration and features. + +```{toctree} +:glob: +:maxdepth: 1 + +* +esp32/README +``` \ No newline at end of file diff --git a/docs/guides/mbedos_add_new_target.md b/docs/guides/mbedos_add_new_target.md index 07d34bb3705690..8ea7c35c7049d2 100644 --- a/docs/guides/mbedos_add_new_target.md +++ b/docs/guides/mbedos_add_new_target.md @@ -1,8 +1,8 @@ ![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png) -

Mbed-OS add new hardware target

+# Mbed-OS add new hardware target -# Overview +## Overview This document shows how to add the new Mbed OS hardware target to Matter project. @@ -23,7 +23,7 @@ remember about the following requirements: Additional target component requirements are different for each of example application. Check the **Device UI** paragraph in example description. -# Example Application +## Example Application The first step to add the new target to each of example application is to modify the `examples/example_name/mbed/mbed_app.json` file. It contains the common @@ -33,7 +33,7 @@ should add the necessary components and parameters for the target there. If the new target uses the external libraries, it will be required to link it in the CMakeLists.txt file. -# Building +## Building To add the new hardware target to the build system the `scripts/examples/mbed_example.sh` script should be modify. Extend @@ -56,7 +56,7 @@ Example: "default": "CY8CPROTO_062_4343W" } -# Flashing +## Flashing Mbed OS example application flashing process uses the [Open On-Chip Debugger](http://openocd.org/). The first step is to create the @@ -83,7 +83,7 @@ Example: "default": "CY8CPROTO_062_4343W" } -# Debugging +## Debugging Debugging process of Mbed OS applications is also based on VSCode launch task. Adding the new target to it required `.vscode/launch.json` modification. Extend @@ -99,7 +99,7 @@ Example: "default": "CY8CPROTO_062_4343W" } -# CI +## CI The Matter project continue integration process is based on Github Actions tool. It uses workflow configuration files to execute actions on CI server. diff --git a/docs/guides/mbedos_commissioning.md b/docs/guides/mbedos_commissioning.md index 1e80d2552a089e..e4b5b6e11a0b06 100644 --- a/docs/guides/mbedos_commissioning.md +++ b/docs/guides/mbedos_commissioning.md @@ -1,6 +1,6 @@ ![ARM Mbed-OS logo](https://raw.githubusercontent.com/ARMmbed/mbed-os/master/logo.png) -

Matter Arm Mbed OS provisioning guide

+# Matter Arm Mbed OS provisioning guide - [Overview](#overview) - [Prerequisites](#prerequisites) @@ -21,7 +21,7 @@
-# Overview +## Overview This document provides a step-by-step guide how to commission any Matter application. For demonstration purposes the Lighting app is used. @@ -37,7 +37,7 @@ The provisioning process is composed of the following stages: BLE is only used during first phase. Afterwards, only the IP connectivity between the smartphone and the accessory device is needed to send messages. -# Prerequisites +## Prerequisites To complete all the steps in the tutorial, you need: @@ -50,9 +50,9 @@ To complete all the steps in the tutorial, you need: - Any currently supported target device (for example, a Cypress PSoC6 CY8CPROTO-062-4343W board) -# CHIPTool for Android +## CHIPTool for Android -## Building and installing +### Building and installing To make provisioning possible and to control the Matter device from your Android based smartphone, you must first build and install the CHIPTool application. @@ -85,7 +85,7 @@ After building, install the application by completing the following steps: Android CHIPTool is now ready to be used for commissioning. -## Accessory Matter device setup +### Accessory Matter device setup To prepare the accessory Matter device for commissioning (called rendezvous), complete the following steps: @@ -113,7 +113,7 @@ to the UART console. - Open URL from the console to display the QR in a web browser. -## Device commissioning for Android +### Device commissioning for Android To commission Matter device onto the network created complete the following steps: @@ -137,7 +137,7 @@ steps: - After successful completion of the process, the application returns to the main screen. -## Sending ZCL commands +### Sending ZCL commands After the accessory device has been successfully commissioned to the network, it is possible to communicate with it using IP. Matter uses Zigbee Cluster Library @@ -156,9 +156,9 @@ If **Lighting LED** is available then brightness change can be observed. > For more details about Android CHIPTool please visit > [CHIPTool](../../src/android/CHIPTool/README.md) -# POSIX CLI CHIPTool +## POSIX CLI CHIPTool -## Building +### Building To make provisioning possible and to control the Matter device from Linux-based device, you can build and run the Matter Client example application on it. @@ -166,7 +166,7 @@ device, you can build and run the Matter Client example application on it. To build the POSIX CLI CHIPTool application check the guide [POSIX CLI guide](../../examples/chip-tool/README.md). -## Device commissioning for CLI +### Device commissioning for CLI In order to send commands to a device, it must be paired with the client and connected to the network. @@ -179,7 +179,7 @@ Example: $ chip-tool pairing ble-wifi node_id_to_assign network_ssid network_password 20202021 3840 -## Sending ZCL commands +### Sending ZCL commands If the commissioning process was successful, it is possible to send a ZCL command to the device which initiate a certain action. @@ -198,9 +198,9 @@ The client will send a single command packet and then exit. > For more details about POSIX CLI CHIPTool please visit > [POSIX CLI CHIPTool](../../examples/chip-tool/README.md) -# Python Device Controller +## Python Device Controller -## Building and installing +### Building and installing To make provisioning possible and to control the Matter device with Python application, you can build and run the Python CHIP controller. @@ -208,7 +208,7 @@ application, you can build and run the Python CHIP controller. To build and install the Python Device Controller application check the guide [Python Device Controller guide](python_chip_controller_building.md). -## Device commissioning for Python Device Controller +### Device commissioning for Python Device Controller In order to send commands to a device, it must be paired with the client and connected to the network. @@ -232,7 +232,7 @@ To run the auto commissioning process via BLE: chip-device-ctrl > connect -ble 3840 20202021 1234 -## Sending ZCL commands +### Sending ZCL commands If the commissioning process was successful, it is possible to send a ZCL command to the device which initiates a certain action. @@ -243,7 +243,7 @@ Example: chip-device-ctrl > zcl LevelControl MoveWithOnOff 12344321 1 0 moveMode=1 rate=2 -### ZCL commands details +#### ZCL commands details To get the list of supported clusters run: diff --git a/docs/guides/mbedos_platform_overview.md b/docs/guides/mbedos_platform_overview.md index 95a1a3ee67f0c7..b70d5ed89cc1ba 100644 --- a/docs/guides/mbedos_platform_overview.md +++ b/docs/guides/mbedos_platform_overview.md @@ -11,7 +11,7 @@ runs on the top of the Mbed-OS. ![matter_mbedos_overview_simplified](images/matter_mbedos_overview_simplified.png) -# ARM Mbed-OS +## ARM Mbed-OS Arm Mbed OS is an open source embedded operating system designed specifically for the "things" in the Internet of Things. It includes all the features you @@ -47,7 +47,7 @@ Finally, Mbed OS implements the retargeting layer and boot process integration of each supported toolchain, so application development feels similar to C or C++ development for any other operating system. -# Bluetooth and IP stacks +## Bluetooth and IP stacks In the Mbed-oS platform applications, the Bluetooth LE interface is used to perform pairing and Wi-Fi network provisioning operations between the Matter @@ -70,7 +70,7 @@ network layer, special glue socket layer has been introduced to take care of adapting the Mbed socket to BSD interface which is used inside the Matter endpoints implementation. -## Matter integration +### Matter integration The Bluetooth LE and Wi-Fi used stacks provided by the Mbed-OS have been integrated with the Matter stack using a special intermediate layer. @@ -80,30 +80,30 @@ interfaces defined in the Matter stack. The application is able to use Matter's platform agnostic interfaces and no additional platform-related actions are needed to perform communication through the Matter stack. -# Matter example applications +## Matter example applications Sample Matter applications are provided for the Mbed OS platform. They can be used to speed up development: -- [shell](../../examples/shell/mbed) -- [all-clusters-app](../../examples/all-clusters-app/mbed) +- [shell](../../examples/shell/mbed/README.md) +- [all-clusters-app](../../examples/all-clusters-app/mbed/README.md) - [lock-app](../../examples/lock-app/mbed/README.md) - [lighting-app](../../examples/lighting-app/mbed/README.md) - [pigweed-app](../../examples/pigweed-app/mbed/README.md) -## Example configuration +### Example configuration Each of the supporting examples contains the `config.in` file which allows you to configure the application in a proper way. You can define/disable/enable application settings. Then they are propagated through Mbed-OS and Matter stack build systems. -## Matter stack configuration +### Matter stack configuration In each of supported examples, the Matter stack can be configured by modifying `CHIPProjectConfig.h` file which is placed inside the project directory. -## Mbed-OS configuration +### Mbed-OS configuration Mbed-OS gives possibility to tweak its parameters by using the [Mbed-OS configuration system](https://os.mbed.com/docs/mbed-os/latest/program-setup/advanced-configuration.html). @@ -113,7 +113,7 @@ support of the new hardware target support into the application. Mbed-OS configuration system can be accessed by modifying the `mbed_app.json` file which exists in each sample project directory. -## Build system +### Build system The Mbed-OS platform makes use of the following build systems to generate ninja build scripts: @@ -126,7 +126,7 @@ Matter's stack and platform modules are built with GN and output a library file. The application, Mbed-OS and target specific libraries are built with CMake and the Matter library file is imported during the compilation process. -## Build profiles +### Build profiles Arm Mbed OS defines three collections of toolchain flags used during the build: diff --git a/docs/guides/nrfconnect_android_commissioning.md b/docs/guides/nrfconnect_android_commissioning.md index 93c0999b26212c..af617cbae77599 100644 --- a/docs/guides/nrfconnect_android_commissioning.md +++ b/docs/guides/nrfconnect_android_commissioning.md @@ -14,16 +14,14 @@ and applications as well. - [Overview](#overview) - [Requirements](#requirements) - [Setting up Thread Border Router](#setting-up-thread-border-router) -- [Building and programming nRF Connect Example Application](#building-example) -- [Building and installing Android CHIPTool](#building-chiptool) -- [Preparing accessory device](#preparing-accessory) -- [Commissioning accessory device](#commissioning-accessory) -- [Sending Matter commands](#sending-chip-commands) +- [Building and programming nRF Connect Example Application](#building-and-programming-nrf-connect-example-application) +- [Building and installing Android CHIPTool](#building-and-installing-android-chiptool) +- [Preparing accessory device](#preparing-accessory-device) +- [Commissioning accessory device](#commissioning-accessory-device) +- [Sending Matter commands](#sending-matter-commands)
- - ## Overview The commissioning process is composed of the following main stages: @@ -53,8 +51,6 @@ applications:
- - ## Requirements You need the following hardware and software for commissioning the nRF Connect @@ -77,8 +73,6 @@ accessory using Android CHIPTool:
- - ## Setting up Thread Border Router Follow the [OpenThread Border Router](openthread_border_router_pi.md) article to @@ -88,8 +82,6 @@ or the nRF52840 Dongle acting as the
- - ## Building and programming nRF Connect Example Application Build and program the example application onto your compatible device. @@ -99,8 +91,6 @@ learn how to build and program the example onto an nRF52840 DK.
- - ## Building and installing Android CHIPTool To build the CHIPTool application for your smartphone, read the @@ -135,8 +125,6 @@ CHIPTool is now ready to be used for commissioning.
- - ## Preparing accessory device To prepare the accessory device for commissioning, complete the following steps: @@ -160,8 +148,6 @@ To prepare the accessory device for commissioning, complete the following steps:
- - ## Commissioning accessory device To commission the accessory device onto the Thread network created in the @@ -185,8 +171,6 @@ device successfully joins the Thread network.
- - ## Sending Matter commands Once the device is commissioned, the main application screen appears. diff --git a/docs/guides/nrfconnect_examples_configuration.md b/docs/guides/nrfconnect_examples_configuration.md index 119852b3929a89..de79df58430526 100644 --- a/docs/guides/nrfconnect_examples_configuration.md +++ b/docs/guides/nrfconnect_examples_configuration.md @@ -103,8 +103,6 @@ target name of the kit, for example _nrf52840dk_nrf52840_:
- - ## Configuration structure overview Zephyr RTOS and related software components, like drivers and libraries, provide diff --git a/docs/guides/nrfconnect_factory_data_configuration.md b/docs/guides/nrfconnect_factory_data_configuration.md index 3dc71cd58ddd92..9f57c079131cb4 100644 --- a/docs/guides/nrfconnect_factory_data_configuration.md +++ b/docs/guides/nrfconnect_factory_data_configuration.md @@ -28,15 +28,13 @@ data secure by applying hardware write protection. > is the hardware flash protection driver, and we used it to ensure write > protection of the factory data partition in internal flash memory. -

- Nordic Semiconductor logo - nRF52840 DK -

+Nordic Semiconductor logo +nRF52840 DK
- [Overview](#overview) - - [Factory data components](#factory-data-components) + - [Factory data components](#factory-data-component-table) - [Factory data format](#factory-data-format) - [Enabling factory data support](#enabling-factory-data-support) - [Generating factory data](#generating-factory-data) @@ -46,7 +44,7 @@ data secure by applying hardware write protection. - [Option 2: Using a website validator](#option-2-using-a-website-validator) - [Option 3: Using the nRF Connect Python script](#option-3-using-the-nrf-connect-python-script) - [Preparing factory data partition on a device](#preparing-factory-data-partition-on-a-device) - - [Creating the factory data partition with the second script](#creating-the-factory-data-partition-with-the-second-script) + - [Creating the factory data partition with the second script](#creating-a-factory-data-partition-with-the-second-script) - [Building an example with factory data](#building-an-example-with-factory-data) - [Providing factory data parameters as a build argument list](#providing-factory-data-parameters-as-a-build-argument-list) - [Setting factory data parameters using interactive Kconfig interfaces](#setting-factory-data-parameters-using-interactive-kconfig-interfaces) @@ -55,8 +53,6 @@ data secure by applying hardware write protection.
- - ## Overview You can implement the factory data set described in the @@ -154,7 +150,6 @@ In the factory data set, the following formats are used: [X.509](https://www.itu.int/rec/T-REC-X.509-201910-I/en) format.
- ## Enabling factory data support @@ -185,7 +180,7 @@ partition into the device's flash memory. You can use the second script without invoking the first one by providing a JSON file written in another way. To make sure that the JSON file is correct and the device is able to read out parameters, verify the file using the -[JSON schema](#verifying-using-a-json-schema). +[JSON schema](#verifying-using-the-json-schema-tool). ### Creating factory data JSON file with the first script @@ -331,7 +326,7 @@ JSON file is verified using the prepared JSON Schema. If the script finishes successfully, go to the location you provided with the `-o` argument. Use the JSON file you find there when -[generating the factory data partition](#generating_factory_data_partition). +[generating the factory data partition](#generating-factory-data). > Note: Generating the SPAKE2+ verifier is optional and requires providing a > path to the `spake2p` executable. To get it, complete the following steps: @@ -536,7 +531,6 @@ reason, it can be programmed directly to the device using a programmer (for example, `nrfjprog`).
- ## Building an example with factory data @@ -616,7 +610,6 @@ snippet: > [Kconfig docummentation](https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/zephyr/build/kconfig/menuconfig.html).
- ## Programming factory data @@ -668,7 +661,7 @@ $ west build -b nrf52840dk_nrf52840 -- \ > Note: To generate new certificates using the nRF Connect platform build > system, you need the `chip-cert` executable in your system variable PATH. To > learn how to get `chip-cert`, go to the note at the end of -> [creating the factory data partition with the second script](#creating-the-factory-data-partition-with-the-second-script) +> [creating the factory data partition with the second script](#creating-a-factory-data-partition-with-the-second-script) > section, and then add the newly built executable to the system variable PATH. > The Cmake build system will find this executable automatically. @@ -680,13 +673,12 @@ $ west flash ```
- ## Using own factory data implementation The [factory data generation process](#generating-factory-data) described above is only an example valid for the nRF Connect platform. You can well create a HEX -file containing all [factory data components](#factory-data-components) in any +file containing all [factory data components](#factory-data-component-table) in any format and then implement a parser to read out all parameters and pass them to a provider. Each manufacturer can implement a factory data set on its own by implementing a parser and a factory data accessor inside the Matter stack. Use diff --git a/docs/guides/nxp_imx8m_linux_examples.md b/docs/guides/nxp_imx8m_linux_examples.md index c1eabd3819910b..6b1ad2b8f6c4bd 100644 --- a/docs/guides/nxp_imx8m_linux_examples.md +++ b/docs/guides/nxp_imx8m_linux_examples.md @@ -4,11 +4,11 @@ This document describes how to build below Linux examples with the NXP embedded Linux Yocto SDK and then run the output executable files on the **NXP i.MX 8M** **Mini EVK** development board. -- [CHIP Linux All-clusters Example](../../examples/all-clusters-app/linux) -- [CHIP Linux Lighting Example](../../examples/lighting-app/linux) -- [CHIP Linux Thermostat Example](../../examples/thermostat/linux) -- [CHIP Linux CHIP-tool Example](../../examples/chip-tool) -- [CHIP Linux OTA-provider Example](../../examples/ota-provider-app/linux) +- [CHIP Linux All-clusters Example](../../examples/all-clusters-app/linux/README.md) +- [CHIP Linux Lighting Example](../../examples/lighting-app/linux/README.md) +- [CHIP Linux Thermostat Example](https://github.com/project-chip/connectedhomeip/tree/master/examples/thermostat/linux) +- [CHIP Linux CHIP-tool Example](../../examples/chip-tool/README.md) +- [CHIP Linux OTA-provider Example](../../examples/ota-provider-app/linux/README.md) This document has been tested on: @@ -30,8 +30,6 @@ Linux OS development. For more information about this project, see the
- - ## Building Before building the CHIP Linux Examples, the Yocto source code released by NXP @@ -73,7 +71,7 @@ to be generated. More information about the downloaded Yocto release can be found in the corresponding i.MX Yocto Project User’s Guide which can be found at - [NXP official website](www.nxp.com/imxlinux). + [NXP official website](https://www.nxp.com/imxlinux). Change the current directory to the top directory of the Yocto source code and execute the commands below to generate the Yocto SDK: @@ -181,8 +179,6 @@ to be generated. running the Yocto image previously generated as described in the sections above. - - ## Commandline arguments The generated executable files supports to work with below commandline argument: @@ -205,8 +201,6 @@ The generated executable files supports to work with below commandline argument: The BLE device on **i.MX 8M Mini EVK** is a module based on the NXP 88W8987 Wi-Fi/Bluetooth SoC. - - ## Running the Examples on i.MX 8M Mini EVK The steps and commands to run any of the examples are quite similar. diff --git a/docs/guides/nxp_k32w_android_commissioning.md b/docs/guides/nxp_k32w_android_commissioning.md index 751b6043a65d81..84b5f7addd2f59 100644 --- a/docs/guides/nxp_k32w_android_commissioning.md +++ b/docs/guides/nxp_k32w_android_commissioning.md @@ -3,26 +3,24 @@ This article describes how to use [CHIPTool](../../src/android/CHIPTool/README.md) for Android smartphones to commission an NXP K32W061 DK6 running -[NXP K32W Lock/Light Example Application](../../examples/lock-light-app/k32w/README.md) +[NXP K32W Lock/Light Example Application](#building-and-programming-nxp-k32w-locklight-example-application) onto a CHIP-enabled Thread network.
- [Overview](#overview) - [Requirements](#requirements) -- [Building and programming OpenThread RCP firmware](#building-rcp-firmware) -- [Configuring PC as Thread Border Router](#configuring-pc) -- [Building and programming NXP K32W Lock/Light Example Application](#building-example) -- [Building and installing Android CHIPTool](#building-chiptool) -- [Forming a Thread network on the Border Router](#form-thread) -- [Preparing accessory device](#preparing-accessory) -- [Commissioning accessory device](#commissioning-accessory) +- [Building and programming OpenThread RCP firmware](#building-and-programming-openthread-rcp-firmware) +- [Configuring PC as Thread Border Router](#configuring-pc-as-a-thread-border-router) +- [Building and programming NXP K32W Lock/Light Example Application](#building-and-programming-nxp-k32w-locklight-example-application) +- [Building and installing Android CHIPTool](#building-and-installing-android-chiptool) +- [Forming a Thread network on the Border Router](#forming-a-thread-network-on-the-border-router) +- [Preparing accessory device](#preparing-accessory-device) +- [Commissioning accessory device](#commissioning-accessory-device) - [Sending CHIP commands](#sending-chip-commands)
- - ## Overview The commissioning process is composed of the following main stages: @@ -49,12 +47,10 @@ The following diagram shows the connectivity between network components required to allow communication between devices running the CHIPTool and Lock/Light applications: -![nxp_hw_connectivity](../../examples/platform/k32w/doc/images/nxp_hw_connectivity.JPG) +![nxp_hw_connectivity](../../examples/platform/nxp/k32w/k32w0/doc/images/nxp_hw_connectivity.JPG)
- - ## Requirements You need the following hardware and software to build a Thread Border Router: @@ -77,8 +73,6 @@ using other popular operating systems.
- - ## Building and programming OpenThread RCP firmware OpenThread RCP firmware is required to allow the PC to communicate with Thread @@ -123,8 +117,6 @@ the RCP firmware onto an K32W061 DK6:
- - ## Configuring PC as a Thread Border Router To make your PC work as a Thread Border Router, complete the following tasks: @@ -353,8 +345,6 @@ To make your PC work as a Thread Border Router, complete the following tasks:
- - ## Building and programming NXP K32W Lock/Light Example Application See @@ -367,8 +357,6 @@ to learn how to build and program the light example onto an K32W061 DK6.
- - ## Building and installing Android CHIPTool To build the CHIPTool application for your smartphone, read @@ -403,8 +391,6 @@ CHIPTool is now ready to be used for commissioning.
- - ## Forming a Thread network on the Border Router 1. On the mobile phone connect to the _OT-BR_ Wi-Fi network. @@ -414,7 +400,7 @@ CHIPTool is now ready to be used for commissioning. 3. Navigate to the _Form_ tab then push the _Form_ button using the default parameters: - ![nxp_form_nwk](../../examples/platform/k32w/doc/images/form_web.JPG) + ![nxp_form_nwk](../../examples/platform/nxp/k32w/k32w0/doc/images/form_web.JPG) 4. The message _Form operation is successful_ should be display after a few seconds. @@ -448,7 +434,7 @@ To prepare the accessory device for commissioning, complete the following steps: 1. Make sure that JP4 and JP7 jumpers are in leftmost position and a mini-USB cable is connected between the LPC connector and PC - ![nxp_connectors](../../examples/platform/k32w/doc/images/k32w-dk6-connectors.jpg) + ![nxp_connectors](../../examples/platform/nxp/k32w/k32w0/doc/images/k32w-dk6-connectors.jpg) 2. Use a terminal emulator (e.g.: Putty) to connect to the UART console of the accessory device. Use a baudrate of 115200. @@ -468,12 +454,10 @@ To prepare the accessory device for commissioning, complete the following steps:
- - ## Commissioning accessory device To commission the accessory device onto the Thread network created in the -[Forming Thread network](#Forming-a-Thread-network) section, complete the +[Forming Thread network](#forming-a-thread-network-on-the-border-router) section, complete the following steps: 1. Enable _Bluetooth_ and _Location_ services on your smartphone; @@ -486,26 +470,24 @@ following steps: progress with scanning, connection, and pairing. At the end of this process, the Thread network settings screen appears. - ![chiptool_main_screen](../../examples/platform/k32w/doc/images/chiptool_main_screen.png) + ![chiptool_main_screen](../../examples/platform/nxp/k32w/k32w0/doc/images/chiptool_main_screen.png) 6. In the Thread network settings screen, use the default settings and tap the _SAVE NETWORK_ button to send a Thread provisioning message to the accessory device. You will see the "Network provisioning completed" message when the accessory device successfully joins the Thread network. - ![chiptool_credentials](../../examples/platform/k32w/doc/images/thread_credentials.png) + ![chiptool_credentials](../../examples/platform/nxp/k32w/k32w0/doc/images/thread_credentials.png)
- - ## Sending CHIP commands 1. Once the device is commissioned, the below screen appears. This means that the provisioning is completed successfully and you are connected to the device. - ![on_off_cluster.png](../../examples/platform/k32w/doc/images/on_off_cluster.png) + ![on_off_cluster.png](../../examples/platform/nxp/k32w/k32w0/doc/images/on_off_cluster.png) 2. Verify that the text box on the screen is not empty and contains the IPv6 address of the accessory device. diff --git a/docs/guides/python_chip_controller_advanced_usage.md b/docs/guides/python_chip_controller_advanced_usage.md index ca17d8ca297829..c3d3f55ddc5095 100644 --- a/docs/guides/python_chip_controller_advanced_usage.md +++ b/docs/guides/python_chip_controller_advanced_usage.md @@ -7,13 +7,11 @@ tool or Matter accessories on Linux.
-- [Bluetooth LE virtualization on Linux](#virtualization) -- [Debugging with gdb](#gdb) +- [Bluetooth LE virtualization on Linux](#bluetooth-le-virtualization-on-linux) +- [Debugging with gdb](#debugging-with-gdb)
- - ## Bluetooth LE virtualization on Linux Commissioning over Bluetooth LE can be tested even if the controller and the @@ -76,8 +74,6 @@ interfaces working as Bluetooth LE central and peripheral, respectively.
- - ## Debugging with gdb You can run the chip-device-ctrl under GDB for debugging, however, since the diff --git a/docs/guides/python_chip_controller_building.md b/docs/guides/python_chip_controller_building.md index 693dacf3732055..a466eb4885b8ee 100644 --- a/docs/guides/python_chip_controller_building.md +++ b/docs/guides/python_chip_controller_building.md @@ -9,16 +9,14 @@ into the network and to communicate with it using the Zigbee Cluster Library
-- [Source files](#source) -- [Building Android CHIPTool](#building) -- [Running the tool](#running) -- [Using Python CHIP Controller for Matter accessory testing](#using) -- [List of commands](#commands) +- [Source files](#source-files) +- [Building Android CHIPTool](#building-and-installing) +- [Running the tool](#running-the-tool) +- [Using Python CHIP Controller for Matter accessory testing](#using-python-chip-controller-for-matter-accessory-testing) +- [List of commands](#list-of-commands)
- - ## Source files You can find source files of the Python CHIP Controller tool in the @@ -29,8 +27,6 @@ The tool uses the generic CHIP Device Controller library, available in the
- - ## Building and installing Before you can use the Python controller, you must compile it from the source on @@ -88,8 +84,6 @@ To build and run the Python CHIP controller:
- - ## Running the tool 1. Activate the Python virtual environment: @@ -113,8 +107,6 @@ To build and run the Python CHIP controller:
- - ## Using Python CHIP Controller for Matter accessory testing This section describes how to use Python CHIP controller to test the Matter @@ -302,8 +294,6 @@ chip-device-ctrl > zclread Basic SoftwareVersion 1234 1 0
- - ## List of commands ### `ble-adapter-print` diff --git a/docs/guides/simulated_device_linux.md b/docs/guides/simulated_device_linux.md index 5bbd5f2b6452cf..2594657b299cf7 100644 --- a/docs/guides/simulated_device_linux.md +++ b/docs/guides/simulated_device_linux.md @@ -2,7 +2,7 @@ This document contains instructions on how to build, run, and interact with a simulated device. All virtual accessories live in -[examples/placeholder/linux/apps](../../examples/placeholder/linux/apps). +[examples/placeholder/linux/apps](https://github.com/project-chip/connectedhomeip/tree/master/examples/placeholder/linux/apps). Each accessory needs to be hosted into a subfolder. It will be the name of the application. For example `app1` will create a binary named `chip-app1`. @@ -86,7 +86,7 @@ Now that the building the app and starting it is complete, you will be able to interact with it using chip-tool 1. Follow the instruction to build chip-tool in the - [chip-tool readme](../../examples/chip-tool). + [chip-tool readme](../../examples/chip-tool/README.md). 2. Run this command to initiate the pairing. ``` @@ -105,7 +105,7 @@ interact with it using chip-tool ./out/debug/standalone/chip-tool onoff write on-time 1 0x654321 1 ``` - See [chip-tool readme](../../examples/chip-tool) for additional commands. + See [chip-tool readme](../../examples/chip-tool/README.md) for additional commands. ## Adding simulated Tests via YAML diff --git a/docs/guides/ti_platform_overview.md b/docs/guides/ti_platform_overview.md index 50d96f361963ee..cc0a05280cbc22 100644 --- a/docs/guides/ti_platform_overview.md +++ b/docs/guides/ti_platform_overview.md @@ -91,7 +91,7 @@ handled by the platform implementation files.
-# Matter example applications +## Matter example applications Sample Matter applications are provided for the TI platform. These can be used as reference for your own application. @@ -102,7 +102,7 @@ as reference for your own application.
-## Build system +### Build system The TI platform uses GN to generate ninja build scripts. Build files have already been written to build and link the TI specific code within the @@ -110,7 +110,7 @@ SimpleLink SDK.
-## TI Support +### TI Support For technical support, please consider creating a post on TI's [E2E forum][e2e]. Additionally, we welcome any feedback. diff --git a/docs/images/logo.svg b/docs/images/logo.svg deleted file mode 100644 index 7dcae9ffa48fa8..00000000000000 --- a/docs/images/logo.svg +++ /dev/null @@ -1,37 +0,0 @@ - - - - Zigbee-Alliance-logo-black - Created with Sketch. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 00000000000000..16ad09c94e027f --- /dev/null +++ b/docs/index.md @@ -0,0 +1,29 @@ +# Welcome to Matter's documentation! + +```{toctree} +:maxdepth: 2 +:caption: Contents +:hidden: + +QUICK_START +PROJECT_FLOW +VSCODE_DEVELOPMENT +api/index +discussion/index +guides/index +style/index +examples/index +BUG_REPORT +``` + +```{include} README.md +:start-after: What is Matter? +:end-before: Building and Developing in Matter +``` + +# Matter build status + +```{include} README.md +:start-line: 2 +:end-before: What is Matter? +``` \ No newline at end of file diff --git a/docs/make.bat b/docs/make.bat new file mode 100644 index 00000000000000..18f214815d661a --- /dev/null +++ b/docs/make.bat @@ -0,0 +1,37 @@ +@ECHO OFF + +pushd %~dp0 + +REM Command file for Sphinx documentation + +if "%SPHINXBUILD%" == "" ( + set SPHINXBUILD=sphinx-build +) +set SPHINXOPTS=-W -c . -d _build\doctrees +set SOURCEDIR=_build\src +set BUILDDIR=_build + +if "%1" == "" goto help + +%SPHINXBUILD% >NUL 2>NUL +if errorlevel 9009 ( + echo. + echo.The 'sphinx-build' command was not found. Make sure you have Sphinx + echo.installed, then set the SPHINXBUILD environment variable to point + echo.to the full path of the 'sphinx-build' executable. Alternatively you + echo.may add the Sphinx directory to PATH. + echo. + echo.If you don't have Sphinx installed, grab it from + echo.http://sphinx-doc.org/ + exit /b 1 +) + +mkdir %SOURCEDIR% +%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O% +goto end + +:help +%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O% + +:end +popd diff --git a/docs/matter.doxyfile.in b/docs/matter.doxyfile.in new file mode 100644 index 00000000000000..7ba503e702e8d3 --- /dev/null +++ b/docs/matter.doxyfile.in @@ -0,0 +1,2691 @@ +# Doxyfile 1.9.2 + +# This file describes the settings to be used by the documentation system +# doxygen (www.doxygen.org) for a project. +# +# All text after a double hash (##) is considered a comment and is placed in +# front of the TAG it is preceding. +# +# All text after a single hash (#) is considered a comment and will be ignored. +# The format is: +# TAG = value [value, ...] +# For lists, items can also be appended using: +# TAG += value [value, ...] +# Values that contain spaces should be placed between quotes (\" \"). + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- + +# 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 libiconv (or the +# iconv built into libc) for the transcoding. See +# https://www.gnu.org/software/libiconv/ for the list of possible encodings. +# The default value is: UTF-8. + +DOXYFILE_ENCODING = UTF-8 + +# The 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. +# The default value is: My Project. + +PROJECT_NAME = Matter + +# The 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. + +PROJECT_NUMBER = @MATTER_VERSION@ + +# Using the 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. + +PROJECT_BRIEF = + +# With the 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. + +PROJECT_LOGO = @MATTER_BASE@/docs/_doxygen/logo.png + +# The 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. + +OUTPUT_DIRECTORY = + +# If the CREATE_SUBDIRS tag is set to 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. +# The default value is: NO. + +CREATE_SUBDIRS = NO + +# If the ALLOW_UNICODE_NAMES tag is set to YES, doxygen will allow non-ASCII +# characters to appear in the names of generated files. If set to NO, non-ASCII +# characters will be escaped, for example _xE3_x81_x84 will be used for Unicode +# U+3044. +# The default value is: NO. + +ALLOW_UNICODE_NAMES = NO + +# The 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. +# Possible values are: Afrikaans, Arabic, Armenian, Brazilian, Catalan, Chinese, +# Chinese-Traditional, Croatian, Czech, Danish, Dutch, English (United States), +# Esperanto, Farsi (Persian), Finnish, French, German, Greek, Hungarian, +# Indonesian, Italian, Japanese, Japanese-en (Japanese with English messages), +# Korean, Korean-en (Korean with English messages), Latvian, Lithuanian, +# Macedonian, Norwegian, Persian (Farsi), Polish, Portuguese, Romanian, Russian, +# Serbian, Serbian-Cyrillic, Slovak, Slovene, Spanish, Swedish, Turkish, +# Ukrainian and Vietnamese. +# The default value is: English. + +OUTPUT_LANGUAGE = English + +# If the BRIEF_MEMBER_DESC tag is set to YES, doxygen will include brief member +# descriptions after the members that are listed in the file and class +# documentation (similar to Javadoc). Set to NO to disable this. +# The default value is: YES. + +BRIEF_MEMBER_DESC = YES + +# If the REPEAT_BRIEF tag is set to YES, doxygen will prepend the brief +# description of a member or function before the detailed description +# +# Note: If both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# brief descriptions will be completely suppressed. +# The default value is: YES. + +REPEAT_BRIEF = YES + +# 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):The $name class, The $name widget, The $name file, is, provides, +# specifies, contains, represents, a, an and the. + +ABBREVIATE_BRIEF = "The $name class" \ + "The $name widget" \ + "The $name file" \ + is \ + provides \ + specifies \ + contains \ + represents \ + a \ + an \ + the + +# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then +# doxygen will generate a detailed section even if there is only a brief +# description. +# The default value is: NO. + +ALWAYS_DETAILED_SEC = NO + +# If the INLINE_INHERITED_MEMB tag is set to 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. +# The default value is: NO. + +INLINE_INHERITED_MEMB = NO + +# If the FULL_PATH_NAMES tag is set to YES, doxygen will prepend the full path +# before files name in the file list and in the header files. If set to NO the +# shortest path that makes the file name unique will be used +# The default value is: YES. + +FULL_PATH_NAMES = YES + +# The STRIP_FROM_PATH tag can be used to strip a user-defined part of the path. +# Stripping is only done if one of the specified strings matches the left-hand +# part of the path. The tag can be used to show relative paths in the file list. +# If left blank the directory from which doxygen is run is used as the path to +# strip. +# +# Note that you can specify absolute paths here, but also relative paths, which +# will be relative from the directory where doxygen is started. +# This tag requires that the tag FULL_PATH_NAMES is set to YES. + +STRIP_FROM_PATH = src + +# The 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. + +STRIP_FROM_INC_PATH = src + +# If the SHORT_NAMES tag is set to 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. +# The default value is: NO. + +SHORT_NAMES = NO + +# If the JAVADOC_AUTOBRIEF tag is set to YES then doxygen will interpret the +# first line (until the first dot) of a Javadoc-style comment as the brief +# description. If set to NO, the Javadoc-style will behave just like regular Qt- +# style comments (thus requiring an explicit @brief command for a brief +# description.) +# The default value is: NO. + +JAVADOC_AUTOBRIEF = YES + +# If the JAVADOC_BANNER tag is set to YES then doxygen will interpret a line +# such as +# /*************** +# as being the beginning of a Javadoc-style comment "banner". If set to NO, the +# Javadoc-style will behave just like regular comments and it will not be +# interpreted by doxygen. +# The default value is: NO. + +JAVADOC_BANNER = NO + +# If the QT_AUTOBRIEF tag is set to YES then doxygen will interpret the first +# line (until the first dot) of a Qt-style comment as the brief description. If +# set to NO, the Qt-style will behave just like regular Qt-style comments (thus +# requiring an explicit \brief command for a brief description.) +# The default value is: NO. + +QT_AUTOBRIEF = NO + +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make doxygen treat a +# multi-line C++ special comment block (i.e. a block of //! or /// 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 YES if you prefer the old behavior instead. +# +# Note that setting this tag to YES also means that rational rose comments are +# not recognized any more. +# The default value is: NO. + +MULTILINE_CPP_IS_BRIEF = NO + +# By default Python docstrings are displayed as preformatted text and doxygen's +# special commands cannot be used. By setting PYTHON_DOCSTRING to NO the +# doxygen's special commands can be used and the contents of the docstring +# documentation blocks is shown as doxygen documentation. +# The default value is: YES. + +PYTHON_DOCSTRING = YES + +# If the INHERIT_DOCS tag is set to YES then an undocumented member inherits the +# documentation from any documented member that it re-implements. +# The default value is: YES. + +INHERIT_DOCS = YES + +# If the SEPARATE_MEMBER_PAGES tag is set to YES then doxygen will produce a new +# page for each member. If set to NO, the documentation of a member will be part +# of the file/class/namespace that contains it. +# The default value is: NO. + +SEPARATE_MEMBER_PAGES = NO + +# The 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. +# Minimum value: 1, maximum value: 16, default value: 4. + +TAB_SIZE = 4 + +# This tag can be used to specify a number of aliases that act as commands in +# the documentation. An alias has the form: +# name=value +# For example adding +# "sideeffect=@par Side Effects:^^" +# will allow you to put the command \sideeffect (or @sideeffect) in the +# documentation, which will result in a user-defined paragraph with heading +# "Side Effects:". Note that you cannot put \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. 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 \{ and \} for these it is advised to use the version @{ and +# @} or use a double escape (\\{ and \\}) + +ALIASES = + +# Set the OPTIMIZE_OUTPUT_FOR_C tag to 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. +# The default value is: NO. + +OPTIMIZE_OUTPUT_FOR_C = NO + +# Set the OPTIMIZE_OUTPUT_JAVA tag to 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. +# The default value is: NO. + +OPTIMIZE_OUTPUT_JAVA = NO + +# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran +# sources. Doxygen will then generate output that is tailored for Fortran. +# The default value is: NO. + +OPTIMIZE_FOR_FORTRAN = NO + +# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL +# sources. Doxygen will then generate output that is tailored for VHDL. +# The default value is: NO. + +OPTIMIZE_OUTPUT_VHDL = NO + +# Set the OPTIMIZE_OUTPUT_SLICE tag to 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. +# The default value is: NO. + +OPTIMIZE_OUTPUT_SLICE = NO + +# Doxygen selects the parser to use depending on the extension of the files it +# parses. With this tag you can assign which parser to use for a given +# extension. Doxygen has a built-in mapping, but you can override or extend it +# using this tag. The format is ext=language, where ext is a file extension, and +# language is one of the parsers supported by doxygen: IDL, Java, JavaScript, +# Csharp (C#), C, C++, Lex, 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 .inc files +# as Fortran files (default is PHP), and .f files as C (default is Fortran), +# use: inc=Fortran f=C. +# +# Note: For files without extension you can use no_extension as a placeholder. +# +# Note that for custom extensions you also need to set FILE_PATTERNS otherwise +# the files are not read by doxygen. When specifying no_extension you should add +# * to the FILE_PATTERNS. +# +# Note see also the list of default file extension mappings. + +EXTENSION_MAPPING = h=C++ + +# If the 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. +# The default value is: YES. + +MARKDOWN_SUPPORT = YES + +# When the 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. +# Minimum value: 0, maximum value: 99, default value: 5. +# This tag requires that the tag MARKDOWN_SUPPORT is set to YES. + +TOC_INCLUDE_HEADINGS = 5 + +# 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 % sign in front of the word or +# globally by setting AUTOLINK_SUPPORT to NO. +# The default value is: YES. + +AUTOLINK_SUPPORT = YES + +# 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 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. +# The default value is: NO. + +BUILTIN_STL_SUPPORT = YES + +# If you use Microsoft's C++/CLI language, you should set this option to YES to +# enable parsing support. +# The default value is: NO. + +CPP_CLI_SUPPORT = NO + +# Set the SIP_SUPPORT tag to YES if your project consists of sip (see: +# https://www.riverbankcomputing.com/software/sip/intro) 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. +# The default value is: NO. + +SIP_SUPPORT = NO + +# For Microsoft's IDL there are propget and propput attributes to indicate +# getter and setter methods for a property. Setting this option to 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 NO. +# The default value is: YES. + +IDL_PROPERTY_SUPPORT = YES + +# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC +# tag is set to 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. +# The default value is: NO. + +DISTRIBUTE_GROUP_DOC = NO + +# 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 \ingroup. +# The default value is: NO. + +GROUP_NESTED_COMPOUNDS = NO + +# Set the SUBGROUPING tag to 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 NO to prevent +# subgrouping. Alternatively, this can be done per class using the +# \nosubgrouping command. +# The default value is: YES. + +SUBGROUPING = YES + +# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and unions +# are shown inside the group in which they are included (e.g. using \ingroup) +# instead of on a separate page (for HTML and Man pages) or section (for LaTeX +# and RTF). +# +# Note that this feature does not work in combination with +# SEPARATE_MEMBER_PAGES. +# The default value is: NO. + +INLINE_GROUPED_CLASSES = NO + +# When the INLINE_SIMPLE_STRUCTS tag is set to 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 NO, structs, classes, and unions are shown on a separate page (for HTML and +# Man pages) or section (for LaTeX and RTF). +# The default value is: NO. + +INLINE_SIMPLE_STRUCTS = NO + +# When TYPEDEF_HIDES_STRUCT tag is enabled, a typedef of a struct, union, or +# enum is documented as struct, union, or enum with the name of the typedef. So +# typedef struct TypeS {} TypeT, will appear in the documentation as a struct +# with name TypeT. When disabled the typedef will appear as a member of a file, +# namespace, or class. And the struct will be named 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. +# The default value is: NO. + +TYPEDEF_HIDES_STRUCT = NO + +# The size of the symbol lookup cache can be set using 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: 2^(16+LOOKUP_CACHE_SIZE). The valid range +# is 0..9, the default is 0, corresponding to a cache size of 2^16=65536 +# 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. +# Minimum value: 0, maximum value: 9, default value: 0. + +LOOKUP_CACHE_SIZE = 0 + +# The NUM_PROC_THREADS specifies the number threads doxygen is allowed to use +# during processing. When set to 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 effectively disables parallel processing. Please report any issues you +# encounter. Generating dot graphs in parallel is controlled by the +# DOT_NUM_THREADS setting. +# Minimum value: 0, maximum value: 32, default value: 1. + +NUM_PROC_THREADS = 1 + +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- + +# If the EXTRACT_ALL tag is set to 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 +# EXTRACT_PRIVATE respectively EXTRACT_STATIC tags are set to YES. +# Note: This will also disable the warnings about undocumented members that are +# normally produced when WARNINGS is set to YES. +# The default value is: NO. + +EXTRACT_ALL = YES + +# If the EXTRACT_PRIVATE tag is set to YES, all private members of a class will +# be included in the documentation. +# The default value is: NO. + +EXTRACT_PRIVATE = NO + +# If the EXTRACT_PRIV_VIRTUAL tag is set to YES, documented private virtual +# methods of a class will be included in the documentation. +# The default value is: NO. + +EXTRACT_PRIV_VIRTUAL = NO + +# If the EXTRACT_PACKAGE tag is set to YES, all members with package or internal +# scope will be included in the documentation. +# The default value is: NO. + +EXTRACT_PACKAGE = NO + +# If the EXTRACT_STATIC tag is set to YES, all static members of a file will be +# included in the documentation. +# The default value is: NO. + +EXTRACT_STATIC = YES + +# If the EXTRACT_LOCAL_CLASSES tag is set to YES, classes (and structs) defined +# locally in source files will be included in the documentation. If set to NO, +# only classes defined in header files are included. Does not have any effect +# for Java sources. +# The default value is: YES. + +EXTRACT_LOCAL_CLASSES = YES + +# This flag is only useful for Objective-C code. If set to YES, local methods, +# which are defined in the implementation section but not in the interface are +# included in the documentation. If set to NO, only methods in the interface are +# included. +# The default value is: NO. + +EXTRACT_LOCAL_METHODS = NO + +# If this flag is set to 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. +# The default value is: NO. + +EXTRACT_ANON_NSPACES = NO + +# If this flag is set to 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. +# The default value is: YES. + +RESOLVE_UNNAMED_PARAMS = YES + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, doxygen will hide all +# undocumented members inside documented classes or files. If set to NO these +# members will be included in the various overviews, but no documentation +# section is generated. This option has no effect if EXTRACT_ALL is enabled. +# The default value is: NO. + +HIDE_UNDOC_MEMBERS = NO + +# If the HIDE_UNDOC_CLASSES tag is set to YES, doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. If set +# to NO, these classes will be included in the various overviews. This option +# has no effect if EXTRACT_ALL is enabled. +# The default value is: NO. + +HIDE_UNDOC_CLASSES = NO + +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, doxygen will hide all friend +# declarations. If set to NO, these declarations will be included in the +# documentation. +# The default value is: NO. + +HIDE_FRIEND_COMPOUNDS = NO + +# If the HIDE_IN_BODY_DOCS tag is set to YES, doxygen will hide any +# documentation blocks found inside the body of a function. If set to NO, these +# blocks will be appended to the function's detailed documentation block. +# The default value is: NO. + +HIDE_IN_BODY_DOCS = NO + +# The INTERNAL_DOCS tag determines if documentation that is typed after a +# \internal command is included. If the tag is set to NO then the documentation +# will be excluded. Set it to YES to include the internal documentation. +# The default value is: NO. + +INTERNAL_DOCS = NO + +# With the correct setting of option 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 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 NO to properly deal with +# output files written for symbols that only differ in casing, such as for two +# classes, one named CLASS and the other named 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 NO, whereas on Linux or other Unix flavors it should typically be set to +# YES. +# The default value is: system dependent. + +CASE_SENSE_NAMES = NO + +# If the HIDE_SCOPE_NAMES tag is set to NO then doxygen will show members with +# their full class and namespace scopes in the documentation. If set to YES, the +# scope will be hidden. +# The default value is: NO. + +HIDE_SCOPE_NAMES = NO + +# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will +# append additional text to a page's title, such as Class Reference. If set to +# YES the compound reference will be hidden. +# The default value is: NO. + +HIDE_COMPOUND_REFERENCE= NO + +# If the SHOW_HEADERFILE tag is set to YES then the documentation for a class +# will show which file needs to be included to use the class. +# The default value is: YES. + +SHOW_HEADERFILE = YES + +# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of +# the files that are included by a file in the documentation of that file. +# The default value is: YES. + +SHOW_INCLUDE_FILES = YES + +# If the SHOW_GROUPED_MEMB_INC tag is set to 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. +# The default value is: NO. + +SHOW_GROUPED_MEMB_INC = NO + +# If the FORCE_LOCAL_INCLUDES tag is set to YES then doxygen will list include +# files with double quotes in the documentation rather than with sharp brackets. +# The default value is: NO. + +FORCE_LOCAL_INCLUDES = NO + +# If the INLINE_INFO tag is set to YES then a tag [inline] is inserted in the +# documentation for inline members. +# The default value is: YES. + +INLINE_INFO = YES + +# If the SORT_MEMBER_DOCS tag is set to YES then doxygen will sort the +# (detailed) documentation of file and class members alphabetically by member +# name. If set to NO, the members will appear in declaration order. +# The default value is: YES. + +SORT_MEMBER_DOCS = YES + +# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the brief +# descriptions of file, namespace and class members alphabetically by member +# name. If set to NO, the members will appear in declaration order. Note that +# this will also influence the order of the classes in the class list. +# The default value is: NO. + +SORT_BRIEF_DOCS = NO + +# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen will sort the +# (brief and detailed) documentation of class members so that constructors and +# destructors are listed first. If set to NO the constructors will appear in the +# respective orders defined by SORT_BRIEF_DOCS and SORT_MEMBER_DOCS. +# Note: If SORT_BRIEF_DOCS is set to NO this option is ignored for sorting brief +# member documentation. +# Note: If SORT_MEMBER_DOCS is set to NO this option is ignored for sorting +# detailed member documentation. +# The default value is: NO. + +SORT_MEMBERS_CTORS_1ST = NO + +# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the hierarchy +# of group names into alphabetical order. If set to NO the group names will +# appear in their defined order. +# The default value is: NO. + +SORT_GROUP_NAMES = NO + +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be sorted by +# fully-qualified names, including namespaces. If set to NO, the class list will +# be sorted only by class name, not including the namespace part. +# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. +# Note: This option applies only to the class list, not to the alphabetical +# list. +# The default value is: NO. + +SORT_BY_SCOPE_NAME = NO + +# If the 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 STRICT_PROTO_MATCHING doxygen will still +# accept a match between prototype and implementation in such cases. +# The default value is: NO. + +STRICT_PROTO_MATCHING = NO + +# The GENERATE_TODOLIST tag can be used to enable (YES) or disable (NO) the todo +# list. This list is created by putting \todo commands in the documentation. +# The default value is: YES. + +GENERATE_TODOLIST = YES + +# The GENERATE_TESTLIST tag can be used to enable (YES) or disable (NO) the test +# list. This list is created by putting \test commands in the documentation. +# The default value is: YES. + +GENERATE_TESTLIST = YES + +# The GENERATE_BUGLIST tag can be used to enable (YES) or disable (NO) the bug +# list. This list is created by putting \bug commands in the documentation. +# The default value is: YES. + +GENERATE_BUGLIST = YES + +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or disable (NO) +# the deprecated list. This list is created by putting \deprecated commands in +# the documentation. +# The default value is: YES. + +GENERATE_DEPRECATEDLIST= YES + +# The ENABLED_SECTIONS tag can be used to enable conditional documentation +# sections, marked by \if ... \endif and \cond +# ... \endcond blocks. + +ENABLED_SECTIONS = + +# The 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 \showinitializer or \hideinitializer command in the +# documentation regardless of this setting. +# Minimum value: 0, maximum value: 10000, default value: 30. + +MAX_INITIALIZER_LINES = 30 + +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated at +# the bottom of the documentation of classes and structs. If set to YES, the +# list will mention the files that were used to generate the documentation. +# The default value is: YES. + +SHOW_USED_FILES = YES + +# Set the SHOW_FILES tag to 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). +# The default value is: YES. + +SHOW_FILES = YES + +# Set the SHOW_NAMESPACES tag to 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). +# The default value is: YES. + +SHOW_NAMESPACES = YES + +# The 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 +# popen()) the command command input-file, where command is the value of the +# FILE_VERSION_FILTER tag, and 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. For an example see the documentation. + +FILE_VERSION_FILTER = + +# The 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 DoxygenLayout.xml +# will be used as the name of the layout file. See also section "Changing the +# layout of pages" for information. +# +# Note that if you run doxygen from a directory containing a file called +# DoxygenLayout.xml, doxygen will parse it automatically even if the LAYOUT_FILE +# tag is left empty. + +LAYOUT_FILE = @MATTER_BASE@/docs/_doxygen/DoxygenLayout.xml + +# The CITE_BIB_FILES tag can be used to specify one or more bib files containing +# the reference definitions. This must be a list of .bib files. The .bib +# extension is automatically appended if omitted. This requires the bibtex tool +# to be installed. See also https://en.wikipedia.org/wiki/BibTeX for more info. +# For LaTeX the style of the bibliography can be controlled using +# LATEX_BIB_STYLE. To use this feature you need bibtex and perl available in the +# search path. See also \cite for info how to create references. + +CITE_BIB_FILES = + +#--------------------------------------------------------------------------- +# Configuration options related to warning and progress messages +#--------------------------------------------------------------------------- + +# The QUIET tag can be used to turn on/off the messages that are generated to +# standard output by doxygen. If QUIET is set to YES this implies that the +# messages are off. +# The default value is: NO. + +QUIET = NO + +# The WARNINGS tag can be used to turn on/off the warning messages that are +# generated to standard error (stderr) by doxygen. If WARNINGS is set to YES +# this implies that the warnings are on. +# +# Tip: Turn warnings on while writing the documentation. +# The default value is: YES. + +WARNINGS = YES + +# If the WARN_IF_UNDOCUMENTED tag is set to YES then doxygen will generate +# warnings for undocumented members. If EXTRACT_ALL is set to YES then this flag +# will automatically be disabled. +# The default value is: YES. + +WARN_IF_UNDOCUMENTED = NO + +# If the WARN_IF_DOC_ERROR tag is set to YES, doxygen will generate warnings for +# potential errors in the documentation, such as documenting some parameters in +# a documented function twice, or documenting parameters that don't exist or +# using markup commands wrongly. +# The default value is: YES. + +WARN_IF_DOC_ERROR = YES + +# If WARN_IF_INCOMPLETE_DOC is set to YES, doxygen will warn about incomplete +# function parameter documentation. If set to NO, doxygen will accept that some +# parameters have no documentation without warning. +# The default value is: YES. + +WARN_IF_INCOMPLETE_DOC = YES + +# This 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 NO, doxygen will only warn about wrong parameter +# documentation, but not about the absence of documentation. If EXTRACT_ALL is +# set to YES then this flag will automatically be disabled. See also +# WARN_IF_INCOMPLETE_DOC +# The default value is: NO. + +WARN_NO_PARAMDOC = NO + +# If the WARN_AS_ERROR tag is set to YES then doxygen will immediately stop when +# a warning is encountered. If the WARN_AS_ERROR tag is set to FAIL_ON_WARNINGS +# then doxygen will continue running as if WARN_AS_ERROR tag is set to NO, but +# at the end of the doxygen process doxygen will return with a non-zero status. +# Possible values are: NO, YES and FAIL_ON_WARNINGS. +# The default value is: NO. + +WARN_AS_ERROR = NO + +# The WARN_FORMAT tag determines the format of the warning messages that doxygen +# can produce. The string should contain the $file, $line, and $text 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 $version, which will +# be replaced by the version of the file (if it could be obtained via +# FILE_VERSION_FILTER) +# The default value is: $file:$line: $text. + +WARN_FORMAT = "$file:$line: $text" + +# The 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). + +WARN_LOGFILE = + +#--------------------------------------------------------------------------- +# Configuration options related to the input files +#--------------------------------------------------------------------------- + +# The INPUT tag is used to specify the files and/or directories that contain +# documented source files. You may enter file names like myfile.cpp or +# directories like /usr/src/myproject. Separate the files or directories with +# spaces. See also FILE_PATTERNS and EXTENSION_MAPPING +# Note: If this tag is empty the current directory is searched. + +INPUT = @MATTER_BASE@/src/ble \ + @MATTER_BASE@/src/controller \ + @MATTER_BASE@/src/crypto \ + @MATTER_BASE@/src/include \ + @MATTER_BASE@/src/inet \ + @MATTER_BASE@/src/lib/mdns \ + @MATTER_BASE@/src/lib/core \ + @MATTER_BASE@/src/lib/support \ + @MATTER_BASE@/src/lib/shell \ + @MATTER_BASE@/src/platform \ + @MATTER_BASE@/src/setup_payload \ + @MATTER_BASE@/src/system \ + @MATTER_BASE@/src/transport + +# 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 the libiconv +# documentation (see: +# https://www.gnu.org/software/libiconv/) for the list of possible encodings. +# The default value is: UTF-8. + +INPUT_ENCODING = UTF-8 + +# If the value of the INPUT tag contains directories, you can use the +# FILE_PATTERNS tag to specify one or more wildcard patterns (like *.cpp and +# *.h) to filter out the source-files in the directories. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# read by doxygen. +# +# Note the list of default checked file patterns might differ from the list of +# default file extension mappings. +# +# If left blank the following patterns are tested:*.c, *.cc, *.cxx, *.cpp, +# *.c++, *.java, *.ii, *.ixx, *.ipp, *.i++, *.inl, *.idl, *.ddl, *.odl, *.h, +# *.hh, *.hxx, *.hpp, *.h++, *.l, *.cs, *.d, *.php, *.php4, *.php5, *.phtml, +# *.inc, *.m, *.markdown, *.md, *.mm, *.dox (to be provided as doxygen C +# comment), *.py, *.pyw, *.f90, *.f95, *.f03, *.f08, *.f18, *.f, *.for, *.vhd, +# *.vhdl, *.ucf, *.qsf and *.ice. + +FILE_PATTERNS = *.c \ + *.cc \ + *.cxx \ + *.cpp \ + *.c++ \ + *.d \ + *.java \ + *.ii \ + *.ixx \ + *.ipp \ + *.i++ \ + *.inl \ + *.h \ + *.hh \ + *.hxx \ + *.hpp \ + *.h++ \ + *.idl \ + *.odl \ + *.cs \ + *.php \ + *.php3 \ + *.inc \ + *.m \ + *.mm \ + *.dox \ + *.py \ + *.f90 \ + *.f \ + *.for \ + *.vhd \ + *.vhdl + +# The RECURSIVE tag can be used to specify whether or not subdirectories should +# be searched for input files as well. +# The default value is: NO. + +RECURSIVE = YES + +# The EXCLUDE tag can be used to specify files and/or directories that should be +# excluded from the INPUT source files. This way you can easily exclude a +# subdirectory from a directory tree whose root is specified with the INPUT tag. +# +# Note that relative paths are relative to the directory from which doxygen is +# run. + +EXCLUDE = + +# The 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. +# The default value is: NO. + +EXCLUDE_SYMLINKS = NO + +# If the value of the INPUT tag contains directories, you can use the +# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude +# certain files from those directories. +# +# Note that the wildcards are matched against the file with absolute path, so to +# exclude all test directories for example use the pattern */test/* + +EXCLUDE_PATTERNS = NetworkProvisioningServer* \ + */tests/* \ + */dbus/* \ + */gen/* \ + */zap-generated/* + +# The 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 +# +# Note that the wildcards are matched against the file with absolute path, so to +# exclude all test directories use the pattern */test/* + +EXCLUDE_SYMBOLS = VerifyOrExit \ + SuccessOrExit \ + ExitNow \ + */dbus/* + +# The EXAMPLE_PATH tag can be used to specify one or more files or directories +# that contain example code fragments that are included (see the \include +# command). + +EXAMPLE_PATH = + +# If the value of the EXAMPLE_PATH tag contains directories, you can use the +# 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. + +EXAMPLE_PATTERNS = * + +# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be +# searched for input files to be used with the \include or \dontinclude commands +# irrespective of the value of the RECURSIVE tag. +# The default value is: NO. + +EXAMPLE_RECURSIVE = NO + +# The 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 +# \image command). + +IMAGE_PATH = + +# The 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 popen()) the command: +# +# +# +# where is the value of the INPUT_FILTER tag, and is the +# name of an input file. Doxygen will then use the output that the filter +# program writes to standard output. If FILTER_PATTERNS is specified, this tag +# will be ignored. +# +# 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. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# properly processed by doxygen. + +INPUT_FILTER = + +# The 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 INPUT_FILTER for further information on how +# filters are used. If the FILTER_PATTERNS tag is empty or if none of the +# patterns match the file name, INPUT_FILTER is applied. +# +# Note that for custom extensions or not directly supported extensions you also +# need to set EXTENSION_MAPPING for the extension otherwise the files are not +# properly processed by doxygen. + +FILTER_PATTERNS = + +# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using +# INPUT_FILTER) will also be used to filter the input files that are used for +# producing the source files to browse (i.e. when SOURCE_BROWSER is set to YES). +# The default value is: NO. + +FILTER_SOURCE_FILES = NO + +# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file +# pattern. A pattern will override the setting for FILTER_PATTERN (if any) and +# it is also possible to disable source filtering for a specific pattern using +# *.ext= (so without naming a filter). +# This tag requires that the tag FILTER_SOURCE_FILES is set to YES. + +FILTER_SOURCE_PATTERNS = + +# If the 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. + +USE_MDFILE_AS_MAINPAGE = + +#--------------------------------------------------------------------------- +# Configuration options related to source browsing +#--------------------------------------------------------------------------- + +# If the SOURCE_BROWSER tag is set to YES then a list of source files will be +# generated. Documented entities will be cross-referenced with these sources. +# +# Note: To get rid of all source code in the generated output, make sure that +# also VERBATIM_HEADERS is set to NO. +# The default value is: NO. + +SOURCE_BROWSER = NO + +# Setting the INLINE_SOURCES tag to YES will include the body of functions, +# classes and enums directly into the documentation. +# The default value is: NO. + +INLINE_SOURCES = NO + +# Setting the STRIP_CODE_COMMENTS tag to 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. +# The default value is: YES. + +STRIP_CODE_COMMENTS = YES + +# If the REFERENCED_BY_RELATION tag is set to YES then for each documented +# entity all documented functions referencing it will be listed. +# The default value is: NO. + +REFERENCED_BY_RELATION = NO + +# If the REFERENCES_RELATION tag is set to YES then for each documented function +# all documented entities called/used by that function will be listed. +# The default value is: NO. + +REFERENCES_RELATION = NO + +# If the REFERENCES_LINK_SOURCE tag is set to YES and SOURCE_BROWSER tag is set +# to YES then the hyperlinks from functions in REFERENCES_RELATION and +# REFERENCED_BY_RELATION lists will link to the source code. Otherwise they will +# link to the documentation. +# The default value is: YES. + +REFERENCES_LINK_SOURCE = YES + +# 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. +# The default value is: YES. +# This tag requires that the tag SOURCE_BROWSER is set to YES. + +SOURCE_TOOLTIPS = YES + +# If the USE_HTAGS tag is set to YES then the references to source code will +# point to the HTML generated by the htags(1) tool instead of doxygen built-in +# source browser. The 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. +# +# To use it do the following: +# - Install the latest version of global +# - Enable SOURCE_BROWSER and USE_HTAGS in the configuration file +# - Make sure the INPUT points to the root of the source tree +# - Run doxygen as normal +# +# Doxygen will invoke htags (and that will in turn invoke gtags), so these +# tools must be available from the command line (i.e. in the search path). +# +# The result: instead of the source browser generated by doxygen, the links to +# source code will now point to the output of htags. +# The default value is: NO. +# This tag requires that the tag SOURCE_BROWSER is set to YES. + +USE_HTAGS = NO + +# If the VERBATIM_HEADERS tag is set the YES then doxygen will generate a +# verbatim copy of the header file for each class for which an include is +# specified. Set to NO to disable this. +# See also: Section \class. +# The default value is: YES. + +VERBATIM_HEADERS = YES + +# If the CLANG_ASSISTED_PARSING tag is set to YES then doxygen will use the +# clang parser (see: +# http://clang.llvm.org/) 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. +# The default value is: NO. + +CLANG_ASSISTED_PARSING = NO + +# If the CLANG_ASSISTED_PARSING tag is set to YES and the CLANG_ADD_INC_PATHS +# tag is set to YES then doxygen will add the directory of each input to the +# include path. +# The default value is: YES. +# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. + +CLANG_ADD_INC_PATHS = YES + +# 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 INPUT and INCLUDE_PATH. +# This tag requires that the tag CLANG_ASSISTED_PARSING is set to YES. + +CLANG_OPTIONS = + +# 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 compilation database (see: +# http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html) 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 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. + +CLANG_DATABASE_PATH = + +#--------------------------------------------------------------------------- +# Configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- + +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index of all +# compounds will be generated. Enable this if the project contains a lot of +# classes, structs, unions or interfaces. +# The default value is: YES. + +ALPHABETICAL_INDEX = YES + +# In case all classes in a project start with a common prefix, all classes will +# be put under the same header in the alphabetical index. The IGNORE_PREFIX tag +# can be used to specify a prefix (or a list of prefixes) that should be ignored +# while generating the index headers. +# This tag requires that the tag ALPHABETICAL_INDEX is set to YES. + +IGNORE_PREFIX = + +#--------------------------------------------------------------------------- +# Configuration options related to the HTML output +#--------------------------------------------------------------------------- + +# If the GENERATE_HTML tag is set to YES, doxygen will generate HTML output +# The default value is: YES. + +GENERATE_HTML = YES + +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. If a +# relative path is entered the value of OUTPUT_DIRECTORY will be put in front of +# it. +# The default directory is: html. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_OUTPUT = html + +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for each +# generated HTML page (for example: .htm, .php, .asp). +# The default value is: .html. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FILE_EXTENSION = .html + +# The HTML_HEADER tag can be used to specify a user-defined HTML header file for +# each generated HTML page. If the tag is left blank doxygen will generate a +# standard header. +# +# To get valid HTML the header file that includes any scripts and style sheets +# that doxygen needs, which is dependent on the configuration options used (e.g. +# the setting GENERATE_TREEVIEW). It is highly recommended to start with a +# default header using +# doxygen -w html new_header.html new_footer.html new_stylesheet.css +# YourConfigFile +# and then modify the file new_header.html. See also section "Doxygen usage" +# for information on how to generate the default header that doxygen normally +# uses. +# Note: The header is subject to change so you typically have to regenerate the +# default header when upgrading to a newer version of doxygen. For a description +# of the possible markers and block names see the documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_HEADER = + +# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each +# generated HTML page. If the tag is left blank doxygen will generate a standard +# footer. See HTML_HEADER for more information on how to generate a default +# footer and what special commands can be used inside the footer. See also +# section "Doxygen usage" for information on how to generate the default footer +# that doxygen normally uses. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FOOTER = + +# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style +# sheet that is used by each HTML page. It can be used to fine-tune the look of +# the HTML output. If left blank doxygen will generate a default style sheet. +# See also section "Doxygen usage" for information on how to generate the style +# sheet that doxygen normally uses. +# Note: It is recommended to use HTML_EXTRA_STYLESHEET instead of this tag, as +# it is more robust and this tag (HTML_STYLESHEET) will in the future become +# obsolete. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_STYLESHEET = + +# The HTML_EXTRA_STYLESHEET tag can be used to specify additional user-defined +# cascading style sheets that are included after the standard style sheets +# created by doxygen. Using this option one can overrule certain style aspects. +# This is preferred over using HTML_STYLESHEET since it does not replace the +# standard style sheet and is therefore more robust against future updates. +# Doxygen will copy the style sheet files to the output directory. +# Note: The order of the extra style sheet files is of importance (e.g. the last +# style sheet in the list overrules the setting of the previous ones in the +# list). For an example see the documentation. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_EXTRA_STYLESHEET = + +# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or +# other source files which should be copied to the HTML output directory. Note +# that these files will be copied to the base HTML output directory. Use the +# $relpath^ marker in the HTML_HEADER and/or HTML_FOOTER files to load these +# files. In the HTML_STYLESHEET file, use the file name only. Also note that the +# files will be copied as-is; there are no commands or markers available. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_EXTRA_FILES = + +# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen +# will adjust the colors in the style sheet and background images according to +# this color. Hue is specified as an angle on a color-wheel, see +# https://en.wikipedia.org/wiki/Hue for more information. For instance the value +# 0 represents red, 60 is yellow, 120 is green, 180 is cyan, 240 is blue, 300 +# purple, and 360 is red again. +# Minimum value: 0, maximum value: 359, default value: 220. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_HUE = 220 + +# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of the colors +# in the HTML output. For a value of 0 the output will use gray-scales only. A +# value of 255 will produce the most vivid colors. +# Minimum value: 0, maximum value: 255, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_SAT = 100 + +# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to the +# luminance component of the colors in the HTML output. Values below 100 +# gradually make the output lighter, whereas values above 100 make the output +# darker. The value divided by 100 is the actual gamma applied, so 80 represents +# a gamma of 0.8, The value 220 represents a gamma of 2.2, and 100 does not +# change the gamma. +# Minimum value: 40, maximum value: 240, default value: 80. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_COLORSTYLE_GAMMA = 80 + +# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML +# page will contain the date and time when the page was generated. Setting this +# to YES can help to show when doxygen was last run and thus if the +# documentation is up to date. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_TIMESTAMP = YES + +# If the HTML_DYNAMIC_MENUS tag is set to YES then the generated HTML +# documentation will contain a main index with vertical navigation menus that +# are dynamically created via JavaScript. If disabled, the navigation index will +# consists of multiple levels of tabs that are statically embedded in every HTML +# page. Disable this option to support browsers that do not have JavaScript, +# like the Qt help browser. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_DYNAMIC_MENUS = YES + +# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML +# documentation will contain sections that can be hidden and shown after the +# page has loaded. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_DYNAMIC_SECTIONS = NO + +# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of entries +# shown in the various tree structured indices initially; the user can expand +# and collapse entries dynamically later on. Doxygen will expand the tree to +# such a level that at most the specified number of entries are visible (unless +# a fully collapsed tree already exceeds this amount). So setting the number of +# entries 1 will produce a full collapsed tree by default. 0 is a special value +# representing an infinite number of entries and will result in a full expanded +# tree by default. +# Minimum value: 0, maximum value: 9999, default value: 100. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_INDEX_NUM_ENTRIES = 100 + +# If the GENERATE_DOCSET tag is set to YES, additional index files will be +# generated that can be used as input for Apple's Xcode 3 integrated development +# environment (see: +# https://developer.apple.com/xcode/), introduced with OSX 10.5 (Leopard). To +# create a documentation set, doxygen will generate a Makefile in the HTML +# output directory. Running make will produce the docset in that directory and +# running make install will install the docset in +# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find it at +# startup. See https://developer.apple.com/library/archive/featuredarticles/Doxy +# genXcode/_index.html for more information. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_DOCSET = NO + +# This tag determines the name of the docset feed. A documentation feed provides +# an umbrella under which multiple documentation sets from a single provider +# (such as a company or product suite) can be grouped. +# The default value is: Doxygen generated docs. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_FEEDNAME = "Doxygen generated docs" + +# This tag specifies a string that should uniquely identify the documentation +# set bundle. This should be a reverse domain-name style string, e.g. +# com.mycompany.MyDocSet. Doxygen will append .docset to the name. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_BUNDLE_ID = org.doxygen.Project + +# The DOCSET_PUBLISHER_ID tag specifies a string that should uniquely identify +# the documentation publisher. This should be a reverse domain-name style +# string, e.g. com.mycompany.MyDocSet.documentation. +# The default value is: org.doxygen.Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_PUBLISHER_ID = org.doxygen.Publisher + +# The DOCSET_PUBLISHER_NAME tag identifies the documentation publisher. +# The default value is: Publisher. +# This tag requires that the tag GENERATE_DOCSET is set to YES. + +DOCSET_PUBLISHER_NAME = Publisher + +# If the GENERATE_HTMLHELP tag is set to YES then doxygen generates three +# additional HTML index files: index.hhp, index.hhc, and index.hhk. The +# index.hhp is a project file that can be read by Microsoft's HTML Help Workshop +# on Windows. In the beginning of 2021 Microsoft took the original page, with +# a.o. the download links, offline the HTML help workshop was already many years +# in maintenance mode). You can download the HTML help workshop from the web +# archives at Installation executable (see: +# http://web.archive.org/web/20160201063255/http://download.microsoft.com/downlo +# ad/0/A/9/0A939EF6-E31C-430F-A3DF-DFAE7960D564/htmlhelp.exe). +# +# The HTML Help Workshop contains a compiler that can convert all HTML output +# generated by doxygen into a single compiled HTML file (.chm). Compiled HTML +# files are now used as the Windows 98 help format, and will replace the old +# Windows help format (.hlp) on all Windows platforms in the future. Compressed +# HTML files also contain an index, a table of contents, and you can search for +# words in the documentation. The HTML workshop also contains a viewer for +# compressed HTML files. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_HTMLHELP = NO + +# The CHM_FILE tag can be used to specify the file name of the resulting .chm +# file. You can add a path in front of the file if the result should not be +# written to the html output directory. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +CHM_FILE = + +# The HHC_LOCATION tag can be used to specify the location (absolute path +# including file name) of the HTML help compiler (hhc.exe). If non-empty, +# doxygen will try to run the HTML help compiler on the generated index.hhp. +# The file has to be specified with full path. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +HHC_LOCATION = + +# The GENERATE_CHI flag controls if a separate .chi index file is generated +# (YES) or that it should be included in the main .chm file (NO). +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +GENERATE_CHI = NO + +# The CHM_INDEX_ENCODING is used to encode HtmlHelp index (hhk), content (hhc) +# and project file content. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +CHM_INDEX_ENCODING = + +# The BINARY_TOC flag controls whether a binary table of contents is generated +# (YES) or a normal table of contents (NO) in the .chm file. Furthermore it +# enables the Previous and Next buttons. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +BINARY_TOC = NO + +# The TOC_EXPAND flag can be set to YES to add extra items for group members to +# the table of contents of the HTML help documentation and to the tree view. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTMLHELP is set to YES. + +TOC_EXPAND = NO + +# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and +# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated that +# can be used as input for Qt's qhelpgenerator to generate a Qt Compressed Help +# (.qch) of the generated HTML documentation. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_QHP = NO + +# If the QHG_LOCATION tag is specified, the QCH_FILE tag can be used to specify +# the file name of the resulting .qch file. The path specified is relative to +# the HTML output folder. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QCH_FILE = + +# The QHP_NAMESPACE tag specifies the namespace to use when generating Qt Help +# Project output. For more information please see Qt Help Project / Namespace +# (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#namespace). +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_NAMESPACE = org.doxygen.Project + +# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating Qt +# Help Project output. For more information please see Qt Help Project / Virtual +# Folders (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#virtual-folders). +# The default value is: doc. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_VIRTUAL_FOLDER = doc + +# If the QHP_CUST_FILTER_NAME tag is set, it specifies the name of a custom +# filter to add. For more information please see Qt Help Project / Custom +# Filters (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_CUST_FILTER_NAME = + +# The QHP_CUST_FILTER_ATTRS tag specifies the list of the attributes of the +# custom filter to add. For more information please see Qt Help Project / Custom +# Filters (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#custom-filters). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_CUST_FILTER_ATTRS = + +# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this +# project's filter section matches. Qt Help Project / Filter Attributes (see: +# https://doc.qt.io/archives/qt-4.8/qthelpproject.html#filter-attributes). +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHP_SECT_FILTER_ATTRS = + +# The QHG_LOCATION tag can be used to specify the location (absolute path +# including file name) of Qt's qhelpgenerator. If non-empty doxygen will try to +# run qhelpgenerator on the generated .qhp file. +# This tag requires that the tag GENERATE_QHP is set to YES. + +QHG_LOCATION = + +# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files will be +# generated, together with the HTML files, they form an Eclipse help plugin. To +# install this plugin and make it available under the help contents menu in +# Eclipse, the contents of the directory containing the HTML and XML files needs +# to be copied into the plugins directory of eclipse. The name of the directory +# within the plugins directory should be the same as the ECLIPSE_DOC_ID value. +# After copying Eclipse needs to be restarted before the help appears. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_ECLIPSEHELP = NO + +# A unique identifier for the Eclipse help plugin. When installing the plugin +# the directory name containing the HTML and XML files should also have this +# name. Each documentation set should have its own identifier. +# The default value is: org.doxygen.Project. +# This tag requires that the tag GENERATE_ECLIPSEHELP is set to YES. + +ECLIPSE_DOC_ID = org.doxygen.Project + +# If you want full control over the layout of the generated HTML pages it might +# be necessary to disable the index and replace it with your own. The +# DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) at top +# of each HTML page. A value of NO enables the index and the value YES disables +# it. Since the tabs in the index contain the same information as the navigation +# tree, you can set this option to YES if you also set GENERATE_TREEVIEW to YES. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +DISABLE_INDEX = NO + +# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index +# structure should be generated to display hierarchical information. If the tag +# value is set to YES, a side panel will be generated containing a tree-like +# index structure (just like the one that is generated for HTML Help). For this +# to work a browser that supports JavaScript, DHTML, CSS and frames is required +# (i.e. any modern browser). Windows users are probably better off using the +# HTML help feature. Via custom style sheets (see HTML_EXTRA_STYLESHEET) one can +# further fine tune the look of the index (see "Fine-tuning the output"). As an +# example, the default style sheet generated by doxygen has an example that +# shows how to put an image at the root of the tree instead of the PROJECT_NAME. +# Since the tree basically has the same information as the tab index, you could +# consider setting DISABLE_INDEX to YES when enabling this option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +GENERATE_TREEVIEW = YES + +# When both GENERATE_TREEVIEW and DISABLE_INDEX are set to YES, then the +# FULL_SIDEBAR option determines if the side bar is limited to only the treeview +# area (value NO) or if it should extend to the full height of the window (value +# YES). Setting this to YES gives a layout similar to +# https://docs.readthedocs.io with more room for contents, but less room for the +# project logo, title, and description. If either GENERATOR_TREEVIEW or +# DISABLE_INDEX is set to NO, this option has no effect. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FULL_SIDEBAR = NO + +# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values that +# doxygen will group on one line in the generated HTML documentation. +# +# Note that a value of 0 will completely suppress the enum values from appearing +# in the overview section. +# Minimum value: 0, maximum value: 20, default value: 4. +# This tag requires that the tag GENERATE_HTML is set to YES. + +ENUM_VALUES_PER_LINE = 1 + +# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be used +# to set the initial width (in pixels) of the frame in which the tree is shown. +# Minimum value: 0, maximum value: 1500, default value: 250. +# This tag requires that the tag GENERATE_HTML is set to YES. + +TREEVIEW_WIDTH = 250 + +# If the EXT_LINKS_IN_WINDOW option is set to YES, doxygen will open links to +# external symbols imported via tag files in a separate window. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +EXT_LINKS_IN_WINDOW = NO + +# If the HTML_FORMULA_FORMAT option is set to svg, doxygen will use the pdf2svg +# tool (see https://github.com/dawbarton/pdf2svg) or inkscape (see +# https://inkscape.org) to generate formulas as SVG images instead of PNGs for +# the HTML output. These images will generally look nicer at scaled resolutions. +# Possible values are: png (the default) and svg (looks nicer but requires the +# pdf2svg or inkscape tool). +# The default value is: png. +# This tag requires that the tag GENERATE_HTML is set to YES. + +HTML_FORMULA_FORMAT = png + +# Use this tag to change the font size of LaTeX formulas included as images in +# the HTML documentation. When you change the font size after a successful +# doxygen run you need to manually remove any form_*.png images from the HTML +# output directory to force them to be regenerated. +# Minimum value: 8, maximum value: 50, default value: 10. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FORMULA_FONTSIZE = 10 + +# Use the FORMULA_TRANSPARENT tag to determine whether or not the images +# generated for formulas are transparent PNGs. Transparent PNGs are not +# supported properly for IE 6.0, but are supported on all modern browsers. +# +# Note that when changing this option you need to delete any form_*.png files in +# the HTML output directory before the changes have effect. +# The default value is: YES. +# This tag requires that the tag GENERATE_HTML is set to YES. + +FORMULA_TRANSPARENT = YES + +# The FORMULA_MACROFILE can contain LaTeX \newcommand and \renewcommand commands +# to create new LaTeX commands to be used in formulas as building blocks. See +# the section "Including formulas" for details. + +FORMULA_MACROFILE = + +# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax (see +# https://www.mathjax.org) which uses client side JavaScript for the rendering +# instead of using pre-rendered bitmaps. Use this if you do not have LaTeX +# installed or if you want to formulas look prettier in the HTML output. When +# enabled you may also need to install MathJax separately and configure the path +# to it using the MATHJAX_RELPATH option. +# The default value is: NO. +# This tag requires that the tag GENERATE_HTML is set to YES. + +USE_MATHJAX = NO + +# With MATHJAX_VERSION it is possible to specify the MathJax version to be used. +# Note that the different versions of MathJax have different requirements with +# regards to the different settings, so it is possible that also other MathJax +# settings have to be changed when switching between the different MathJax +# versions. +# Possible values are: MathJax_2 and MathJax_3. +# The default value is: MathJax_2. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_VERSION = MathJax_2 + +# When MathJax is enabled you can set the default output format to be used for +# the MathJax output. For more details about the output format see MathJax +# version 2 (see: +# http://docs.mathjax.org/en/v2.7-latest/output.html) and MathJax version 3 +# (see: +# http://docs.mathjax.org/en/latest/web/components/output.html). +# Possible values are: HTML-CSS (which is slower, but has the best +# compatibility. This is the name for Mathjax version 2, for MathJax version 3 +# this will be translated into chtml), NativeMML (i.e. MathML. Only supported +# for NathJax 2. For MathJax version 3 chtml will be used instead.), chtml (This +# is the name for Mathjax version 3, for MathJax version 2 this will be +# translated into HTML-CSS) and SVG. +# The default value is: HTML-CSS. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_FORMAT = HTML-CSS + +# When MathJax is enabled you need to specify the location relative to the HTML +# output directory using the MATHJAX_RELPATH option. The destination directory +# should contain the MathJax.js script. For instance, if the mathjax directory +# is located at the same level as the HTML output directory, then +# MATHJAX_RELPATH should be ../mathjax. The default value points to the MathJax +# Content Delivery Network so you can quickly see the result without installing +# MathJax. However, it is strongly recommended to install a local copy of +# MathJax from https://www.mathjax.org before deployment. The default value is: +# - in case of MathJax version 2: https://cdn.jsdelivr.net/npm/mathjax@2 +# - in case of MathJax version 3: https://cdn.jsdelivr.net/npm/mathjax@3 +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest + +# The MATHJAX_EXTENSIONS tag can be used to specify one or more MathJax +# extension names that should be enabled during MathJax rendering. For example +# for MathJax version 2 (see https://docs.mathjax.org/en/v2.7-latest/tex.html +# #tex-and-latex-extensions): +# MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols +# For example for MathJax version 3 (see +# http://docs.mathjax.org/en/latest/input/tex/extensions/index.html): +# MATHJAX_EXTENSIONS = ams +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_EXTENSIONS = + +# The MATHJAX_CODEFILE tag can be used to specify a file with javascript pieces +# of code that will be used on startup of the MathJax code. See the MathJax site +# (see: +# http://docs.mathjax.org/en/v2.7-latest/output.html) for more details. For an +# example see the documentation. +# This tag requires that the tag USE_MATHJAX is set to YES. + +MATHJAX_CODEFILE = + +# When the SEARCHENGINE tag is enabled doxygen will generate a search box for +# the HTML output. The underlying search engine uses javascript and DHTML and +# should work on any modern browser. Note that when using HTML help +# (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets (GENERATE_DOCSET) +# there is already a search function so this one should typically be disabled. +# For large projects the javascript based search engine can be slow, then +# enabling SERVER_BASED_SEARCH may provide a better solution. It is possible to +# search using the keyboard; to jump to the search box use + S +# (what the is depends on the OS and browser, but it is typically +# , /