CMAKE-INSTRUMENTATION(7)

📦

version 4.4.5 · 8 versions

💅 CMAKE-INSTRUMENTATION(7) — the `cmake-instrumentation` manual page, bestie edition

okay so this is the cmake-instrumentation page from the CMake manual. yes it's the same CMake. yes she's serving. grab a snack, this one's long 🍓

Added in version 4.3.

✨ NAME ✨

cmake-instrumentation — CMake Instrumentation. that's it, that's the name, and honestly the rest of this page is just her explaining why she's iconic 💅

🌸 INTRODUCTION 🌸

The CMake Instrumentation API is your girl for collecting timing data, target information and system diagnostic information while a CMake project goes through its configure, generate, build, test and install steps. like she's literally watching the whole pipeline and taking notes ✨

Every single interaction with the CMake instrumentation API must specify both an API version and a Data Version. There is only one API version, so, you know, see the API v1. no cap.

🙈 Note: this feature is only available for projects using the Makefile Generators, Ninja Generators or FASTBuild. if you're on something else… not her problem, bestie 😭

🦋 Overview

CMake Instrumentation works in 2 major stages: Data Collection and Indexing. two steps. iconic behavior.

Data Collection is the process by which CMake writes out instrumentation data into a project build tree. The commands instrumented in this way range from overall builds, to individual compile commands. The full list of commands instrumented is documented under the v1 Snippet File. she's thorough, okay?

Collected data will accumulate until Indexing occurs — that's the process of collating the generated data. Indexing occurs on events called "hooks", which can be configured as part of the v1 Query Files. A v1 Index File is created and passed to any user-defined Callbacks provided to process the data. Once all Callbacks have run, CMake deletes the files. periodt. 🧹

And here's the best part — without needing any custom Callbacks at all, CMake can submit instrumentation data to CDash, or generate a Google Trace File for visualization. no extra work, she just does it 🫶

💜 Data Collection

Whenever a command is executed with instrumentation enabled, a v1 Snippet File is created in the project build tree with data specific to that command. These files remain until after Indexing occurs. they're just vibing there until the collating happens.

CMake sets the RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK and RULE_LAUNCH_CUSTOM global properties to wrap each compile, link and custom command invocation in a launcher that performs instrumentation and writes out a v1 Snippet File. so like every command gets a lil bodyguard 💅

If the project has been configured with CTestUseLaunchers, the launcher will collect instrumentation data in addition to performing the communication typically handled by that module. she's multitasking, she's thriving ✨

🔥 Indexing

Indexing is the process of collating generated instrumentation data. The available hooks to trigger indexing include options such as after every build, or every ctest invocation, and are configured as part of the v1 Query Files. Whenever a hook is triggered, an index file is generated containing a list of snippet files newer than the previous indexing. This index file is passed to user-defined Callbacks commands to process the data. slay.

Indexing and can also be performed by manually invoking ctest --collect-instrumentation. yes, you can just. do it yourself. king behavior 👑

Indexing, and the subsequent callbacks, will not occur concurrently in a single build tree. When multiple hooks trigger indexing at the same time, a file-based lock is used to ensure one indexing completes, executes all of its callbacks, and deletes the instrumentation data before the next indexing can begin. like a queue at the club, one in, one out 🎀

🎀 Callbacks

As part of the v1 Query Files, users can provide a list of callbacks intended to handle data collected by this feature. your callbacks, your rules.

Whenever Indexing occurs, each provided callback is executed, passing the path to the generated v1 Index File as an additional argument. that's the whole interface, bestie, she just hands you a path.

These callbacks — defined either at the user-level or project-level — should read the instrumentation data and perform any desired handling of it. The index file and its listed snippets are automatically deleted by CMake once all callbacks have completed.

⚠️ lowkey important: a callback should never move or delete these data files manually, because they may be needed by other callbacks. hands off the merchandise 🙈

If indexing is triggered again before Callbacks have finished running, the generated index file will contain only instrumentation data generated since the previous indexing. math is mathing 🔥

🌈 ENABLING INSTRUMENTATION 🌈

Instrumentation can be enabled either for an individual CMake project, or for all CMake projects configured and built by a user. In all cases, a "query" represents a request for instrumentation behavior. See the v1 Query Files for details on configuring this feature. one concept, two addresses, iykyk 💅

🦋 Enabling Instrumentation at the Project-Level

