cmake-file-api
CMake File-Based API
- Provided by: cmake-data (Version: 4.2.3-2ubuntu2)
- Source: cmake
- Report a bug
CMake File-Based API
CMake provides a file-based API that clients may use to get semantic information about the buildsystems CMake generates. Clients may use the API by writing query files to a specific location in a build tree to request zero or more Object Kinds. When CMake generates the buildsystem in that build tree it will read the query files and write reply files for the client to read.
The file-based API uses a <build>/.cmake/api/ directory at the top of a build tree. The API is versioned to support changes to the layout of files within the API directory. API file layout versioning is orthogonal to the versioning of Object Kinds used in replies. This version of CMake supports only 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:cmake_file_api> command.
API v1 is housed in the <build>/.cmake/api/v1/ directory. It has the following subdirectories:
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. Clients may optionally create the reply/ directory at any time and monitor it for the appearance of a new reply index. CMake owns all reply files. Clients must never remove them.
Added in version 3.31: Users can add query files to api/v1/query inside the CMAKE_CONFIG_DIR <#envvar:CMAKE_CONFIG_DIR> to create user-wide queries for all CMake projects.
Shared stateless query files allow clients to share requests for major versions of the Object Kinds and get all requested versions recognized by the CMake that runs.
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.
Client stateless query files allow clients to 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.
Files of this form are stateless queries owned by the client <client>. The owning client may remove them at any time.
Stateful query files allow clients to request a list of versions of each of the Object Kinds and get only the most recent version recognized by the CMake that runs.
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. When a given client installation is 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.
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:
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.
Other query.json top-level members are reserved for future use. If present they are ignored for forward compatibility.
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 is given a new name and any old one is deleted. During the short time between these steps there may be multiple index files present; the one with the largest name in lexicographic order is the current index file.
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:
After reading the reply index file, clients may read the other v1 Reply Files it references.
The reply index file represents each reference to another reply file using a JSON object with members:
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 of a v1 Reply Index File, with the following exceptions:
Index entries for other object kinds contain an error message instead of a v1 Reply File Reference.
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 follow references to the names of the desired response objects.
Reply files (including the index file) will never be replaced by files of the same name but different content. This allows a client to read the files concurrently with a running CMake that may generate a new reply. However, after generating a new reply CMake will attempt to remove reply files from previous runs that it did not just write. If a client attempts to read a reply file referenced by the index but finds the file missing, that means a concurrent CMake has generated a new reply. The client may simply start again by reading the new reply index file.
The CMake file-based API reports semantic information about the build system using the following kinds of JSON objects. Each kind of object is versioned independently using semantic versioning with major and minor components. Every kind of object has the form:
{
"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 integer components of the object kind's version. Additional top-level members are specific to each object kind.
The codemodel object kind describes the build system structure as modeled by CMake.
There is only one codemodel object major version, version 2. Version 1 does not exist to avoid confusion with that from cmake-server(7) <#manual:cmake-server(7)> mode.
Added in version 4.1: The codemodel object kind reply is described in machine-readable form by this JSON schema.
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>"
}
]
}
]
}
The members specific to codemodel objects are:
This field was added in codemodel version 2.9.
<major>.<minor>[.<patch>[.<tweak>]][<suffix>]
Each component is an unsigned integer and the suffix may be an arbitrary string.
This field was added in codemodel version 2.3.
Each entry is a JSON object containing members:
This field was added in codemodel version 2.9.
Each entry is a JSON object containing members:
This field was added in codemodel version 2.9.
Added in version 4.1: The directory object reply is described in machine-readable form by this JSON schema.
A codemodel "directory" object is referenced by a "codemodel" version 2 object's directories array. Each "directory" object is a JSON object with members:
This field was added in codemodel version 2.9.
In both cases the paths are represented with forward slashes. If the "from" path is inside the top-level directory documented by the corresponding type value, then the path is specified relative to that directory. Otherwise the path is absolute.
This type was added in codemodel version 2.4.
This type was added in codemodel version 2.5.
This field was added in codemodel version 2.4.
This field was added in codemodel version 2.4.
This field was added in codemodel version 2.4.
This field was added in codemodel version 2.4.
This field was added in codemodel version 2.5.
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:
This field was added in codemodel version 2.9.
This field was added in codemodel version 2.9.
This field was added in codemodel version 2.9.
This field was added in codemodel version 2.9. Abstract targets were not included in codemodel version 2.8 and earlier.
This field was added in codemodel version 2.9. Symbolic targets were not included in codemodel version 2.8 and earlier.
This field was added in codemodel version 2.7.
This field was added in codemodel version 2.8.
This field was added in codemodel version 2.8.
The value is a JSON array of entries corresponding to the build dependencies. The array includes not just direct dependencies, but also transitive dependencies. All listed targets will build before this one.
The list of dependencies reflects the build graph dependencies, not necessarily the link dependencies. If there are cycles in the link dependencies of static libraries, not all link dependencies will be reflected in this list of build graph dependencies.
Each entry is a JSON object with members:
Items that are only applied as usage requirements (such as being wrapped in a $<COMPILE_ONLY:...> <#genex:COMPILE_ONLY> expression) will not be present in this member.
The value is a JSON array of entries. Each entry is a JSON object with members:
The target this id identifies is not necessarily part of the build system. It may be an imported target or an interface library with no sources or file sets.
Exactly one of id or fragment will always be present.
Exactly one of id or fragment will always be present.
This field was added in codemodel version 2.9.
Items that are only applied as usage requirements (such as being wrapped in a $<COMPILE_ONLY:...> <#genex:COMPILE_ONLY> expression) will not be present in this member.
The value is a JSON array of entries. Each entry is a JSON object with members:
The target this id identifies is not necessarily part of the build system. It may be an imported target or an interface library with no sources or file sets.
Exactly one of id or fragment will always be present.
Exactly one of id or fragment will always be present.
This field was added in codemodel version 2.9.
Relationships that only apply linking requirements (such as being wrapped in a $<LINK_ONLY:...> <#genex:LINK_ONLY> expression) will not be present in this member.
The value is a JSON array of entries. Each entry is a JSON object with members:
The target this id identifies is not necessarily part of the build system. It may be an imported target or an interface library with no sources or file sets.
This field was added in codemodel version 2.9.
Relationships that only apply linking requirements (such as being wrapped in a $<LINK_ONLY:...> <#genex:LINK_ONLY> expression) will not be present in this member.
The value is a JSON array of entries. Each entry is a JSON object with members:
The target this id identifies is not necessarily part of the build system. It may be an imported target or an interface library with no sources or file sets.
This field was added in codemodel version 2.9.
The value is a JSON array of entries. Each entry is a JSON object with members:
This field was added in codemodel version 2.9.
The value is a JSON array of entries. Each entry is a JSON object with members:
This field was added in codemodel version 2.9.
This field was added in codemodel version 2.5.
This field was added in codemodel version 2.5.
This field was added in codemodel version 2.2.
This field was added in codemodel version 2.6.
This field was added in codemodel version 2.1.
The backtraceGraph member of a "codemodel" version 2 "directory" object, or "codemodel" version 2 "target" object is a JSON object describing a graph of backtraces. Its nodes are referenced from backtrace members elsewhere in the containing object. The backtrace graph object members are:
Added in version 3.26.
The configureLog object kind describes the location and contents of a cmake-configure-log(7) <#manual:cmake-configure-log(7)> file.
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 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:
The cache object kind lists cache entries. These are the Variables <#cmake-language-variables> stored in the persistent cache (CMakeCache.txt) for the build tree.
There is only one cache object major version, version 2. Version 1 does not exist to avoid confusion with that from cmake-server(7) <#manual:cmake-server(7)> mode.
Added in version 4.1: The cache object kind reply is described in machine-readable form by this JSON schema.
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:
The cmakeFiles object kind lists files used by CMake while configuring and generating the build system. These include the CMakeLists.txt files as well as included .cmake files.
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 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:
This field was added in cmakeFiles version 1.1.
The members of each entry are:
The toolchains object kind lists properties of the toolchains used during the build. These include the language, compiler path, ID, and version.
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 object version 1 is a JSON object:
{
"kind": "toolchains",
"version": { "major": 1, "minor": 0 },
"toolchains": [
{
"language": "C",
"compiler": {
"path": "/usr/bin/cc",
"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:
2000-2025 Kitware, Inc. and Contributors