cmake-presets.7.rst 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375
  1. .. cmake-manual-description: CMakePresets.json
  2. cmake-presets(7)
  3. ****************
  4. .. only:: html
  5. .. contents::
  6. Introduction
  7. ============
  8. One problem that CMake users often face is sharing settings with other people
  9. for common ways to configure a project. This may be done to support CI builds,
  10. or for users who frequently use the same build. CMake supports two files,
  11. ``CMakePresets.json`` and ``CMakeUserPresets.json``, that allow users to
  12. specify common configure options and share them with others.
  13. ``CMakePresets.json`` and ``CMakeUserPresets.json`` live in the project's root
  14. directory. They both have exactly the same format, and both are optional
  15. (though at least one must be present if ``--preset`` is specified.)
  16. ``CMakePresets.json`` is meant to save project-wide builds, while
  17. ``CMakeUserPresets.json`` is meant for developers to save their own local
  18. builds. ``CMakePresets.json`` may be checked into a version control system, and
  19. ``CMakeUserPresets.json`` should NOT be checked in. For example, if a project
  20. is using Git, ``CMakePresets.json`` may be tracked, and
  21. ``CMakeUserPresets.json`` should be added to the ``.gitignore``.
  22. Format
  23. ======
  24. The files are a JSON document with an object as the root:
  25. .. literalinclude:: presets/example.json
  26. :language: json
  27. The root object recognizes the following fields:
  28. ``version``
  29. A required integer representing the version of the JSON schema. Currently,
  30. the only supported version is 1.
  31. ``cmakeMinimumRequired``
  32. An optional object representing the minimum version of CMake needed to
  33. build this project. This object consists of the following fields:
  34. ``major``
  35. An optional integer representing the major version.
  36. ``minor``
  37. An optional integer representing the minor version.
  38. ``patch``
  39. An optional integer representing the patch version.
  40. ``vendor``
  41. An optional map containing vendor-specific information. CMake does not
  42. interpret the contents of this field except to verify that it is a map if
  43. it does exist. However, the keys should be a vendor-specific domain name
  44. followed by a ``/``-separated path. For example, the Example IDE 1.0 could
  45. use ``example.com/ExampleIDE/1.0``. The value of each field can be anything
  46. desired by the vendor, though will typically be a map.
  47. ``configurePresets``
  48. An optional array of `Configure Preset`_ objects.
  49. Configure Preset
  50. ^^^^^^^^^^^^^^^^
  51. Each entry of the ``configurePresets`` array is a JSON object
  52. that may contain the following fields:
  53. ``name``
  54. A required string representing the machine-friendly name of the preset.
  55. This identifier is used in the ``--preset`` argument. There must not be
  56. two presets in the union of ``CMakePresets.json`` and
  57. ``CMakeUserPresets.json`` in the same directory with the same name.
  58. ``hidden``
  59. An optional boolean specifying whether or not a preset should be hidden.
  60. If a preset is hidden, it cannot be used in the ``--preset=`` argument,
  61. will not show up in the :manual:`CMake GUI <cmake-gui(1)>`, and does not
  62. have to have a valid ``generator`` or ``binaryDir``, even from
  63. inheritance. ``hidden`` presets are intended to be used as a base for
  64. other presets to inherit via the ``inherits`` field.
  65. ``inherits``
  66. An optional array of strings representing the names of presets to inherit
  67. from. The preset will inherit all of the fields from the ``inherits``
  68. presets by default (except ``name``, ``hidden``, ``inherits``,
  69. ``description``, and ``displayName``), but can override them as
  70. desired. If multiple ``inherits`` presets provide conflicting values for
  71. the same field, the earlier preset in the ``inherits`` list will be
  72. preferred. Presets in ``CMakePresets.json`` may not inherit from presets
  73. in ``CMakeUserPresets.json``.
  74. This field can also be a string, which is equivalent to an array
  75. containing one string.
  76. ``vendor``
  77. An optional map containing vendor-specific information. CMake does not
  78. interpret the contents of this field except to verify that it is a map
  79. if it does exist. However, it should follow the same conventions as the
  80. root-level ``vendor`` field. If vendors use their own per-preset
  81. ``vendor`` field, they should implement inheritance in a sensible manner
  82. when appropriate.
  83. ``displayName``
  84. An optional string with a human-friendly name of the preset.
  85. ``description``
  86. An optional string with a human-friendly description of the preset.
  87. ``generator``
  88. An optional string representing the generator to use for the preset. If
  89. ``generator`` is not specified, it must be inherited from the
  90. ``inherits`` preset (unless this preset is ``hidden``).
  91. Note that for Visual Studio generators, unlike in the command line ``-G``
  92. argument, you cannot include the platform name in the generator name. Use
  93. the ``architecture`` field instead.
  94. ``architecture``, ``toolset``
  95. Optional fields representing the platform and toolset, respectively, for
  96. generators that support them. Each may be either a string or an object
  97. with the following fields:
  98. ``value``
  99. An optional string representing the value.
  100. ``strategy``
  101. An optional string telling CMake how to handle the ``architecture`` or
  102. ``toolset`` field. Valid values are:
  103. ``"set"``
  104. Set the respective value. This will result in an error for generators
  105. that do not support the respective field.
  106. ``"external"``
  107. Do not set the value, even if the generator supports it. This is
  108. useful if, for example, a preset uses the Ninja generator, and an IDE
  109. knows how to set up the Visual C++ environment from the
  110. ``architecture`` and ``toolset`` fields. In that case, CMake will
  111. ignore the field, but the IDE can use them to set up the environment
  112. before invoking CMake.
  113. ``binaryDir``
  114. An optional string representing the path to the output binary directory.
  115. This field supports `macro expansion`_. If a relative path is specified,
  116. it is calculated relative to the source directory. If ``binaryDir`` is not
  117. specified, it must be inherited from the ``inherits`` preset (unless this
  118. preset is ``hidden``).
  119. ``cmakeExecutable``
  120. An optional string representing the path to the CMake executable to use
  121. for this preset. This is reserved for use by IDEs, and is not used by
  122. CMake itself. IDEs that use this field should expand any macros in it.
  123. ``cacheVariables``
  124. An optional map of cache variables. The key is the variable name (which
  125. may not be an empty string), and the value is either ``null``, a boolean
  126. (which is equivalent to a value of ``"TRUE"`` or ``"FALSE"`` and a type
  127. of ``BOOL``), a string representing the value of the variable (which
  128. supports `macro expansion`_), or an object with the following fields:
  129. ``type``
  130. An optional string representing the type of the variable.
  131. ``value``
  132. A required string or boolean representing the value of the variable.
  133. A boolean is equivalent to ``"TRUE"`` or ``"FALSE"``. This field
  134. supports `macro expansion`_.
  135. Cache variables are inherited through the ``inherits`` field, and the
  136. preset's variables will be the union of its own ``cacheVariables`` and
  137. the ``cacheVariables`` from all its parents. If multiple presets in this
  138. union define the same variable, the standard rules of ``inherits`` are
  139. applied. Setting a variable to ``null`` causes it to not be set, even if
  140. a value was inherited from another preset.
  141. ``environment``
  142. An optional map of environment variables. The key is the variable name
  143. (which may not be an empty string), and the value is either ``null`` or
  144. a string representing the value of the variable. Each variable is set
  145. regardless of whether or not a value was given to it by the process's
  146. environment. This field supports `macro expansion`_, and environment
  147. variables in this map may reference each other, and may be listed in any
  148. order, as long as such references do not cause a cycle (for example,
  149. if ``ENV_1`` is ``$env{ENV_2}``, ``ENV_2`` may not be ``$env{ENV_1}``.)
  150. Environment variables are inherited through the ``inherits`` field, and
  151. the preset's environment will be the union of its own ``environment`` and
  152. the ``environment`` from all its parents. If multiple presets in this
  153. union define the same variable, the standard rules of ``inherits`` are
  154. applied. Setting a variable to ``null`` causes it to not be set, even if
  155. a value was inherited from another preset.
  156. ``warnings``
  157. An optional object specifying the warnings to enable. The object may
  158. contain the following fields:
  159. ``dev``
  160. An optional boolean. Equivalent to passing ``-Wdev`` or ``-Wno-dev``
  161. on the command line. This may not be set to ``false`` if ``errors.dev``
  162. is set to ``true``.
  163. ``deprecated``
  164. An optional boolean. Equivalent to passing ``-Wdeprecated`` or
  165. ``-Wno-deprecated`` on the command line. This may not be set to
  166. ``false`` if ``errors.deprecated`` is set to ``true``.
  167. ``uninitialized``
  168. An optional boolean. Setting this to ``true`` is equivalent to passing
  169. ``--warn-uninitialized`` on the command line.
  170. ``unusedCli``
  171. An optional boolean. Setting this to ``false`` is equivalent to passing
  172. ``--no-warn-unused-cli`` on the command line.
  173. ``systemVars``
  174. An optional boolean. Setting this to ``true`` is equivalent to passing
  175. ``--check-system-vars`` on the command line.
  176. ``errors``
  177. An optional object specifying the errors to enable. The object may
  178. contain the following fields:
  179. ``dev``
  180. An optional boolean. Equivalent to passing ``-Werror=dev`` or
  181. ``-Wno-error=dev`` on the command line. This may not be set to ``true``
  182. if ``warnings.dev`` is set to ``false``.
  183. ``deprecated``
  184. An optional boolean. Equivalent to passing ``-Werror=deprecated`` or
  185. ``-Wno-error=deprecated`` on the command line. This may not be set to
  186. ``true`` if ``warnings.deprecated`` is set to ``false``.
  187. ``debug``
  188. An optional object specifying debug options. The object may contain the
  189. following fields:
  190. ``output``
  191. An optional boolean. Setting this to ``true`` is equivalent to passing
  192. ``--debug-output`` on the command line.
  193. ``tryCompile``
  194. An optional boolean. Setting this to ``true`` is equivalent to passing
  195. ``--debug-trycompile`` on the command line.
  196. ``find``
  197. An optional boolean. Setting this to ``true`` is equivalent to passing
  198. ``--debug-find`` on the command line.
  199. Macro Expansion
  200. ^^^^^^^^^^^^^^^
  201. As mentioned above, some fields support macro expansion. Macros are
  202. recognized in the form ``$<macro-namespace>{<macro-name>}``. All macros are
  203. evaluated in the context of the preset being used, even if the macro is in a
  204. field that was inherited from another preset. For example, if the ``Base``
  205. preset sets variable ``PRESET_NAME`` to ``${presetName}``, and the
  206. ``Derived`` preset inherits from ``Base``, ``PRESET_NAME`` will be set to
  207. ``Derived``.
  208. It is an error to not put a closing brace at the end of a macro name. For
  209. example, ``${sourceDir`` is invalid. A dollar sign (``$``) followed by
  210. anything other than a left curly brace (``{``) with a possible namespace is
  211. interpreted as a literal dollar sign.
  212. Recognized macros include:
  213. ``${sourceDir}``
  214. Path to the project source directory.
  215. ``${sourceParentDir}``
  216. Path to the project source directory's parent directory.
  217. ``${sourceDirName}``
  218. The last filename component of ``${sourceDir}``. For example, if
  219. ``${sourceDir}`` is ``/path/to/source``, this would be ``source``.
  220. ``${presetName}``
  221. Name specified in the preset's ``name`` field.
  222. ``${generator}``
  223. Generator specified in the preset's ``generator`` field.
  224. ``${dollar}``
  225. A literal dollar sign (``$``).
  226. ``$env{<variable-name>}``
  227. Environment variable with name ``<variable-name>``. The variable name may
  228. not be an empty string. If the variable is defined in the ``environment``
  229. field, that value is used instead of the value from the parent environment.
  230. If the environment variable is not defined, this evaluates as an empty
  231. string.
  232. Note that while Windows environment variable names are case-insensitive,
  233. variable names within a preset are still case-sensitive. This may lead to
  234. unexpected results when using inconsistent casing. For best results, keep
  235. the casing of environment variable names consistent.
  236. ``$penv{<variable-name>}``
  237. Similar to ``$env{<variable-name>}``, except that the value only comes from
  238. the parent environment, and never from the ``environment`` field. This
  239. allows you to prepend or append values to existing environment variables.
  240. For example, setting ``PATH`` to ``/path/to/ninja/bin:$penv{PATH}`` will
  241. prepend ``/path/to/ninja/bin`` to the ``PATH`` environment variable. This
  242. is needed because ``$env{<variable-name>}`` does not allow circular
  243. references.
  244. ``$vendor{<macro-name>}``
  245. An extension point for vendors to insert their own macros. CMake will not
  246. be able to use presets which have a ``$vendor{<macro-name>}`` macro, and
  247. effectively ignores such presets. However, it will still be able to use
  248. other presets from the same file.
  249. CMake does not make any attempt to interpret ``$vendor{<macro-name>}``
  250. macros. However, to avoid name collisions, IDE vendors should prefix
  251. ``<macro-name>`` with a very short (preferably <= 4 characters) vendor
  252. identifier prefix, followed by a ``.``, followed by the macro name. For
  253. example, the Example IDE could have ``$vendor{xide.ideInstallDir}``.
  254. Schema
  255. ======
  256. :download:`This file </manual/presets/schema.json>` provides a machine-readable
  257. JSON schema for the ``CMakePresets.json`` format.