CMAKE-FILE-API(7)

cmake-file-api 💅✨

okay so bestie, welcome to cmake-file-api(7) — the official CMake File-Based API manual, and honestly it's giving "backstage pass to the build system" energy 🎀

---

🌸 NAME 🌸

cmake-file-api — the CMake File-Based API 🦋

---

✨ INTRODUCTION ✨

So CMake ships with a file-based API that clients can use to get semantic info about the buildsystems CMake generates. Here's the whole vibe: a client writes query files into a specific spot in a build tree, asking for zero or more Object Kinds. Then, when CMake generates the buildsystem in that build tree, it reads those query files and writes back reply files for the client to read. Receipts!! 📬

The file-based API lives in a <build>/.cmake/api/ directory at the top of a build tree. And it's versioned, specifically so the layout of files inside the API directory can change down the line. Important distinction, bestie: this API file layout versioning is orthogonal to the versioning of the Object Kinds used in replies — two separate things, don't mix them up 💀. This version of CMake supports exactly one API version: API v1.

Added in version 3.27: Projects may also submit queries for the current run using the cmake_file_api() command. cute!!

---

👑 API V1 👑

API v1 lives in the <build>/.cmake/api/v1/ directory. It's got these subdirectories:

• query/ — holds query files written by clients. These may be v1 Shared Stateless Query Files, v1 Client Stateless Query Files, or v1 Client Stateful Query Files. three flavors, all iconic 💅
• reply/ — holds reply files written by CMake when it runs to generate a build system. Clients may read reply files only when they're referenced by a reply index:
  • <cyan>index-*.json</cyan> — a v1 Reply Index File written when CMake generates a build system.
  • <cyan>error-*.json</cyan> — Added in version 4.1. A v1 Reply Error Index written when CMake fails to generate a build system due to an error. 😭

Clients may look for and read a reply index at any time, fr. Clients may optionally create the reply/ directory at any time and monitor it for the appearance of a new reply index. But heads up: CMake owns all reply files. Clients must never remove them — not even one, not even a little 🙈

Added in version 3.31: Users can add query files to api/v1/query inside the CMAKE_CONFIG_DIR environment variable to create user-wide queries for all CMake projects. slay.

---

🎀 v1 Shared Stateless Query Files 🎀

Shared stateless query files let clients share requests for major versions of the Object Kinds and get back all requested versions that the running CMake recognizes. teamwork!!

Clients may create shared requests by creating empty files in the v1/query/ directory. The form is:

<build>/.cmake/api/v1/query/<kind>-v<major>

where <kind> is one of the Object Kinds, -v is literal, and <major> is the major version number.

Files of this form are stateless shared queries not owned by any specific client. Once created they should not be removed without external client coordination or human intervention. so like, don't just yeet them ok 🫶

---

🦋 v1 Client Stateless Query Files 🦋

Client stateless query files let clients create owned requests for major versions of the Object Kinds and get all requested versions recognized by the CMake that runs.

Clients may create owned requests by creating empty files in client-specific query subdirectories. The form is:

<build>/.cmake/api/v1/query/client-<client>/<kind>-v<major>

where client- is literal, <client> is a string uniquely identifying the client, <kind> is one of the Object Kinds, -v is literal, and <major> is the major version number. Each client must choose a unique <client> identifier via its own means — no copying someone else's name bestie, that's not the vibe 💀

Files of this form are stateless queries owned by the client <client>. The owning client may remove them at any time. it's yours, do what you want 💖

---

🌈 v1 Client Stateful Query Files 🌈

Stateful query files let clients request a list of versions of each of the Object Kinds and get back only the most recent version recognized by the CMake that runs. one answer, freshest one, periodt.

Clients may create owned stateful queries by creating query.json files in client-specific query subdirectories. The form is:

<build>/.cmake/api/v1/query/client-<client>/query.json

where client- is literal, <client> is a string uniquely identifying the client, and query.json is literal. Each client must choose a unique <client> identifier via its own means.

query.json files are stateful queries owned by the client <client>. The owning client may update or remove them at any time. And when a given client installation gets updated, it may then update the stateful query it writes to build trees to request newer object versions. This can be used to avoid asking CMake to generate multiple object versions unnecessarily — efficiency queen behavior 👑

Added in version 4.1: The query.json file is described in machine-readable form by this JSON schema.

A query.json file must contain a JSON object:

{
  "requests": [
    { "kind": "<kind>" , "version": 1 },
    { "kind": "<kind>" , "version": { "major": 1, "minor": 2 } },
    { "kind": "<kind>" , "version": [2, 1] },
    { "kind": "<kind>" , "version": [2, { "major": 1, "minor": 2 }] },
    { "kind": "<kind>" , "version": 1, "client": {} },
    { "kind": "..." }
  ],
  "client": {}
}

The members are:

• requests — a JSON array containing zero or more requests. Each request is a JSON object with members:
  • kind — specifies one of the Object Kinds to be included in the reply.
  • version — indicates the version(s) of the object kind that the client understands. Versions have major and minor components following semantic version conventions. The value must be
    • a JSON integer specifying a (non-negative) major version number, or
    • a JSON object containing major and (optionally) minor members specifying non-negative integer version components, or
    • a JSON array whose elements are each one of the above.
  • client — optional member reserved for use by the client. This value is preserved in the reply written for the client in the v1 Reply Index File but is otherwise ignored. Clients may use this to pass custom information with a request through to its reply. cute little passthrough 🎀

For each requested object kind CMake will choose the first version that it recognizes for that kind among those listed in the request. The response will use the selected major version with the highest minor version known to the running CMake for that major version. Therefore clients should list all supported major versions in preferred order along with the minimal minor version required for each major version. order matters, bestie, read the room 📋

• client — optional member reserved for use by the client. This value is preserved in the reply written for the client in the v1 Reply Index File but is otherwise ignored. Clients may use this to pass custom information with a query through to its reply.

Other query.json top-level members are reserved for future use. If they're present they are ignored for forward compatibility. future-proofing, we love to see it ✨

---

⭐ v1 Reply Index File ⭐

CMake writes an index-*.json file to the v1/reply/ directory when it successfully generates a build system. Clients must read the reply index file first, and may read other v1 Reply Files only by following references. The form of the reply index file name is:

<build>/.cmake/api/v1/reply/index-<unspecified>.json

where index- is literal and <unspecified> is an unspecified name selected by CMake. Whenever a new index file is generated it gets a brand new name and any old one is deleted. During the short time between these steps there may be multiple index files hanging out — the one with the largest name in lexicographic order is the current index file. iykyk 🔥

Added in version 4.1: The reply index file is described in machine-readable form by this JSON schema.

The reply index file contains a JSON object:

{
  "cmake": {
    "version": {
      "major": 3, "minor": 14, "patch": 0, "suffix": "",
      "string": "3.14.0", "isDirty": false
    },
    "paths": {
      "cmake": "/prefix/bin/cmake",
      "ctest": "/prefix/bin/ctest",
      "cpack": "/prefix/bin/cpack",
      "root": "/prefix/share/cmake-3.14"
    },
    "generator": {
      "multiConfig": false,
      "name": "Unix Makefiles"
    }
  },
  "objects": [
    { "kind": "<kind>",
      "version": { "major": 1, "minor": 0 },
      "jsonFile": "<file>" },
    { "...": "..." }
  ],
  "reply": {
    "<kind>-v<major>": { "kind": "<kind>",
                         "version": { "major": 1, "minor": 0 },
                         "jsonFile": "<file>" },
    "<unknown>": { "error": "unknown query file" },
    "...": {},
    "client-<client>": {
      "<kind>-v<major>": { "kind": "<kind>",
                           "version": { "major": 1, "minor": 0 },
                           "jsonFile": "<file>" },
      "<unknown>": { "error": "unknown query file" },
      "...": {},
      "query.json": {
        "requests": [ {}, {}, {} ],
        "responses": [
          { "kind": "<kind>",
            "version": { "major": 1, "minor": 0 },
            "jsonFile": "<file>" },
          { "error": "unknown query file" },
          { "...": {} }
        ],
        "client": {}
      }
    }
  }
}

The members are:

