cmake-configure-log.7.rst 7.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254
  1. .. cmake-manual-description: CMake Configure Log
  2. cmake-configure-log(7)
  3. **********************
  4. .. versionadded:: 3.26
  5. .. only:: html
  6. .. contents::
  7. Introduction
  8. ============
  9. CMake writes a running log, known as the configure log,
  10. of certain events that occur during the "configure" step.
  11. The log file is located at::
  12. ${CMAKE_BINARY_DIR}/CMakeFiles/CMakeConfigureLog.yaml
  13. The configure log does *not* contain a log of all output, errors,
  14. or messages printed while configuring a project. It is a log of
  15. detailed information about specific events, such as toolchain inspection
  16. by :command:`try_compile`, meant for use in debugging the configuration
  17. of a build tree.
  18. Log Structure
  19. =============
  20. The configure log is designed to be both machine- and human-readable.
  21. The log file is a YAML document stream containing zero or more YAML
  22. documents separated by document markers. Each document begins
  23. with a ``---`` document marker line, contains a single YAML mapping
  24. that logs events from one CMake "configure" step, and, if the configure
  25. step finished normally, ends with a ``...`` document marker line:
  26. .. code-block:: yaml
  27. ---
  28. events:
  29. -
  30. kind: "try_compile-v1"
  31. # (other fields omitted)
  32. -
  33. kind: "try_compile-v1"
  34. # (other fields omitted)
  35. ...
  36. A new document is appended to the log every time CMake configures
  37. the build tree and logs new events.
  38. The keys of the each document root mapping are:
  39. ``events``
  40. A YAML block sequence of nodes corresponding to events logged during
  41. one CMake "configure" step. Each event is a YAML node containing one
  42. of the `Event Kinds`_ documented below.
  43. Log Versioning
  44. --------------
  45. Each of the `Event Kinds`_ is versioned independently. The set of
  46. keys an event's log entry provides is specific to its major version.
  47. When an event is logged, the latest version of its event kind that is
  48. known to the running version of CMake is always written to the log.
  49. Tools reading the configure log must ignore event kinds and versions
  50. they do not understand:
  51. * A future version of CMake may introduce a new event kind or version.
  52. * If an existing build tree is re-configured with a different version of
  53. CMake, the log may contain different versions of the same event kind.
  54. Text Block Encoding
  55. -------------------
  56. In order to make the log human-readable, text blocks are always
  57. represented using YAML literal block scalars (``|``).
  58. Since literal block scalars do not support escaping, backslashes
  59. and non-printable characters are encoded at the application layer:
  60. * ``\\`` encodes a backslash.
  61. * ``\xXX`` encodes a byte using two hexadecimal digits, ``XX``.
  62. .. _`configure-log event kinds`:
  63. Event Kinds
  64. ===========
  65. Every event kind is represented by a YAML mapping of the form:
  66. .. code-block:: yaml
  67. kind: "<kind>-v<major>"
  68. backtrace:
  69. - "<file>:<line> (<function>)"
  70. #...event-specific keys...
  71. The keys common to all events are:
  72. ``kind``
  73. A string identifying the event kind and major version.
  74. ``backtrace``
  75. A YAML block sequence reporting the call stack of CMake source
  76. locations at which the event occurred. Each node is a string
  77. specifying one location formatted as ``<file>:<line> (<function>)``.
  78. Additional mapping keys are specific to each (versioned) event kind,
  79. described below.
  80. Event Kind ``try_compile``
  81. --------------------------
  82. The :command:`try_compile` command logs ``try_compile`` events.
  83. There is only one ``try_compile`` event major version, version 1.
  84. .. _`try_compile-v1 event`:
  85. ``try_compile-v1`` Event
  86. ^^^^^^^^^^^^^^^^^^^^^^^^
  87. A ``try_compile-v1`` event is a YAML mapping:
  88. .. code-block:: yaml
  89. kind: "try_compile-v1"
  90. backtrace:
  91. - "CMakeLists.txt:123 (try_compile)"
  92. directories:
  93. source: "/path/to/.../TryCompile-01234"
  94. binary: "/path/to/.../TryCompile-01234"
  95. buildResult:
  96. variable: "COMPILE_RESULT"
  97. cached: true
  98. stdout: |
  99. # ...
  100. exitCode: 0
  101. The keys specific to ``try_compile-v1`` mappings are:
  102. ``directories``
  103. A mapping describing the directories associated with the
  104. compilation attempt. It has the following keys:
  105. ``source``
  106. String specifying the source directory of the
  107. :command:`try_compile` project.
  108. ``binary``
  109. String specifying the binary directory of the
  110. :command:`try_compile` project.
  111. For non-project invocations, this is often the same as
  112. the source directory.
  113. ``buildResult``
  114. A mapping describing the result of compiling the test code.
  115. It has the following keys:
  116. ``variable``
  117. A string specifying the name of the CMake variable
  118. storing the result of trying to build the test project.
  119. ``cached``
  120. A boolean indicating whether the above result ``variable``
  121. is stored in the CMake cache.
  122. ``stdout``
  123. A YAML literal block scalar containing the output from building
  124. the test project, represented using our `Text Block Encoding`_.
  125. This contains build output from both stdout and stderr.
  126. ``exitCode``
  127. An integer specifying the build tool exit code from trying
  128. to build the test project.
  129. Event Kind ``try_run``
  130. ----------------------
  131. The :command:`try_run` command logs ``try_run`` events.
  132. There is only one ``try_run`` event major version, version 1.
  133. .. _`try_run-v1 event`:
  134. ``try_run-v1`` Event
  135. ^^^^^^^^^^^^^^^^^^^^
  136. A ``try_run-v1`` event is a YAML mapping:
  137. .. code-block:: yaml
  138. kind: "try_run-v1"
  139. backtrace:
  140. - "CMakeLists.txt:456 (try_run)"
  141. directories:
  142. source: "/path/to/.../TryCompile-56789"
  143. binary: "/path/to/.../TryCompile-56789"
  144. buildResult:
  145. variable: "COMPILE_RESULT"
  146. cached: true
  147. stdout: |
  148. # ...
  149. exitCode: 0
  150. runResult:
  151. variable: "RUN_RESULT"
  152. cached: true
  153. stdout: |
  154. # ...
  155. stderr: |
  156. # ...
  157. exitCode: 0
  158. The keys specific to ``try_run-v1`` mappings include those
  159. documented by the `try_compile-v1 event`_, plus:
  160. ``runResult``
  161. A mapping describing the result of running the test code.
  162. It has the following keys:
  163. ``variable``
  164. A string specifying the name of the CMake variable
  165. storing the result of trying to run the test executable.
  166. ``cached``
  167. A boolean indicating whether the above result ``variable``
  168. is stored in the CMake cache.
  169. ``stdout``
  170. An optional key that is present when the test project built successfully.
  171. Its value is a YAML literal block scalar containing output from running
  172. the test executable, represented using our `Text Block Encoding`_.
  173. If ``RUN_OUTPUT_VARIABLE`` was used, stdout and stderr are captured
  174. together, so this will contain both. Otherwise, this will contain
  175. only the stdout output.
  176. ``stderr``
  177. An optional key that is present when the test project built successfully
  178. and the ``RUN_OUTPUT_VARIABLE`` option was not used.
  179. Its value is a YAML literal block scalar containing output from running
  180. the test executable, represented using our `Text Block Encoding`_.
  181. If ``RUN_OUTPUT_VARIABLE`` was used, stdout and stderr are captured
  182. together in the ``stdout`` key, and this key will not be present.
  183. Otherwise, this will contain the stderr output.
  184. ``exitCode``
  185. An optional key that is present when the test project built successfully.
  186. Its value is an integer specifying the exit code, or a string containing
  187. an error message, from trying to run the test executable.