Project code can contain instrumentation queries by using the cmake_instrumentation() command. she's built in, bestie.

In addition, query files can be placed manually under <build>/.cmake/instrumentation/<version>/query/ at the top of a build tree. This version of CMake supports only one version schema, API v1. just the one 🎀

🧚 Enabling Instrumentation at the User-Level

Instrumentation can be configured at the user-level by placing query files in the CMAKE_CONFIG_DIR under <config_dir>/instrumentation/<version>/query/. same energy, different folder ✨

👑 Enabling Instrumentation for CDash Submissions

You can enable instrumentation when using CTest in Dashboard Client mode by setting the CTEST_USE_INSTRUMENTATION environment variable. Doing so automatically enables the dynamicSystemInformation option. yes automatically. she's thoughtful like that 💖

The following shows how each type of instrumented command gets mapped to a corresponding type of CTest XML file:

configure → Configure.xml
generate → Configure.xml
compile → Build.xml
link → Build.xml
custom → Build.xml
build → unused! 💀 (literally unused, she said what she said)
cmakeBuild → Build.xml
cmakeInstall → Build.xml
install → Build.xml
ctest → Build.xml
test → Test.xml

By default the command line reported to CDash is truncated at the first space. You can instead choose to report the full command line (including arguments) by setting CTEST_USE_VERBOSE_INSTRUMENTATION to 1. your call, no pressure 🫶

Alternatively, you can use the v1 Query Files to enable instrumentation for CDash using the cdashSubmit and cdashVerbose options. options on options, we love to see it.

In order for the submitted Build.xml file to group the snippet files correctly, all configure and build commands should be executed with CTest in Dashboard Client mode. all of them. not most. all. 😭

⭐ API V1 ⭐

The API version specifies the layout of the instrumentation directory, as well as the general format of the query files and cmake_instrumentation() command arguments. she's the blueprint, okay?

The Instrumentation API v1 is housed in the instrumentation/v1/ directory under either <build>/.cmake/ for output data and project-level queries, or <config_dir>/ for user-level queries. The v1 component of this directory is what signifies the API version. It has the following subdirectories:

query/ — Holds query files written by users or clients. Any file with the .json file extension will be recognized as a query file. These files are owned by whichever client or user creates them. yours, bestie 🫶
query/generated/ — Holds query files generated by a CMake project with the cmake_instrumentation() command or the CTEST_USE_INSTRUMENTATION variable. These files are owned by CMake and are deleted and regenerated automatically during the CMake configure step. she cleans up after herself 💅
data/ — Holds instrumentation data collected on the project. CMake owns all data files, they should never be removed by other processes. Data collected here remains until after Indexing occurs and all Callbacks are executed.
data/index/ — A subset of the collected data, containing any v1 Index Files.
data/content/ — A subset of the collected data, containing any v1 CMake Content Files.
data/trace/ — A subset of the collected data, containing the Google Trace File created from the most recent Indexing. Unlike other data files, the most recent trace file remains even after Indexing occurs and all Callbacks are executed, until the next time Indexing occurs. she lingers. respectfully ✨
data/compile-trace/ — A subset of the collected data, containing any trace files generated by the compiler, when the compileTrace option is enabled.
cdash/ — Holds temporary files used internally to generate XML content to be submitted to CDash.

💜 Data Version

The data version specifies the contents of the output files generated by the API v1 as part of the Data Collection and Indexing processes.

v1 Query Files, or a cmake_instrumentation() invocation, should request a specific Data Version, and v1 Data Files of the corresponding version will be generated and sent to the user Callbacks defined in that query. ask and you shall receive, that's the whole deal 🌸

Currently, the only supported major version is 1, and the maximum supported minor version is also 1. Here's the tea on how that numbering works 🫖 — a brand-new major version appears whenever data that used to be included gets removed or reformatted in a way that could make scripts written to parse that data incompatible with the new format. A new minor version appears whenever new data becomes available. Like, growth, but make it versioned. 💅

🌸 v1 Query Files 🌸

Any file with a .json extension under the instrumentation/v1/query/ directory is recognized as a query for instrumentation data. That's it — that's the whole vibe check. Drop a .json in there and CMake is like "oh, a query, say less" 🦋

These files must contain a JSON object with the following keys. The version key is required, but every other field is optional (so you can be a little lazy with the rest — just not with that one, iykyk).