• cmake — a JSON object containing info about the instance of CMake that generated the reply. It contains members:
  • version — a JSON object specifying the version of CMake with members:
    • major, minor, patch — integer values specifying the major, minor, and patch version components.
    • suffix — a string specifying the version suffix, if any, e.g. g0abc3.
    • string — a string specifying the full version in the format <major>.<minor>.<patch>[-<suffix>].
    • isDirty — a boolean indicating whether the version was built from a version controlled source tree with local modifications. 👀
• paths — a JSON object listing paths to stuff that ships with CMake 💫. It's got members for cmake, ctest, and cpack, and each value is a JSON string holding the absolute path to that tool, written with forward slashes. It also has a root member: the absolute path to the directory holding CMake resources like the Modules/ directory (peep CMAKE_ROOT).
• generator — a JSON object describing the CMake generator used for the build 🛠️. Members:
  • multiConfig — a boolean saying whether the generator supports multiple output configurations.
  • name — a string with the generator's name.
  • platform — if the generator supports CMAKE_GENERATOR_PLATFORM, this is a string with the generator platform name.
• objects — a JSON array listing all versions of all Object Kinds generated as part of the reply ✨. Each entry in the array is a v1 Reply File Reference.
• reply — a JSON object mirroring the content of the query/ directory that CMake loaded to produce the reply 🪞. Its members look like:
  • <kind>-v<major> — one of these shows up for each of the v1 Shared Stateless Query Files that CMake recognized as a request for object kind <kind> with major version <major>. The value is either:
    • a v1 Reply File Reference to the matching reply file for that object kind and version, or
    • in a v1 Reply Error Index, a JSON object with a single error member holding a string with an error message.
  • <unknown> — one of these shows up for each of the v1 Shared Stateless Query Files CMake did not recognize 😬. The value is a JSON object with a single error member holding a string with an error message saying the query file is unknown.
  • client-<client> — one of these shows up for each client-owned directory holding v1 Client Stateless Query Files. The value is a JSON object mirroring the content of the query/client-<client>/ directory. Members:
    • <kind>-v<major> — shows up for each of the v1 Client Stateless Query Files that CMake recognized as a request for object kind <kind> with major version <major>. The value is either:
      • a v1 Reply File Reference to the matching reply file for that object kind and version, or
      • in a v1 Reply Error Index, a JSON object with a single error member holding a string with an error message.
    • <unknown> — shows up for each of the v1 Client Stateless Query Files CMake did not recognize. The value is a JSON object with a single error member holding a string with an error message saying the query file is unknown.
    • query.json — this one shows up for clients using v1 Client Stateful Query Files 🌸. If the query.json file failed to read or parse as a JSON object, this member is a JSON object with a single error member holding a string with an error message. Otherwise, this member is a JSON object mirroring the content of the query.json file. Its members:
      • client — a copy of the query.json file's client member, if it exists.
      • requests — a copy of the query.json file's requests member, if it exists.
      • responses — if the query.json file's requests member is missing or invalid, this member is a JSON object with a single error member holding a string with an error message. Otherwise, it's a JSON array with a response for each entry of the requests array, in the same order. Each response is either:
        • a v1 Reply File Reference to the matching reply file for the requested object kind and selected version, or
        • a JSON object with a single error member holding a string with an error message.

After reading the reply index file, clients may read the other v1 Reply Files it references 📖.

🎀 v1 Reply File Reference 🎀

The reply index file represents each reference to another reply file using a JSON object with these members:

• kind — a string specifying one of the Object Kinds.
• version — a JSON object with members major and minor specifying integer version components of the object kind.
• jsonFile — a JSON string specifying a path relative to the reply index file, pointing to another JSON file that contains the object.

💅 v1 Reply Error Index 💅

Added in version 4.1.

CMake writes an error-*.json file to the v1/reply/ directory when it fails to generate a build system 😭. This reply error index follows the same naming pattern, syntax, and semantics as a v1 Reply Index File, with these exceptions:

• The index- prefix gets swapped for an error- prefix.
• When a new error index is generated, old index files are not deleted. If a v1 Reply Index File exists, it indexes replies from the most recent successful run. If multiple index-*.json and/or error-*.json files are around, the one with the largest name in lexicographic order — excluding the index- or error- prefix — is the current index 👑.
• Only a subset of Object Kinds get provided:
  • configureLog — added in version 4.1.
  • Index entries for other object kinds contain an error message instead of a v1 Reply File Reference.

🦋 v1 Reply Files 🦋

Reply files containing specific Object Kinds are written by CMake. The names of these files are unspecified and must not be interpreted by clients 🙅‍♀️. Clients must first read the v1 Reply Index File and then follow references to the names of the desired response objects.

Reply files (index file included) will never be replaced by files with the same name but different content. That's what lets a client read the files at the same time as a running CMake that might generate a new reply 🔥. BUT — after generating a new reply, CMake will attempt to remove reply files from previous runs that it didn't just write. So if a client tries to read a reply file referenced by the index and finds it missing, that means a concurrent CMake generated a new reply. No drama: the client can simply start over by reading the new reply index file 💫.

---

🌈 OBJECT KINDS 🌈

The CMake file-based API reports semantic information about the build system using the following kinds of JSON objects. Each kind is versioned independently with semantic versioning, using major and minor components. Every kind of object looks like:

{
  "kind": "<kind>",
  "version": { "major": 1, "minor": 0 },
  "...": {}
}

The kind member is a string specifying the object kind name. The version member is a JSON object with major and minor members specifying the integer components of the object kind's version. Any additional top-level members are specific to each object kind.

⭐ Object Kind "codemodel" ⭐

The codemodel object kind describes the build system structure as modeled by CMake.

There's only one codemodel object major version: version 2️⃣. Version 1 straight-up does not exist, specifically to avoid confusion with the one from cmake-server(7) mode. iykyk.

Added in version 4.1: The codemodel object kind reply is described in machine-readable form by this JSON schema.

🫶 "codemodel" version 2 🫶

codemodel object version 2 is a JSON object:

{
  "kind": "codemodel",
  "version": { "major": 2, "minor": 8 },
  "paths": {
    "source": "/path/to/top-level-source-dir",
    "build": "/path/to/top-level-build-dir"
  },
  "configurations": [
    {
      "name": "Debug",
      "directories": [
        {
          "source": ".",
          "build": ".",
          "childIndexes": [ 1 ],
          "projectIndex": 0,
          "targetIndexes": [ 0 ],
          "abstractTargetIndexes": [ 1 ],
          "hasInstallRule": true,
          "minimumCMakeVersion": {
            "string": "3.14"
          },
          "jsonFile": "<file>"
        },
        {
          "source": "sub",
          "build": "sub",
          "parentIndex": 0,
          "projectIndex": 0,
          "targetIndexes": [ 1 ],
          "abstractTargetIndexes": [ 0 ],
          "minimumCMakeVersion": {
            "string": "3.14"
          },
          "jsonFile": "<file>"
        }
      ],
      "projects": [
        {
          "name": "MyProject",
          "directoryIndexes": [ 0, 1 ],
          "targetIndexes": [ 0, 1 ],
          "abstractTargetIndexes": [ 0, 1 ],
        }
      ],
      "targets": [
        {
          "name": "MyExecutable",
          "directoryIndex": 0,
          "projectIndex": 0,
          "jsonFile": "<file>"
        },
        {
          "name": "MyLibrary",
          "directoryIndex": 1,
          "projectIndex": 0,
          "jsonFile": "<file>"
        }
      ]
      "abstractTargets": [
        {
          "name": "MyImportedExecutable",
          "directoryIndex": 1,
          "projectIndex": 0,
          "jsonFile": "<file>"
        },
        {
          "name": "MyPureInterfaceLibrary",
          "directoryIndex": 0,
          "projectIndex": 0,
          "jsonFile": "<file>"
        }
      ]
    }
  ]
}

okay so those are the members that are specific to codemodel objects — like, the ones that only show up here and nowhere else. buckle up bestie, there's a lot 💅

• paths — a JSON object, and inside it lives:
  • source — a string with the absolute path to the top-level source directory, written with forward slashes (yes, forward — slashes behaving themselves for once 🎀).
  • build — a string with the absolute path to the top-level build directory, also with forward slashes.
