Basic Usage

The diagram below illustrates the workflow of the MrDocs documentation tool. It shows how inputs are transformed step by step into the final documentation output. Each component in the diagram represents a distinct type of entity:

Inputs: Provide the initial parameters and settings required to configure and run the tool. These include the configuration file and command-line arguments.
Processes: Represent intermediary outputs or data generated during the workflow.
Outputs: The final product, in this case, the generated documentation.

graph TD %% Define styles for visual clarity classDef input fill:#D1E8FF,stroke:#005CFF,stroke-width:2; classDef artifact fill:#FFF5D1,stroke:#FFA500,stroke-width:2; classDef output fill:#D1FFD1,stroke:#008000,stroke-width:2; %% Define Inputs subgraph Inputs CF[Configuration File] CL[Command Line Arguments] end class CL,CF input %% Define Artifacts subgraph Processes P[Configuration Options] CD[Compilation Database] C[Corpus] G[Generator] end class P artifact class CD,C,G artifact %% Define Outputs subgraph Outputs D[Documentation] end class D output %% Relationships CF -->|Define| P CL -->|Define| P P -->|Defines| CD CD -->|Extract Symbols| C C -->|Feeds| G G -->|Produces| D %% Highlight dependencies for clarity P -->|Influences| G

In summary:

Begin by specifying the configuration file and command-line arguments to set up the options. The configuration options affect all processes.
The configuration options define a Compilation Database. All symbols are extracted with Clang to generate a unified corpus of symbols with their corresponding documentation.
Finally, This corpus is then fed to a Generator that produces the desired documentation.

For more details on each component, refer to the corresponding sections of this guide.

MrDocs configuration file

The mrdocs.yml configuration file contains information about the project. If you’re used to Doxygen, this file is similar to the Doxyfile configuration file.

Here is an example of a mrdocs.yml file:

source-root: ../include
multipage: false
generate: adoc

In many projects, it is common to have the documentation in a docs directory, which can also contain this configuration file.

+ <project-directory>
  + docs
    + mrdocs.yml
    + ...
  + include
  + src
  + test
  + ...

The most important information is the source-root option, which determines the root of the source tree relative to the mrdocs.yml file.

The list of all available options can be found in the The Configuration File page.

MrDocs invocation

For consistency, these instructions assume you have the mrdocs executable in PATH.

Basic invocation

You can invoke MrDocs from the command line with the following command:

mrdocs path/to/mrdocs.yml

If you are at the path of the mrdocs.yml file, you can simply run:

mrdocs

You can also specify other commands to MrDocs directly from the command line to set or override options from the mrdocs.yml file (See all options in The Configuration File page).

mrdocs path/to/mrdocs.yml --output=../docs/reference

Except for the path to the mrdocs.yml file, all other relative paths are made absolute relative to the mrdocs.yml file.

Compilation databases

One way to simplify the documentation generation process is by using a compile_commands.json file generated by CMake to determine the source files to process and their compile options. This file is generated by the CMake configuration step when the CMAKE_EXPORT_COMPILE_COMMANDS option is set to ON.

cmake -B build -S . -DCMAKE_EXPORT_COMPILE_COMMANDS=ON

At this step, you can also add any other flags you want to pass to cmake, such as -DCMAKE_BUILD_TYPE=Release or -DCMAKE_CXX_COMPILER=clang++.

If you are using the Visual Studio generator, you might need to switch to the Ninja generator to generate the compile_commands.json file.

This will generate a compile_commands.json file in the build directory containing all commands needed to compile your project. This file can be used by MrDocs to determine the source files to process and their compile options.

mrdocs --compilation-database=../build/compile_commands.json --output=../docs/reference

MrDocs will go through all the source files listed in the compile_commands.json file and generate the documentation for them.

When MrDocs goes through the commands in the compilation database, it will go through the same targets as the compiler. Only symbols present in these targets will be documented. In the case of header-only libraries, the symbols will be documented only if they are included in one of these targets.

CMake integration

It’s common to have different configurations for the documentation generation than for the project build. This means CMake is often being run just to generate a custom compile_commands.json for the documentation. Also, the compile_commands.json file is a configuration artifact, which means it often lacks a stable location that can be referenced in the mrdocs.yml configuration file.