version — the Data Version of the snippet files to generate.

In query files, this may be specified either as an integer major version or as an object with major and minor members. For example, 1 and { "major": 1, "minor": 0 } both request version 1.0. Specifying a minor version is optional — CMake will always generate instrumentation data for the most recent minor version, even if you asked for an earlier one (she's giving main character energy and doing the newest thing regardless 💁‍♀️).

Currently, the only supported major version is 1. Query files requesting a minor version up to the maximum described in Data Version are accepted; those with an unknown data version will just be ignored. Not rejected, not yelled at — ignored. ✨

callbacks — a list of command-line strings for Callbacks to handle the collected instrumentation data. Whenever these callbacks are executed, the full path to a v1 Index File gets appended to the arguments included in the string. So your callback script always knows where the index lives 🎀
hooks — a list of strings specifying when Indexing should occur automatically. These are the intervals when instrumentation data should be collated and your user Callbacks should be invoked to handle the data. Elements in this list should be one of the following:
- postGenerate
- preBuild (called when ninja or make is invoked)
- postBuild (called when ninja or make completes)
- preCMakeBuild (called when cmake --build is invoked)
- postCMakeBuild (called when cmake --build completes)
- postCMakeInstall
- postCMakeWorkflow
- postCTest

Heads up bestie ⚠️ preBuild and postBuild are not supported when using the MSYS Makefiles or FASTBuild generators. Additionally, they will not be triggered when the build tool is invoked by cmake --build. Sad but true 😭

options — a list of strings used to enable certain optional behavior, including the collection of certain additional data. Elements in this list should be one of the following:
- staticSystemInformation — enables collection of the static information about the host machine CMake is being run from. This data is collected during Indexing and is included in the generated v1 Index File. 🖥️
- dynamicSystemInformation — enables collection of the dynamic information about the host machine CMake is being run from. Data is collected for every v1 Snippet File generated by CMake, and includes information from immediately before and after the command is executed. Obsessed with the before/after pics ngl 📸
- captureOutput — Added in version 4.4. Enables collection of command output in generated v1 Snippet Files. When enabled, snippets for compile, link, custom, test, and install commands include stdout and stderr fields. Only available as of data version 1.1.
- compileTrace — Added in version 4.4. Enables collection of JSON files generated by Clang's -ftime-trace option. When such files are created for an instrumented compile command, they are copied into the instrumentation data directory and referenced from the compile snippet. Only available as of data version 1.1.
- cdashSubmit — enables including instrumentation data in CDash. This is equivalent to having the CTEST_USE_INSTRUMENTATION environment variable enabled.
- cdashVerbose — enables including the full untruncated commands in data submitted to CDash. Equivalent to having the CTEST_USE_VERBOSE_INSTRUMENTATION and CTEST_USE_INSTRUMENTATION environment variables enabled. Full commands, no cuts ✂️❌
- trace — enables generation of a Google Trace File during Indexing to visualize data from the v1 Snippet Files collected. Pretty visuals, we love to see it 🌈

The callbacks listed will be invoked during the specified hooks at a minimum. And here's where it gets spicy 🌶️ — when there are multiple query files, the callbacks, hooks and options between them will be merged. So if any query file includes any hooks, then every callback across all query files will be executed at every hook across all query files. Additionally, if any query file requests optional data using the options field, any related data will be present in all snippet files. User written callbacks should be able to handle the presence of this optional data, since it may be requested by an unrelated query. Basically: everybody shares, no gatekeeping 🫶

The JSON format is described in machine-readable form by this JSON schema.

Example:

{
  "version": 1,
  "callbacks": [
    "/usr/bin/python callback.py",
    "/usr/bin/cmake -P callback.cmake arg",
  ],
  "hooks": [
    "postCMakeBuild",
    "postCMakeInstall"
  ],
  "options": [
    "staticSystemInformation",
    "dynamicSystemInformation",
    "captureOutput",
    "cdashSubmit",
    "trace"
  ]
}

In this example, after every cmake --build or cmake --install invocation, an index file index-<timestamp>.json will be generated in <build>/.cmake/instrumentation/v1/data/index containing a list of data snippet files created since the previous indexing. The commands /usr/bin/python callback.py index-<timestamp>.json and /usr/bin/cmake -P callback.cmake arg index-<timestamp>.json will be executed in that order (order matters, bestie, they're not running in parallel 💅). The index file will contain the staticSystemInformation data and each snippet file listed in the index will contain the dynamicSystemInformation data and captured command output. Additionally, the index file will contain the path to the generated Google Trace File. Once both callbacks have completed, the index file and data files listed by it (including snippet files, but not the trace file) will be deleted from the project build tree. The instrumentation data will be present in the XML files submitted to CDash, but with truncated command strings because cdashVerbose was not enabled. Truncated! Because you didn't ask nicely for the full ones 😌

🧚 v1 Data Files 🧚

There are four types of data files generated as part of API v1, and yes we're counting them like a girlboss counting her rings 👑:

the v1 Snippet File
v1 Index File
v1 CMake Content File
the Google Trace File

These files live in <build>/.cmake/instrumentation/v1/data/ under the project build tree. One folder, all the lore 🗂️

Note that the v1 delineation of these files refers to the API v1. The Data Version of these files is specified with a version field as part of the file contents. Two different version things, don't mix them up fr fr 🙈

🎀 v1 Snippet File 🎀

Snippet files are generated for every compile, link and custom command invoked as part of the CMake build or install step, and contain instrumentation data about the command executed. Additionally, snippet files are created for the following:

The CMake configure step
The CMake generate step
Entire build step (executed with cmake --build)
Entire install step (executed with cmake --install)
Each time ctest is invoked to run tests (even if no tests are found — yes, even then, she's thorough 💀)
Each individual test executed by ctest

These files remain in the build tree until after Indexing occurs and any user-specified Callbacks are executed. So don't go deleting them yourself, they've got a job to do 🫡

Note: Configure and generate snippet files are not written by CMake until the generate step is complete. When using cmake-gui(1) or ccmake(1), triggering only configure step(s) without generating the project files will not generate any configure snippets. Once the generate step is run, there will be one configure snippet for each time the configure step was run. No generate, no snippet — those are the rules ✨

Snippet files have a filename with the syntax <role>-<hash>-<timestamp>.json and contain the following data:

version — the Data Version of the snippet file, written as { "major": 1, "minor": N } where N is the most recent minor version.
command — the full command executed. Excluded when role is build (build's too cool to show the full command, apparently 😤).
workingDir — the working directory in which the command was executed.
result — the exit code of the command, an integer. This will be null when role is build.
stdout — Added in version 4.4. The standard output produced by the command. Only included when enabled by the captureOutput option and when role is one of: compile, link, custom, install or test. For test snippets, this field contains the merged standard out and standard error streams. Two streams, one field, we love a merge 💜
stderr — Added in version 4.4. The standard error output produced by the command. Only included when enabled by the captureOutput option and when role is one of: compile, link, custom, install or test. For test snippets, error output is merged with stdout, and the value of stderr is always empty. Empty! Nothing in there! It all went to stdout bestie 🌸
role — the type of command executed, which will be one of the following values:
- configure: the CMake configure step
- generate: the CMake generate step
- compile: an individual compile step invoked during the build
- link: an individual link step invoked during the build
- custom: an individual custom command invoked during the build

so the role field can be one of these, bestie:

build — a complete make or ninja invocation (not through cmake --build <#cmdoption-cmake-build>).
cmakeBuild — a complete cmake --build <#cmdoption-cmake-build> invocation.
cmakeInstall — a complete cmake --install <#cmdoption-cmake-install> invocation.
install — an individual cmake -P cmake_install.cmake invocation.
ctest — a complete ctest <#manual:ctest(1)> command invocation.
test — a single test executed by ctest <#manual:ctest(1)>.

target — the CMake target associated with the command. Only included when role is compile or link, or when role is custom and the custom command is attached to a target with add_custom_command(TARGET) <#target>. In conjunction with cmakeContent, this can be used to look up the target TYPE <#prop_tgt:TYPE> and LABELS <#prop_tgt:LABELS>.
timeStart — time at which the command started, expressed as the number of milliseconds since the system epoch.
duration — the duration that the command ran for, expressed in milliseconds.
outputs — the command's output file(s), an array. Only included when role is one of: compile, link, custom.
outputSizes — the size(s) in bytes of the outputs, an array. For files which do not exist, the size is 0. Included under the same conditions as the outputs field.
source — the source file being compiled. Only included when role is compile.
language — the language of the source file being compiled. Only included when role is compile or link.
testName — the name of the test being executed. Only included when role is test.
config — the Build Configuration <#build-configurations>, such as Release or Debug. Only included when role is one of: compile, link, custom, install, test.
traceFile — Added in version 4.4. A path, relative to the instrumentation data directory, referencing a copied JSON file generated by Clang's -ftime-trace option. Only included when the compileTrace option is enabled and role is compile. If no JSON file was produced by the compile command, this value is null.
dynamicSystemInformation — specifies the dynamic information collected about the host machine CMake is being run from. Data is collected for every snippet file generated by CMake, with data immediately before and after the command is executed. Only included when enabled by the v1 Query Files.
- beforeHostMemoryUsed — the Host Memory Used in KiB at timeStart.
- afterHostMemoryUsed — the Host Memory Used in KiB at timeStart + duration.
- beforeCPULoadAverage — the Average CPU Load at timeStart, or null if it cannot be determined.
- afterCPULoadAverage — the Average CPU Load at timeStart + duration, or null if it cannot be determined.
cmakeContent — the path to a v1 CMake Content File located under data, which contains information about the CMake configure and generate steps responsible for generating the command in this snippet. When using cmake-gui(1) <#manual:cmake-gui(1)> or ccmake(1) <#manual:ccmake(1)>, this field may be null for all configure steps up to the most recent one before the generate step.
showOnly — a boolean representing whether the --show-only <#cmdoption-ctest-N> option was passed to ctest <#manual:ctest(1)>. Only included when role is ctest.

Example:

{
  "version": {
    "major": 1,
    "minor": 1
  },
  "command" : "\"/usr/bin/c++\" \"-MD\" \"-MT\" \"CMakeFiles/main.dir/main.cxx.o\" \"-MF\" \"CMakeFiles/main.dir/main.cxx.o.d\" \"-o\" \"CMakeFiles/main.dir/main.cxx.o\" \"-c\" \"<src>/main.cxx\"",
  "role" : "compile",
  "result" : 1,
  "stdout" : "<compiler stdout>",
  "stderr" : "<compiler stderr>",
  "target": "main",
  "language" : "C++",
  "outputs" : [ "CMakeFiles/main.dir/main.cxx.o" ],
  "outputSizes" : [ 0 ],
  "traceFile" : "compile-trace/main.cxx-<hash>.json",
  "source" : "<src>/main.cxx",
  "config" : "Debug",
  "dynamicSystemInformation" :
  {
    "afterCPULoadAverage" : 2.3500000000000001,
    "afterHostMemoryUsed" : 6635680.0
    "beforeCPULoadAverage" : 2.3500000000000001,
    "beforeHostMemoryUsed" : 6635832.0
  },
  "timeStart" : 1737053448177,
  "duration" : 31,
  "cmakeContent" : "content/cmake-2025-07-11T12-46-32-0572.json"
}

Added in version 4.4: The JSON format is described in machine-readable form by this JSON schema.

v1 Index File

Index files contain a list of v1 Snippet Files. It's literally your entry point for navigating all the instrumentation data. They're generated whenever Indexing occurs and deleted after any user-specified Callbacks are executed. So yeah, they don't stick around forever. 💅

version — the Data Version of the index file, written as { "major": 1, "minor": N } where N is the most recent minor version.
buildDir — the build directory of the CMake project.
dataDir — the full path to the <build>/.cmake/instrumentation/v1/data/ directory.
hook — the name of the hook responsible for generating the index file. In addition to the hooks that can be specified by one of the v1 Query Files, this value may be set to manual if indexing is performed by invoking ctest --collect-instrumentation <#cmdoption-ctest-collect-instrumentation>.

Note that the hook is not directly tied to what data may be available. A postBuild hook, for example, may include test or install snippets, if these steps were run since the previous indexing.

snippets — contains a list of v1 Snippet Files. This includes all snippet files generated since the previous index file was created. The file paths are relative to dataDir.

This list may be empty if indexing was run twice in succession, such as when building multiple times with both the preBuild and postBuild hooks enabled.

trace — contains the path to the Google Trace File. This includes data from all corresponding snippets in the index file. The file path is relative to dataDir. Only included when enabled by the v1 Query Files.
staticSystemInformation — specifies the static information collected about the host machine CMake is being run from. If CMake is unable to determine the value of any given field, it will be null. See cmake_host_system_information() <#command:cmake_host_system_information> for a description of each of the following fields. Only included when enabled by the v1 Query Files.
- OSName
- OSPlatform
- OSRelease
- OSVersion
- familyId
- hostname
- is64Bits
- modelId
- modelName
- numberOfLogicalCPU
- numberOfPhysicalCPU
- processorAPICID
- processorCacheSize
- processorClockFrequency
- processorName
- totalPhysicalMemory
- totalVirtualMemory
- vendorID
- vendorString

Example:

{
  "version": {
    "major": 1,
    "minor": 0
  },
  "hook": "manual",
  "buildDir": "<build>",
  "dataDir": "<build>/.cmake/instrumentation/v1/data",
  "snippets": [
    "configure-<hash>-<timestamp>.json",
    "generate-<hash>-<timestamp>.json",
    "compile-<hash>-<timestamp>.json",
    "compile-<hash>-<timestamp>.json",
    "link-<hash>-<timestamp>.json",
    "install-<hash>-<timestamp>.json",
    "ctest-<hash>-<timestamp>.json",
    "test-<hash>-<timestamp>.json",
    "test-<hash>-<timestamp>.json",
  ],
  "trace": "trace/trace-<timestamp>.json"
}

Added in version 4.4: The JSON format is described in machine-readable form by this JSON schema.

v1 CMake Content File

CMake content files contain information about the CMake configure and generate steps. Each v1 Snippet File gives you the path to one of these files corresponding to the CMake invocation responsible for generating its command. 🫶

Each CMake content file contains the following:

version — the Data Version of the content file, written as { "major": 1, "minor": N } where N is the most recent minor version.
project — the value of CMAKE_PROJECT_NAME <#variable:CMAKE_PROJECT_NAME>.
custom — an object containing arbitrary JSON data specified by the user with the Custom CMake Content <#cmake-instrumentation-custom-content> functionality of the cmake_instrumentation() <#command:cmake_instrumentation> command.
targets — an object containing CMake targets, indexed by name, that have corresponding instrumentation data. Each target contains the following:
- type — the TYPE <#prop_tgt:TYPE> property of the target. Only EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY and OBJECT_LIBRARY targets are included.
- labels — the LABELS <#prop_tgt:LABELS> property of the target.

Google Trace File

CMake can generate a file in the Google Trace Event Format <https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview> to help visualize collected instrumentation data. Enabling the trace option in the v1 Query Files causes such a file to be generated under <build>/.cmake/instrumentation/v1/data/trace whenever Indexing occurs. ✨

Generated trace files include data from all v1 Snippet Files listed in the current index file.

When instrumentation data is deleted by CMake after Indexing, the most recent trace file remains so that it can be manually inspected without the need for any custom Callbacks. So it's like a little souvenir. 🎀

Trace files are stored in the JSON Array Format, where each v1 Snippet File corresponds to a single trace event object. Each trace event contains the following data:

name — a descriptive name that CMake cooks up for you based on the snippet data you handed over. cute and auto-generated, no cap ✨
cat — the role, straight from the v1 Snippet File. it's giving "what kind of snippet is this" energy 👑
ph — rn this is always "X", which stands for "Complete Events". iconic, honestly 💅
ts — the timeStart from the v1 Snippet File, but converted from milliseconds to microseconds (the glow-up unit conversion 🦋)
dur — the duration from the v1 Snippet File, also converted from milliseconds to microseconds ⏱️
pid — unused, always zero. it's just sitting there, living its best decorative life 🙈
tid — an integer ranging from zero to the number of concurrent jobs that the processes being indexed ran with. this one's a synthetic ID that CMake calculates from the ts and dur of all the snippet files being indexed, so the visualization of your process concurrency actually looks good instead of a whole mess 🌈
args — contains all the data from the v1 Snippet File that corresponds to this trace event. the whole little payload, wrapped up and ready 🎀

💖 COPYRIGHT 💖

2000-2026 Kitware, Inc. and Contributors

and that's the whole page, bestie!! 🫶 you officially read the entire CMAKE-INSTRUMENTATION(7) manual — main character behavior fr fr 👑 this gorgeous little doc is CMake 4.4.5, dated Oct 28, 2026, so go forth and instrument responsibly 💜✨

📦 where this page comes from

arch rolling: cmake 4.4.5-1 · BSD-3-Clause
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms

CMAKE-INSTRUMENTATION(7)