• configurations — a JSON array of entries, one for each build configuration that's available. On single-configuration generators there's exactly one entry, and it's the value of the CMAKE_BUILD_TYPE variable. On multi-configuration generators there's an entry for every configuration listed in the CMAKE_CONFIGURATION_TYPES variable. each entry is a JSON object with these members:
  • name — a string with the configuration's name, like Debug.
  • directories — a JSON array of entries, each one corresponding to a build system directory whose source directory has a CMakeLists.txt file in it. the first entry is always the top-level directory, no exceptions 💖 each entry is a JSON object with these members:
    • source — a string with the path to the source directory, forward slashes again. if the directory is inside the top-level source directory, the path is relative to it (with . meaning the top-level source directory itself 🫶). otherwise the path is absolute.
    • build — a string with the path to the build directory, forward slashes. if it's inside the top-level build directory, the path is relative to it (and . means the top-level build directory itself). otherwise, absolute.
    • parentIndex — optional! it only shows up when the directory is not top-level. the value is an unsigned integer, a 0-based index of another entry in the main directories array — the parent directory that added this one as a subdirectory.
    • childIndexes — optional, present when the directory has subdirectories. the value is a JSON array of entries for the child directories created by the add_subdirectory() or subdirs() command. each entry is an unsigned integer 0-based index of another entry in the main directories array.
    • projectIndex — an unsigned integer 0-based index into the main projects array, telling you which build system project this directory belongs to.
    • targetIndexes — optional, present when the directory itself has build system targets (and not counting the ones that belong to subdirectories ✨). the value is a JSON array of entries for the build system targets, and each entry is an unsigned integer 0-based index into the main targets array.
    • abstractTargetIndexes — added in codemodel version 2.9. optional, present when the directory itself has abstract targets, excluding the ones belonging to subdirectories. the value is a JSON array of entries for the abstract targets, each one an unsigned integer 0-based index into the main abstractTargets array 🦋
    • minimumCMakeVersion — optional, present when a minimum required version of CMake is known for the directory. it's the <min> version given to the most local call of cmake_minimum_required(VERSION) in the directory itself or one of its ancestors. the value is a JSON object with a single member:
      • string — a string with the minimum required version, formatted like so:

<major>.<minor>[.<patch>[.<tweak>]][<suffix>]

every component is an unsigned integer, and the suffix can be literally any arbitrary string you want. iconic.

• hasInstallRule — optional, and when it's there it's a boolean true. it means the directory or one of its subdirectories contains any install() rules — i.e. whether a make install or equivalent rule is actually available. so like, yes you can install it, no cap 🔥
• jsonFile — added in codemodel version 2.3. a JSON string with a path relative to the codemodel file pointing at another JSON file containing a "codemodel" version 2 "directory" object. follow the breadcrumb trail 🍓

• projects — a JSON array of entries for the top-level project plus every sub-project defined in the build system. each (sub-)project corresponds to a source directory whose CMakeLists.txt calls the project() command with a project name that's different from its parent directory's. the first entry is the top-level project, always.

each entry is a JSON object with these members:

• name — a string with the name that was handed to the project() command.
• parentIndex — optional, present when the project is not top-level. it's an unsigned integer 0-based index of another entry in the main projects array — the parent project that added this one as a sub-project.
• childIndexes — optional, present when the project has sub-projects. a JSON array of entries for those sub-projects, each one an unsigned integer 0-based index of another entry in the main projects array.
• directoryIndexes — a JSON array of entries for the build system directories that are part of the project. the first entry is the project's top-level directory. each entry is an unsigned integer 0-based index into the main directories array 💜
• targetIndexes — optional, present when the project itself has build system targets, excluding those that belong to sub-projects. a JSON array of entries for the build system targets, each one an unsigned integer 0-based index into the main targets array.
• abstractTargetIndexes — added in codemodel version 2.9. optional, present when the project itself has abstract targets, excluding those belonging to sub-projects. a JSON array of entries for the abstract targets, each one an unsigned integer 0-based index into the main abstractTargets array 👑

• targets — a JSON array where each entry is one of the build system targets, bestie. These are the targets that get created by calls to add_executable(), add_library(), and add_custom_target(), but imported targets and interface libraries that don't generate any build rules are not invited to this party. Each entry is a JSON object with these members:
  • name — a string with the target's name. iconic.
  • id — a string that uniquely identifies the target. It matches the id field in the file that jsonFile points at, so you can always trace it back 🫶
  • directoryIndex — an unsigned integer, 0-based index into the main directories array, telling you which build system directory the target is defined in.
  • projectIndex — an unsigned integer, 0-based index into the main projects array, telling you which build system project the target is defined in.
  • jsonFile — a JSON string with a path relative to the codemodel file, pointing to another JSON file that holds a "codemodel" version 2 "target" object. it's giving breadcrumb trail ✨
• abstractTargets — added in codemodel version 2.9, so don't come looking for it in older files 💅

A JSON array of entries for targets that are not present in the build system. These are imported targets, or interface libraries created by calling add_executable() or add_library(). For interface libraries specifically, only the ones that aren't part of the build system show up in this array — interface libraries that do participate in the build system go in the targets array instead. no gatekeeping confusion, iykyk.

Each entry is a JSON object with these members:

• name — a string with the target's name.
• id — a string that uniquely identifies the target. Matches the id field in the file referenced by jsonFile.
• directoryIndex — an unsigned integer, 0-based index into the main directories array, indicating the build system directory where the target is defined.
• projectIndex — an unsigned integer, 0-based index into the main projects array, indicating the build system project where the target is defined.
• jsonFile — a JSON string with a path relative to the codemodel file, pointing to another JSON file containing a "codemodel" version 2 "target" object.

---

🦋 the "codemodel" version 2 "directory" object 🦋

Added in version 4.1: the directory object reply is described in machine-readable form by this JSON schema. slay, documentation that documents itself 💅

A codemodel "directory" object is referenced by a "codemodel" version 2 object's directories array. Each "directory" object is a JSON object with these members:

• codemodelVersion — added in codemodel version 2.9.

This specifies the codemodel version this file is part of. It will match the version field of the codemodel object kind that references this file. It's a JSON object with these members:

• major — the codemodel major version.
• minor — the codemodel minor version.

• paths — a JSON object with these members:
  • source — a string with the path to the source directory, written with forward slashes. If the directory lives inside the top-level source directory then the path is given relative to that directory (and . means the top-level source directory itself). Otherwise the path is absolute. periodt.
  • build — a string with the path to the build directory, also written with forward slashes. If the directory lives inside the top-level build directory then the path is relative to that directory (with . for the top-level build directory itself). Otherwise it's absolute.
• installers — a JSON array of entries corresponding to install() rules. Each entry is a JSON object with these members:
  • component — a string with the component selected by the corresponding install() command invocation.
  • destination — an optional member, present for specific type values below. The value is a string with the install destination path. The path may be absolute or relative to the install prefix. your call bestie 🎀
  • paths — an optional member, present for specific type values below. The value is a JSON array of entries for the paths (files or directories) to be installed. Each entry is one of:
    • A string with the path from which a file or directory is to be installed. The portion of the path not preceded by a / also specifies the path (name) to which the file or directory gets installed under the destination.
    • A JSON object with these members:
      • from — a string with the path from which a file or directory is to be installed.
      • to — a string with the path to which the file or directory is to be installed under the destination.

In both cases the paths are written with forward slashes. If the "from" path is inside the top-level directory documented by the corresponding type value, then the path is given relative to that directory. Otherwise the path is absolute. no cap.