Thus, the pattern of using a compile_commands.json file generated by CMake is so common that MrDocs provides a CMake module to simplify the process. You can let MrDocs generate the compile_commands.json file for you by providing the path to the CMakeLists.txt file of your project.

mrdocs --compilation-database=../CMakeLists.txt --output=../docs/reference

By providing your CMakeLists.txt file as the reference for you compilation database, MrDocs will automatically run CMake to generate the compile_commands.json file in a temporary directory. Not only this simplifies the usage but also ensures that the stable compilation database file can be used in the mrdocs.yml configuration file.

MrDocs does not bundle CMake. If you want to use this feature, you need to have CMake installed on your system and available in PATH.

Parameters for cmake, such as -D BUILDING_TEST=OFF -D MRDOCS_BUILD=ON can also be specified with the cmake option in configuration file. MrDocs will always append the CMAKE_EXPORT_COMPILE_COMMANDS=ON flag to the cmake command.

MrDocs Builds

In many projects, a common pattern is to define a special build configuration for the documentation generation such that:

Tests, examples, and auxiliary targets excluded
All header-only files are included in targets
Unnecessary sources files are excluded from targets

This can usually be achieved by defining a custom target in the CMakeLists.txt with a single source file that includes all the necessary header files.

if (MY_PROJECT_MRDOCS_BUILD)
    # Glob all header files
    set(INCLUDE_DIR "${CMAKE_SOURCE_DIR}/include")
    file(GLOB_RECURSE HEADER_FILES "${INCLUDE_DIR}/*.hpp")

    # Create a temporary source file that includes all header files
    set(TEMP_CPP_FILE "${CMAKE_CURRENT_BINARY_DIR}/all_headers.cpp")
    file(WRITE ${TEMP_CPP_FILE} "// This file is generated automatically by CMake\n\n")
    foreach(HEADER_FILE ${HEADER_FILES_LIST})
        file(APPEND ${TEMP_CPP_FILE} "#include \"${HEADER_FILE}\"\n")
    endforeach()

    # Create a custom target for MrDocs
    add_library(my_project_mrdocs_target ${TEMP_CPP_FILE})

    # Set any other target properties here
    target_include_directories(my_project_mrdocs_target PRIVATE ${INCLUDE_DIR})
    target_link_libraries(my_project_mrdocs_target PRIVATE an_external_library)

    # Don't create any other targets
    return()
endif()

To use this target, you can run CMake with the MY_PROJECT_MRDOCS_BUILD flag set to ON:

mrdocs --cmake="-D MY_PROJECT_MRDOCS_BUILD=ON" --compilation-database=../CMakeLists.txt --output=..\docs\reference

Because these paths and options are stable, you can specify them in the mrdocs.yml configuration file.

cmake: "-D MY_PROJECT_MRDOCS_BUILD=ON"
compilation-database: ../CMakeLists.txt
output: ../docs/reference

Extracting Documentation

Unlike other documentation generators, MrDocs only works with valid C++ code. Instead of partially preprocessing the source files and inferring symbols from potentially ill-formed code, MrDocs relies on the compilation database and Clang to preprocess the source files.

Thus, for each common C++ construct, MrDocs provides commands or options to identify and extract the relevant information as intended by the user. For instance, a common ill-formed Doxygen pattern to specify a class as an implementation detail is:

#ifdef DOCS
__implementation_defined__
#else
impl::f_return_t
#endif
f();

In this pattern, the user wants to document the function f as implementation_defined f(); because the library contract is that the user should not rely on a specific return type here. However, this ill-formed pattern is problematic:

implementation_defined is not a valid symbol so the code is ill-formed
impl::f_return_t doesn’t express the intent of the user for the documentation
the developer has to effectively maintain two versions of the code
the original source code becomes more and more unreadable

Instead, when using MrDocs, the same function could be documented as:

impl::f_return_t f();

And the user can specify that impl as a namespace for implementation details in the configuration file:

# ...
implementation-detail: impl
# ...

The Commands and The Configuration File pages contain a list of all available commands and options to identify and extract the relevant information as intended by the user.

MrDocs provides multiple mechanisms are provided to specify special C++ patterns, such as the example above. For each common C++ construct that would require macros and two versions of the code, MrDocs provides commands to identify the construct and extract the relevant information as intented by the user.

Edit this Page