• type — a string with the type of installation rule. The value is one of the following, and some variants hand you extra members too:
  • file — an install(FILES) or install(PROGRAMS) call. The destination and paths members are populated, with paths under the top-level source directory expressed relative to it. The isOptional member may exist. This type has no additional members.
  • directory — an install(DIRECTORY) call. The destination and paths members are populated, with paths under the top-level source directory expressed relative to it. The isOptional member may exist. This type has no additional members.
  • target — an install(TARGETS) call. The destination and paths members are populated, with paths under the top-level build directory expressed relative to it. The isOptional member may exist. This type has additional members targetId, targetIndex, targetIsImportLibrary, and targetInstallNamelink.
  • export — an install(EXPORT) call. The destination and paths members are populated, with paths under the top-level build directory expressed relative to it. The paths entries refer to files generated automatically by CMake for installation, and their actual values are considered private implementation details 🙈 so don't go building anything on top of them, fr fr. This type has additional members exportName and exportTargets.
  • script — an install(SCRIPT) call. This type has an additional member scriptFile.
  • code — an install(CODE) call. This type has no additional members.
  • importedRuntimeArtifacts — an install(IMPORTED_RUNTIME_ARTIFACTS) call. The destination member is populated. The isOptional member may exist. This type has no additional members.
  • runtimeDependencySet — an install(RUNTIME_DEPENDENCY_SET) call, or an install(TARGETS) call with RUNTIME_DEPENDENCIES. The destination member is populated. This type has additional members runtimeDependencySetName and runtimeDependencySetType.
  • fileSet — added in codemodel version 2.4.

An install(TARGETS) call with FILE_SET. The destination and paths members are populated. The isOptional member may exist. This type has additional members fileSetName, fileSetType, fileSetDirectories, and fileSetTarget.

• cxxModuleBmi — added in codemodel version 2.5.

An install(TARGETS) call with CXX_MODULES_BMI. The destination member is populated and the isOptional member may exist. This type has an additional member cxxModuleBmiTarget. modules era 💜

• isExcludeFromAll — an optional member, present with boolean value true when install() is called with the EXCLUDE_FROM_ALL option.
• isForAllComponents — an optional member, present with boolean value true when install(SCRIPT|CODE) is called with the ALL_COMPONENTS option.
• isOptional — an optional member, present with boolean value true when install() is called with the OPTIONAL option. This is allowed when type is file, directory, or target.

• targetId — optional member, only shows up when type is target 🎯. It’s a string that uniquely identifies the target to be installed, and it matches the id member of that target in the main "codemodel" object’s targets array. bestie, it’s literally the same ID, no cap.
• targetIndex — optional member, only when type is target ✨. Value is an unsigned integer 0-based index into the main "codemodel" object’s targets array for the target to be installed. index energy.
• targetIsImportLibrary — optional member, present when type is target and the installer is for a Windows DLL import library file or for an AIX linker import file 🪟. If it’s there, it has boolean value true. iconic little flag.
• targetInstallNamelink — optional member, present when type is target and the installer corresponds to a target that may use symbolic links to implement the VERSION and SOVERSION target properties 🔗. Value is a string saying how the installer should handle the symlinks: skip means the installer should skip the symlinks and install only the real file, and only means the installer should install only the symlinks and not the real file. In all cases the paths member lists what it actually installs. periodt.
• exportName — optional member, present when type is export 📦. The value is a string specifying the name of the export. simple, clean, slay.
• exportTargets — optional member, present when type is export 🎀. The value is a JSON array of entries corresponding to the targets included in the export. Each entry is a JSON object with members:
  • id — a string uniquely identifying the target. This matches the id member of the target in the main "codemodel" object’s targets array.
  • index — an unsigned integer 0-based index into the main "codemodel" object’s targets array for the target.
• runtimeDependencySetName — optional member, present when type is runtimeDependencySet and the installer was created by an install(RUNTIME_DEPENDENCY_SET) call 🌀. The value is a string specifying the name of the runtime dependency set that was installed.
• runtimeDependencySetType — optional member, present when type is runtimeDependencySet 🌈. The value is a string with one of these values:
  • library — indicates that this installer installs dependencies that are not macOS frameworks.
  • framework — indicates that this installer installs dependencies that are macOS frameworks.
• fileSetName — Added in codemodel version 2.4. Optional member, present when type is fileSet 🗂️. The value is a string with the name of the file set.
• fileSetType — Added in codemodel version 2.4. Optional member, present when type is fileSet 🧚. The value is a string with the type of the file set.

Changed in codemodel version 2.11: This field additionally accounts for SOURCES file sets. glow-up.

• fileSetDirectories — Added in codemodel version 2.4. Optional member, present when type is fileSet 📁. The value is a list of strings with the file set’s base directories, determined by genex-evaluation of HEADER_DIRS or HEADER_DIRS_<NAME>. directories but make it genex.
• fileSetTarget — Added in codemodel version 2.4. Optional member, present when type is fileSet 🎯. The value is a JSON object with members:
  • id — a string uniquely identifying the target. This matches the id member of the target in the main "codemodel" object’s targets array.
  • index — an unsigned integer 0-based index into the main "codemodel" object’s targets array for the target.
• cxxModuleBmiTarget — Added in codemodel version 2.5. Optional member, present when type is cxxModuleBmi 🧬. The value is a JSON object with members:
  • id — a string uniquely identifying the target. This matches the id member of the target in the main "codemodel" object’s targets array.
  • index — an unsigned integer 0-based index into the main "codemodel" object’s targets array for the target.
• scriptFile — optional member, present when type is script 📜. The value is a string specifying the path to the script file on disk, represented with forward slashes. If the file is inside the top-level source directory then the path is specified relative to that directory. Otherwise the path is absolute. path vibes, but precise.
• backtrace — optional member, present when a CMake language backtrace to the install() or other command invocation that added this installer is available 🧵. The value is an unsigned integer 0-based index into the backtraceGraph member’s nodes array.

backtraceGraph 🕸️

A "codemodel" version 2 "backtrace graph" whose nodes are referenced from backtrace members elsewhere in this "directory" object. iykyk.

---

🎯 "codemodel" version 2 "target" object 🎯

Added in version 4.1: The target object reply is described in machine-readable form by this JSON schema. 🧾

A codemodel "target" object is referenced by a "codemodel" version 2 object’s targets array. Each "target" object is a JSON object with members:

• codemodelVersion — Added in codemodel version 2.9. This specifies the codemodel version this file is part of. It will match the version field of the codemodel object kind that references this file. It is a JSON object with the following members:
  • major — the codemodel major version.
  • minor — the codemodel minor version.
• name — a string specifying the logical name of the target. 💖
• id — a string uniquely identifying the target. The format is unspecified and should not be interpreted by clients. no cap, don’t read into it.
• type — a string specifying the type of the target. The value is one of EXECUTABLE, STATIC_LIBRARY, SHARED_LIBRARY, MODULE_LIBRARY, OBJECT_LIBRARY, INTERFACE_LIBRARY, or UTILITY. 🏷️
• imported — Added in codemodel version 2.9. Optional member, present with boolean value true if the target is an imported target. 📥
• local — Added in codemodel version 2.9. Optional member, present with boolean value true if the target is only defined with local scope rather than being a global target. Currently, only imported targets will potentially have this field. 🏠
• abstract — Added in codemodel version 2.9. Optional member, present with boolean value true if the target is an abstract target. Abstract targets are not part of the build system — they only exist to describe dependencies or to provide usage requirements to targets that link to them. Examples include imported targets and interface libraries that have no generated sources. Abstract targets cannot be built, so they should not be presented to the user as a buildable target. 🫥

Abstract targets were not included in codemodel version 2.8 and earlier. important lore.

• symbolic — Added in codemodel version 2.9. Optional member, present with boolean value true if the target is SYMBOLIC. Symbolic targets are created by calls to add_library(INTERFACE SYMBOLIC), and are also abstract targets that are not part of the build system. 🔮

Symbolic targets were not included in codemodel version 2.8 and earlier. another 2.8 exclusion, bestie.

• backtrace — optional member, present when a CMake language backtrace to the command in the source code that created the target is available. The value is an unsigned integer 0-based index into the backtraceGraph member’s nodes array. 🧵
• folder — optional member, present when the FOLDER target property is set. The value is a JSON object with one member:
  • name — a string specifying the name of the target folder. 📂
• paths — a JSON object containing members:
  • source — a string specifying the path to the target’s source directory, represented with forward slashes. If the directory is inside the top-level source directory then the path is specified relative to that directory, with . for the top-level source directory itself. Otherwise the path is absolute.
  • build — a string specifying the path to the target’s build directory, represented with forward slashes. If the directory is inside the top-level build directory then the path is specified relative to that directory, with . for the top-level build directory itself. Otherwise the path is absolute. 🛠️
• nameOnDisk — optional member, present for executable and library targets that are linked or archived into a single primary artifact. The value is a string specifying the file name of that artifact on disk. 💾
• artifacts — optional member, present for executable and library targets that produce artifacts on disk meant for consumption by dependents. The value is a JSON array of entries corresponding to the artifacts. Each entry is a JSON object containing one member: 🧺

path

A string that says where the file lives on disk, written with forward slashes (/). ✨ If the file is inside the top-level build directory, the path is relative to that directory. Otherwise it's absolute. That's the whole rule, no cap. 💅

isGeneratorProvided

Optional member, present with boolean value true when the target is provided by CMake's build system generator instead of by a command in the source code. Like, nobody wrote this target, the generator just manifested it. 🧚

install

Optional member, present when the target has an install() rule. Bestie, this one's a whole JSON object with these members:

• prefix — a JSON object describing the installation prefix. It has exactly one member:
  • path — a string holding the value of CMAKE_INSTALL_PREFIX.
• destinations — a JSON array of entries describing install destination paths. Each entry is a JSON object with:
  • path — a string saying the install destination path. It may be absolute, or relative to the install prefix.
  • backtrace — optional member, present when a CMake language backtrace to the install() command invocation that specified this destination is available. The value is an unsigned integer, a 0-based index into the backtraceGraph member's nodes array.

launchers

Added in codemodel version 2.7. 🎀

Optional member, present on executable targets that have at least one launcher specified by the project. The value is a JSON array of entries, one per specified launcher, and each entry is a JSON object with:

• command — a string with the path to the launcher on disk, forward slashes please. If the file is inside the top-level source directory, the path is specified relative to that directory.
• arguments — optional member, present when the launcher command has arguments that come before the executable being launched. The value is a JSON array of strings, aka the arguments.
• type — a string telling you what kind of launcher it is. One of these two, periodt:
  • emulator — an emulator for the target platform when cross-compiling. Go look at the CROSSCOMPILING_EMULATOR target property.
  • test — a start program for executing tests. See the TEST_LAUNCHER target property.

link

Optional member that's present for non-imported executables and shared library targets that link into a runtime binary. The value is a JSON object whose members describe the link step. 👑

• language — a string with the language (like C, CXX, Fortran) of the toolchain used to invoke the linker.
• commandFragments — optional member, present when fragments of the link command line invocation are available. The value is a JSON array of entries with the fragments in order. Each entry is a JSON object with:
  • fragment — a string, one fragment of the link command line invocation. The value is encoded in the build system's native shell format.
  • role — a string saying what the fragment's content is for:
    • flags: link flags.
    • libraries: link library file paths or flags.
    • libraryPath: library search path flags.
    • frameworkPath: macOS framework search path flags.
  • backtrace — optional member, present when a CMake language backtrace to the target_link_libraries(), target_link_options(), or other command invocation that added this link fragment is available. Value's an unsigned integer, 0-based index into the backtraceGraph member's nodes array.
• lto — optional member, present with boolean value true when link-time optimization (a.k.a. interprocedural optimization, a.k.a. link-time code generation) is enabled. 🔥
• sysroot — optional member, present when the CMAKE_SYSROOT_LINK or CMAKE_SYSROOT variable is defined. The value is a JSON object with one member:
  • path — a string with the absolute path to the sysroot, forward slashes only.

archive

Optional member, present for non-imported static library targets. The value is a JSON object whose members describe the archive step. 🍓

• commandFragments — optional member, present when fragments of the archiver command line invocation are available. The value is a JSON array of entries describing those fragments. Each entry is a JSON object with:
  • fragment — a string, one fragment of the archiver command line invocation. The value is encoded in the build system's native shell format.
  • role — a string saying what the fragment's content is for:
    • flags: archiver flags.
• lto — optional member, present with boolean value true when link-time optimization (a.k.a. interprocedural optimization, a.k.a. link-time code generation) is enabled.

debugger

Added in codemodel version 2.8. 🌸

Optional member, present when the target has one of the following fields set. The value is a JSON object of entries matching the debugger-specific values that are set.

• workingDirectory — optional member, present when the DEBUGGER_WORKING_DIRECTORY target property is set. It'll also be present in Visual Studio Generators when VS_DEBUGGER_WORKING_DIRECTORY is set.

dependencies

Optional member, present when the target depends on other targets. Heads up: it's only present if the target is part of the build system. Imported targets aren't part of the build system, and interface libraries are only part of it if they have sources or file sets. 🙈

The value is a JSON array of entries matching the build dependencies. And it's not just the direct ones, bestie — it includes the transitive dependencies too. Everything listed builds before this target. 💯

The list reflects build graph dependencies, not necessarily link dependencies. So if there are cycles in the link dependencies of static libraries, not all the link dependencies will show up in this list of build graph dependencies. (iykyk 😭)

Each entry is a JSON object with:

• id — a string uniquely identifying the target this target depends on. It matches the main id member of that other target.
• backtrace — optional member, present when a CMake language backtrace to the add_dependencies(), target_link_libraries(), or other command invocation that created this dependency is available. The value is an unsigned integer, 0-based index into the backtraceGraph member's nodes array.

linkLibraries

Added in codemodel version 2.9. ⭐

Optional member that may be present when the target links directly to one or more other targets or libraries. It holds the items used when linking this target. Those come from the target's LINK_LIBRARIES property (evaluated non-transitively), or from the INTERFACE_LINK_LIBRARIES_DIRECT property of another target it links to directly or transitively.

Items that are only applied as usage requirements — like when they're wrapped in a $<COMPILE_ONLY:...> expression — will not be in this member. Not them. 💅

The value is a JSON array of entries. Each entry is a JSON object with:

• id — optional member, present when the library being linked is a target. It uniquely identifies the target this one has a direct link relationship with, and matches the main id member of that other target.
  • Important: the target this id identifies isn't necessarily part of the build system. It might be an imported target, or an interface library with no sources or file sets.
  • Exactly one of id or fragment will always be present. Always.
• fragment — optional member, present when the library being linked is not a target. It's a string with the raw linker command line arguments that capture the relationship — typically linking to libraries or frameworks by name rather than as a target.
  • Exactly one of id or fragment will always be present. 🫶

---

• backtrace — optional, and it only shows up when CMake actually has a language backtrace pointing at the command that created this relationship 🫶. The value? An unsigned integer, 0-based, indexing into the backtraceGraph member's nodes array. That's your little treasure map back to the guilty line of CMake code.
• fromDependency — optional, and only present when this relationship is the result of an INTERFACE_LINK_LIBRARIES_DIRECT target property living on one of this target's directly or transitively linked libraries 👀. It's a JSON object with exactly one member:
  • id — a string that uniquely identifies the target whose INTERFACE_LINK_LIBRARIES_DIRECT property created this relationship. Its value matches the main id member of that target. iykyk 💅

✨ interfaceLinkLibraries ✨

Added in codemodel version 2.9.

Optional member, may show up when the target has one or more interface link libraries 💖. It holds the items that get used when linking consumers of this target — and those items come straight from the target's INTERFACE_LINK_LIBRARIES property.

Heads up bestie: items that are only applied as usage requirements (like when they're wrapped in a $<COMPILE_ONLY:...> expression) will not be present here. They're just not that kind of item, okay? 🙈

The value is a JSON array of entries, and each entry is a JSON object with these members:

• id — optional, present when the interface link library is for a target. It uniquely identifies that target, and the value matches the main id member of that target.

Important though: the target this id identifies is not necessarily part of the build system 🫠. It could be an imported target, or an interface library with no sources or file sets. So don't assume it exists as a buildable thing.

And exactly one of id or fragment will always be present — no cap, that's the rule ✨

• fragment — optional, present when the interface link library is not for a target. It's a string holding the raw linker command line arguments to be applied to consumers of this target's interface link libraries. Typically these are linker arguments for linking to libraries or frameworks by name instead of as a target 🎀

Exactly one of id or fragment will always be present. (Yes, I said it twice. It's that important, bestie 💅)

• backtrace — optional, present when there's a CMake language backtrace to the command invocation that created this interface relationship. Value is an unsigned integer, 0-based index into the backtraceGraph member's nodes array 🔥

---

🌸 compileDependencies 🌸

Added in codemodel version 2.9.

Optional member, may be present when the target links directly to one or more other targets that might hand it usage requirements 😌. These affect how this target's sources get compiled, which is a whole different vibe from linking.

Where do these relationships come from? Two places:

• The target's LINK_LIBRARIES property, evaluated non-transitively
• The INTERFACE_LINK_LIBRARIES_DIRECT property of other targets it links to, directly or transitively

Careful: relationships that only apply linking requirements (like when they're wrapped in a $<LINK_ONLY:...> expression) will not be present in this member. Linking-only stuff stays out of the compile party 🙅‍♀️

The value is a JSON array of entries. Each entry is a JSON object with these members:

• id — a string uniquely identifying the target on which this target directly depends. It matches the main id member of that other target.

And again: the target this id points to is not necessarily part of the build system 💀 — it may be an imported target, or an interface library with no sources or file sets.

• backtrace — optional, present when there's a CMake language backtrace to the command invocation that created this relationship. Unsigned integer, 0-based index into the backtraceGraph member's nodes array 🌈
• fromDependency — optional, and only there when the relationship came from an INTERFACE_LINK_LIBRARIES_DIRECT target property on one of this target's directly or transitively linked libraries. JSON object, one member:
  • id — a string uniquely identifying the target whose INTERFACE_LINK_LIBRARIES_DIRECT property created this relationship. Value matches the main id member of that target 👑

🦋 interfaceCompileDependencies 🦋

Added in codemodel version 2.9.

Optional member, may be present when the target has one or more interface linking relationships to other targets 💜. It carries the items that affect how consumers' sources get compiled, and these relationships are defined by the target's INTERFACE_LINK_LIBRARIES property.

Same vibe check as before: relationships that only apply linking requirements (think $<LINK_ONLY:...> wrapping) will not be present in this member ⭐

The value is a JSON array of entries, each entry a JSON object with:

• id — a string uniquely identifying the target on which this target specifies an interface relationship. Matches the main id member of that other target.

And yeah, once more with feeling: that target is not necessarily part of the build system 😭 — imported target, or an interface library with no sources or file sets, both totally valid.

• backtrace — optional, present when a CMake language backtrace to the command invocation that created this relationship is available. Unsigned integer, 0-based index into the backtraceGraph member's nodes array 🌟

---

🎀 objectDependencies 🎀

Added in codemodel version 2.9.

Optional member, present when the target has one or more entries in its SOURCES property where the entry is specified using $<TARGET_OBJECTS:...>, and where no other generator expression is used inside that $<TARGET_OBJECTS:...> expression 👀. (Yes — one single genex, clean and simple. Nest another one in there and this member minds its own business.)

The value is a JSON array of entries. Each entry is a JSON object with:

• id — a string uniquely identifying the target whose objects are referred to in the $<TARGET_OBJECTS:...> expression. Matches the main id member of that other target 💖
• backtrace — optional, present when there's a CMake language backtrace to the command invocation that created this dependency. Unsigned integer, 0-based index into the backtraceGraph member's nodes array 🧚

🔥 orderDependencies 🔥

Added in codemodel version 2.9.

Optional member, present when the target has one or more direct order dependencies on other targets 😤. These can come from calls to add_dependencies() or from internal CMake processing — either way, they're order-only, not link-y.

Big difference from the dependencies array: the ZERO_CHECK target will not be included in orderDependencies. Also, this detail is only relevant for Xcode and Visual Studio generators 🫶 — so if you're not on those, this is just lore.

The value is a JSON array of entries, each one a JSON object with:

• id — a string uniquely identifying the target on which this target depends. Matches the main id member of that other target 💫
• backtrace — optional, present when there's a CMake language backtrace to the command invocation that created this dependency. Unsigned integer, 0-based index into the backtraceGraph member's nodes array 🌸

---

💅 fileSets 💅

Added in codemodel version 2.5.

An optional member, present when a target defines one or more file sets 🗂️. The value is a JSON array of entries corresponding to the target's file sets — each entry a JSON object with these members:

• name — a string specifying the name of the file set ✨
• type — a string specifying the type of the file set. Peep the file set types supported by target_sources() for the full menu 🍓
• visibility — a string specifying the visibility of the file set; one of PUBLIC, PRIVATE, or INTERFACE. Pick your fighter 💅
• baseDirectories — a JSON array of strings, each specifying a base directory containing sources in the file set. If the directory is inside the top-level source directory, the path is relative to that directory. Otherwise the path is absolute 📁

🌈 sources 🌈

A JSON array of entries corresponding to the target's source files 💜. Each entry is a JSON object with these members:

• path — a string specifying the path to the source file on disk, written with forward slashes 🫶. If the file is inside the top-level source directory, the path is relative to that directory. Otherwise it's absolute. (Same rule as baseDirectories — consistency is iconic.)
• compileGroupIndex — optional, present when the source is actually compiled 🔨. The value is an unsigned integer, 0-based index into the compileGroups array. Go look it up, bestie, the whole story is in there 👑

sourceGroupIndex

Optional member — it's there when the source is part of a source group, either because someone called the source_group() command or just by default. The value is an unsigned integer, 0-based, and it indexes into the sourceGroups array. 💅

isGenerated

Optional member, present with boolean value true when the source is GENERATED (as in the <prop_sf:GENERATED> property). ✨

fileSetIndex

Added in codemodel version 2.5.

Deprecated since version 4.4: use the fileSetIndexes field instead — that one's an array, and it actually accounts for sources assigned to multiple file sets. 😭

Optional member that's present when the source is part of a file set. The value is an unsigned integer 0-based index into the fileSets array, pointing at the file set to which the source was most recently added.

fileSetIndexes

Added in codemodel version 2.11.

Optional member, present when the source is part of at least one file set; see also policy CMP0211. The value is an array of unsigned integer 0-based indexes into the fileSets array. 🦋

backtrace

Deprecated since version 4.4: use the backtraces field instead — it's an array, and it accounts for sources added to multiple file sets over multiple command invocations.

Optional member that's present when a CMake language backtrace to the target_sources(), add_executable(), add_library(), add_custom_target(), or other command invocation that added this source to the target is available. The value is an unsigned integer 0-based index into the backtraceGraph member's nodes array.

backtraces

Added in codemodel version 2.11.

Optional member that's present when CMake language backtraces to the target_sources(), add_executable(), add_library(), add_custom_target(), or other command invocation that added this source to the target are available. And listen — it's completely possible for a single source file to be included in multiple target_sources() invocations, each naming it in a different file set (see also policy CMP0211), so yeah, there could be multiple backtraces. The value is a JSON array where each entry is an unsigned integer 0-based index into the backtraceGraph member's nodes array. 👑

---

interfaceSources

Added in codemodel version 2.10.

An optional member that's present when a target defines one or more interface sources. The value is a JSON array of entries, one per interface source file of the target. Each entry is a JSON object with these members:

• path — a string, the path to the source file on disk, written with forward slashes. If the file is inside the top-level source directory, the path is relative to that directory; otherwise it's absolute. 🍓
• sourceGroupIndex — optional member, present when the source is part of a source group either via the source_group() command or by default. Unsigned integer 0-based index into the sourceGroups array.
• isGenerated — optional member, present with boolean value true if the source is GENERATED.
• fileSetIndex — added in codemodel version 2.5; deprecated since version 4.4: use the fileSetIndexes field instead, which is an array and accounts for sources assigned to multiple file sets. Optional member, present when the source is part of a file set. Unsigned integer 0-based index into the fileSets array representing the file set to which the source was most recently added.
• fileSetIndexes — added in codemodel version 2.11. Optional member, present when the source is part of at least one file set; see also policy CMP0211. The value is an array of unsigned integer 0-based indexes into the fileSets array.

sourceGroups

Optional member that's present when sources are grouped together by the source_group() command or by default. The value is a JSON array of entries, one per group. Each entry is a JSON object with these members:

• name — a string, the name of the source group.
• sourceIndexes — a JSON array listing the sources that belong to the group. Each entry is an unsigned integer 0-based index into the main sources array for the target.
• interfaceSourceIndexes — added in codemodel version 2.10. Optional member, present when at least one interface source file is part of the source group. The value is a JSON array listing the interface sources belonging to the group, each entry an unsigned integer 0-based index into the main interfaceSources array for the target. 💜

compileGroups

Optional member that's present when the target has sources that compile. The value is a JSON array of entries, one per group of sources that all compile with the same settings. Each entry is a JSON object with these members:

• sourceIndexes — a JSON array listing the sources belonging to the group. Each entry is an unsigned integer 0-based index into the main sources array for the target.
• language — a string specifying the language (e.g. C, CXX, Fortran) of the toolchain used to compile the source file.
• languageStandard — added in codemodel version 2.2. Optional member, present when the language standard is set explicitly (e.g. via CXX_STANDARD) or implicitly by compile features. Each entry is a JSON object with two members:
  • backtraces — optional member, present when a CMake language backtrace to the <LANG>_STANDARD setting is available. If the language standard was set implicitly by compile features, those are used as the backtrace(s). Multiple compile features can require the same language standard, so there could be multiple backtraces. The value is a JSON array where each entry is an unsigned integer 0-based index into the backtraceGraph member's nodes array.
  • standard — string representing the language standard.
• compileCommandFragments — optional member, present when fragments of the compiler command line invocation are available. The value is a JSON array of entries specifying ordered fragments. Each entry is a JSON object with one member:
  • fragment — a string specifying a fragment of the compile command line invocation. The value is encoded in the build system's native shell format.
  • backtrace — optional member, present when a CMake language backtrace to the command invocation that added this fragment is available. The value is an unsigned integer 0-based index into the backtraceGraph member's nodes array.
• includes — optional member, present when there are include directories. The value is a JSON array with an entry for each directory. Each entry is a JSON object with these members:
  • path — a string specifying the path to the include directory, represented with forward slashes.
  • isSystem — optional member, present with boolean value true if the include directory is marked as a system include directory.
  • backtrace — optional member, present when a CMake language backtrace to the target_include_directories() or other command invocation that added this include directory is available. The value is an unsigned integer 0-based index into the backtraceGraph member's nodes array.
• frameworks — added in codemodel version 2.6. Optional member, present when, on Apple platforms, there are frameworks. The value is a JSON array with an entry for each directory. Each entry is a JSON object with these members:
  • path — a string specifying the path to the framework directory, represented with forward slashes.
  • isSystem — optional member, present with boolean value true if the framework is marked as a system one.

backtrace

Optional member — it shows up when there's a CMake language backtrace pointing at the target_link_libraries() call (or whatever other command invocation) that added this framework. The value? An unsigned integer, a 0-based index into the backtraceGraph member's nodes array. ✨

precompileHeaders

Added in codemodel version 2.1.

Optional member, present when target_precompile_headers() or other command invocations set PRECOMPILE_HEADERS on the target. The value is a JSON array with one entry per header, and every entry is a JSON object with these members:

• header — the full path to the precompile header file.
• backtrace — optional member, present when there's a CMake language backtrace to the target_precompile_headers() call (or other command invocation) that added this precompiled header. The value is an unsigned integer, a 0-based index into the backtraceGraph member's nodes array.

defines

Optional member, present when there are preprocessor definitions. The value is a JSON array with one entry per definition, and each entry is a JSON object with these members:

• define — a string giving the preprocessor definition in the format <name>[=<value>], e.g. DEF or DEF=1.
• backtrace — optional member, present when there's a CMake language backtrace to the target_compile_definitions() call (or other command invocation) that added this preprocessor definition. The value is an unsigned integer, a 0-based index into the backtraceGraph member's nodes array.

sysroot

Optional member, present when the CMAKE_SYSROOT_COMPILE or CMAKE_SYSROOT variable is defined. The value is a JSON object with exactly one member:

• path — a string giving the absolute path to the sysroot, written with forward slashes.

backtraceGraph

A "codemodel" version 2 "backtrace graph" whose nodes get referenced from backtrace members elsewhere in this "target" object. 🫶

---

🧚 "codemodel" version 2 "backtrace graph"

The backtraceGraph member of a "codemodel" version 2 "directory" object (or of a "codemodel" version 2 "target" object, bestie — both do it) is a JSON object describing a graph of backtraces. Its nodes are referenced from backtrace members elsewhere in the containing object. The members of this backtrace graph object are:

• nodes — a JSON array listing the nodes in the backtrace graph. Each entry is a JSON object with these members:
  • file — an unsigned integer, 0-based index into the backtrace files array.
  • line — optional member, present when the node represents a line within the file. The value is an unsigned integer, a 1-based line number.
  • command — optional member, present when the node represents a command invocation within the file. The value is an unsigned integer, 0-based index into the backtrace commands array.
  • parent — optional member, present when the node is not the bottom of the call stack. The value is an unsigned integer, a 0-based index of another entry in the backtrace nodes array.
• commands — a JSON array listing command names referenced by backtrace nodes. Each entry is a string giving a command name.
• files — a JSON array listing CMake language files referenced by backtrace nodes. Each entry is a string giving the path to a file, written with forward slashes. If the file lives inside the top-level source directory, the path is relative to that directory; otherwise it's absolute. 💅

---

✨ Object Kind configureLog ✨

Added in version 3.26.

The configureLog object kind describes the location and the contents of a cmake-configure-log(7) file. Iconic behaviour, honestly.

There is only one configureLog object major version — version 1.

Added in version 4.1: the configureLog object kind reply is described in machine-readable form by this JSON schema.

"configureLog" version 1

configureLog object version 1 is a JSON object:

{
  "kind": "configureLog",
  "version": { "major": 1, "minor": 0 },
  "path": "/path/to/top-level-build-dir/CMakeFiles/CMakeConfigureLog.yaml",
  "eventKindNames": [ "try_compile-v1", "try_run-v1" ]
}

The members specific to configureLog objects are:

• path — a string giving the path to the configure log file. Clients must read the log file from this path, which may be different from the path documented by cmake-configure-log(7). Heads up though: the log file may not exist at all if no events are logged. 🙈
• eventKindNames — a JSON array whose entries are each a JSON string naming one of the cmake-configure-log(7) versioned event kinds. At most one version of each configure log event kind will be listed. And even though the configure log may contain other (versioned) event kinds, clients must ignore the ones that aren't listed in this field. Fr fr, ignore them.

---

🎀 Object Kind cache 🎀

The cache object kind lists cache entries — these are the Variables stored in the persistent cache (CMakeCache.txt) for the build tree. 💖

There is only one cache object major version, version 2. Version 1 straight-up does not exist, specifically to avoid confusion with the version 1 from cmake-server(7) mode. Not me skipping a number for my own sanity.

Added in version 4.1: the cache object kind reply is described in machine-readable form by this JSON schema.

"cache" version 2

cache object version 2 is a JSON object:

{
  "kind": "cache",
  "version": { "major": 2, "minor": 0 },
  "entries": [
    {
      "name": "BUILD_SHARED_LIBS",
      "value": "ON",
      "type": "BOOL",
      "properties": [
        {
          "name": "HELPSTRING",
          "value": "Build shared libraries"
        }
      ]
    },
    {
      "name": "CMAKE_GENERATOR",
      "value": "Unix Makefiles",
      "type": "INTERNAL",
      "properties": [
        {
          "name": "HELPSTRING",
          "value": "Name of generator."
        }
      ]
    }
  ]
}

The members specific to cache objects are:

• entries — a JSON array whose entries are each a JSON object specifying a cache entry. The members of each entry are:
  • name — a string giving the name of the entry.
  • value — a string giving the value of the entry.
  • type — a string giving the type of the entry, the one cmake-gui(1) uses to choose a widget for editing. 🎀
  • properties — a JSON array of entries specifying the associated cache entry properties. Each entry is a JSON object containing these members:
    • name — a string giving the name of the cache entry property.
    • value — a string giving the value of the cache entry property.

---

🦋 Object Kind cmakeFiles 🦋

The cmakeFiles object kind lists files that CMake uses while configuring and generating the build system — including the CMakeLists.txt files and the included .cmake files. The way it's just cataloguing everything? Obsessed.

There is only one cmakeFiles object major version, version 1.

Added in version 4.1: the cmakeFiles object kind reply is described in machine-readable form by this JSON schema.

"cmakeFiles" version 1

cmakeFiles object version 1 is a JSON object:

{
  "kind": "cmakeFiles",
  "version": { "major": 1, "minor": 1 },
  "paths": {
    "build": "/path/to/top-level-build-dir",
    "source": "/path/to/top-level-source-dir"
  },
  "inputs": [
    {
      "path": "CMakeLists.txt"
    },
    {
      "isGenerated": true,
      "path": "/path/to/top-level-build-dir/.../CMakeSystem.cmake"
    },
    {
      "isExternal": true,
      "path": "/path/to/external/third-party/module.cmake"
    },
    {
      "isCMake": true,
      "isExternal": true,
      "path": "/path/to/cmake/Modules/CMakeGenericSystem.cmake"
    }
  ],
  "globsDependent": [
    {
      "expression": "src/*.cxx",
      "recurse": true,
      "files": [
        "src/foo.cxx",
        "src/bar.cxx"
      ]
    }
  ]
}

The members specific to cmakeFiles objects are:

• paths — a JSON object containing these members:
  • source — a string giving the absolute path to the top-level source directory, written with forward slashes.
  • build — a string giving the absolute path to the top-level build directory, written with forward slashes.
• inputs — a JSON array whose entries are each a JSON object specifying an input file that CMake uses when configuring and generating the build system. The members of each entry are:
  • path — a string giving the path to an input file to CMake, written with forward slashes. If the file lives inside the top-level source directory, the path is relative to that directory; otherwise the path is absolute.
• isGenerated — optional member, and it shows up with the boolean value true when the path points at a file that lives under the top-level build directory and the build is out-of-source. Heads up bestie: this member is not available on in-source builds. 🙈
• isExternal — optional member, present with boolean value true when the path specifies a file that's not under the top-level source or build directories.
• isCMake — optional member, present with boolean value true if the path specifies a file that's chillin' inside the CMake installation itself.

✨ globsDependent ✨

Added in cmakeFiles version 1.1.

Optional member, and it's only there when the project calls file(GLOB) or file(GLOB_RECURSE) with the CONFIGURE_DEPENDS option. Its value is a JSON array of JSON objects, each one specifying a globbing expression plus the list of paths it matched. And here's the ✨consequence✨: if the globbing expression no longer matches that same list of paths, CMake considers the build system to be out of date. It will be judging you. 💅

The members of each entry are:

• expression — a string specifying the globbing expression.
• recurse — optional member, present with boolean value true if the entry corresponds to a file(GLOB_RECURSE) call. Otherwise the entry corresponds to a file(GLOB) call.
• listDirectories — optional member, present with boolean value true if file(GLOB) was called without LIST_DIRECTORIES false, or if file(GLOB_RECURSE) was called with LIST_DIRECTORIES true.
• followSymlinks — optional member, present with boolean value true if file(GLOB) was called with the FOLLOW_SYMLINKS option.
• relative — optional member, present if file(GLOB) was called with the RELATIVE <path> option. The value is a string containing the <path> that was given.
• paths — a JSON array of strings specifying the paths matched by the call to file(GLOB) or file(GLOB_RECURSE).

---

🌈 Object Kind "toolchains" 🌈

Okay so the toolchains object kind lists properties of the toolchains used during the build. These include the language, compiler path, ID, and version. It's giving full compiler résumé. 👑

There is only one toolchains object major version, version 1.

Added in version 4.1: the toolchains object kind reply is described in machine-readable form by this JSON schema.

🛠️ "toolchains" version 1

toolchains object version 1 is a JSON object:

{
  "kind": "toolchains",
  "version": { "major": 1, "minor": 1 },
  "toolchains": [
    {
      "language": "C",
      "compiler": {
        "path": "/usr/bin/cc",
        "commandFragment": "--config x86_64-linux-gnu.cfg",
        "id": "GNU",
        "version": "9.3.0",
        "implicit": {
          "includeDirectories": [
            "/usr/lib/gcc/x86_64-linux-gnu/9/include",
            "/usr/local/include",
            "/usr/include/x86_64-linux-gnu",
            "/usr/include"
          ],
          "linkDirectories": [
            "/usr/lib/gcc/x86_64-linux-gnu/9",
            "/usr/lib/x86_64-linux-gnu",
            "/usr/lib",
            "/lib/x86_64-linux-gnu",
            "/lib"
          ],
          "linkFrameworkDirectories": [],
          "linkLibraries": [ "gcc", "gcc_s", "c", "gcc", "gcc_s" ]
        }
      },
      "sourceFileExtensions": [ "c", "m" ]
    },
    {
      "language": "CXX",
      "compiler": {
        "path": "/usr/bin/c++",
        "id": "GNU",
        "version": "9.3.0",
        "implicit": {
          "includeDirectories": [
            "/usr/include/c++/9",
            "/usr/include/x86_64-linux-gnu/c++/9",
            "/usr/include/c++/9/backward",
            "/usr/lib/gcc/x86_64-linux-gnu/9/include",
            "/usr/local/include",
            "/usr/include/x86_64-linux-gnu",
            "/usr/include"
          ],
          "linkDirectories": [
            "/usr/lib/gcc/x86_64-linux-gnu/9",
            "/usr/lib/x86_64-linux-gnu",
            "/usr/lib",
            "/lib/x86_64-linux-gnu",
            "/lib"
          ],
          "linkFrameworkDirectories": [],
          "linkLibraries": [
            "stdc++", "m", "gcc_s", "gcc", "c", "gcc_s", "gcc"
          ]
        }
      },
      "sourceFileExtensions": [
        "C", "M", "c++", "cc", "cpp", "cxx", "mm", "CPP"
      ]
    }
  ]
}

The members specific to toolchains objects are:

• toolchains — a JSON array whose entries are each a JSON object specifying a toolchain associated with a particular language. The members of each entry are:
  • language — a JSON string specifying the toolchain language, like C or CXX. Language names are the same as language names that can be passed to the project() command. Because CMake only supports a single toolchain per language, this field can be used as a key. 🔑
  • compiler — a JSON object containing members:
    • path — optional member, present when the CMAKE_<LANG>_COMPILER variable is defined for the current language. Its value is a JSON string holding the path to the compiler.
    • commandFragment — added in toolchains version 1.1. Optional member, present when the CMAKE_<LANG>_COMPILER variable is a list containing multiple elements, or when the CC or similar environment variable contains command line arguments after the compiler executable. Its value is a JSON string holding the second and further elements (mandatory arguments to the compiler) as a command line fragment.
    • id — optional member, present when the CMAKE_<LANG>_COMPILER_ID variable is defined for the current language. Its value is a JSON string holding the ID (GNU, MSVC, etc.) of the compiler.
    • version — optional member, present when the CMAKE_<LANG>_COMPILER_VERSION variable is defined for the current language. Its value is a JSON string holding the version of the compiler.
    • target — optional member, present when the CMAKE_<LANG>_COMPILER_TARGET variable is defined for the current language. Its value is a JSON string holding the cross-compiling target of the compiler.
    • implicit — a JSON object containing members:
      • includeDirectories — optional member, present when the CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES variable is defined for the current language. Its value is a JSON array of JSON strings where each string holds a path to an implicit include directory for the compiler.
      • linkDirectories — optional member, present when the CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES variable is defined for the current language. Its value is a JSON array of JSON strings where each string holds a path to an implicit link directory for the compiler.
      • linkFrameworkDirectories — optional member, present when the CMAKE_<LANG>_IMPLICIT_LINK_FRAMEWORK_DIRECTORIES variable is defined for the current language. Its value is a JSON array of JSON strings where each string holds a path to an implicit link framework directory for the compiler.
      • linkLibraries — optional member, present when the CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES variable is defined for the current language. Its value is a JSON array of JSON strings where each string holds a path to an implicit link library for the compiler.
  • sourceFileExtensions — optional member, present when the CMAKE_<LANG>_SOURCE_FILE_EXTENSIONS variable is defined for the current language. Its value is a JSON array of JSON strings where each string holds a file extension (without the leading dot) for the language. 🍓

---

🎀 Copyright 🎀

2000-2026 Kitware, Inc. and Contributors

---

And that's the whole page bestie, we literally made it to the end 🫶💖 This was CMAKE-FILE-API(7) from source/version 4.4.5, dated Oct 28, 2026 — go forth and query that file API, you absolute icon. 🌟