add_custom_command.rst 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243
  1. add_custom_command
  2. ------------------
  3. Add a custom build rule to the generated build system.
  4. There are two main signatures for ``add_custom_command``.
  5. Generating Files
  6. ^^^^^^^^^^^^^^^^
  7. The first signature is for adding a custom command to produce an output:
  8. .. code-block:: cmake
  9. add_custom_command(OUTPUT output1 [output2 ...]
  10. COMMAND command1 [ARGS] [args1...]
  11. [COMMAND command2 [ARGS] [args2...] ...]
  12. [MAIN_DEPENDENCY depend]
  13. [DEPENDS [depends...]]
  14. [BYPRODUCTS [files...]]
  15. [IMPLICIT_DEPENDS <lang1> depend1
  16. [<lang2> depend2] ...]
  17. [WORKING_DIRECTORY dir]
  18. [COMMENT comment]
  19. [DEPFILE depfile]
  20. [VERBATIM] [APPEND] [USES_TERMINAL]
  21. [COMMAND_EXPAND_LISTS])
  22. This defines a command to generate specified ``OUTPUT`` file(s).
  23. A target created in the same directory (``CMakeLists.txt`` file)
  24. that specifies any output of the custom command as a source file
  25. is given a rule to generate the file using the command at build time.
  26. Do not list the output in more than one independent target that
  27. may build in parallel or the two instances of the rule may conflict
  28. (instead use the :command:`add_custom_target` command to drive the
  29. command and make the other targets depend on that one).
  30. In makefile terms this creates a new target in the following form::
  31. OUTPUT: MAIN_DEPENDENCY DEPENDS
  32. COMMAND
  33. The options are:
  34. ``APPEND``
  35. Append the ``COMMAND`` and ``DEPENDS`` option values to the custom
  36. command for the first output specified. There must have already
  37. been a previous call to this command with the same output.
  38. The ``COMMENT``, ``MAIN_DEPENDENCY``, and ``WORKING_DIRECTORY``
  39. options are currently ignored when APPEND is given, but may be
  40. used in the future.
  41. ``BYPRODUCTS``
  42. Specify the files the command is expected to produce but whose
  43. modification time may or may not be newer than the dependencies.
  44. If a byproduct name is a relative path it will be interpreted
  45. relative to the build tree directory corresponding to the
  46. current source directory.
  47. Each byproduct file will be marked with the :prop_sf:`GENERATED`
  48. source file property automatically.
  49. Explicit specification of byproducts is supported by the
  50. :generator:`Ninja` generator to tell the ``ninja`` build tool
  51. how to regenerate byproducts when they are missing. It is
  52. also useful when other build rules (e.g. custom commands)
  53. depend on the byproducts. Ninja requires a build rule for any
  54. generated file on which another rule depends even if there are
  55. order-only dependencies to ensure the byproducts will be
  56. available before their dependents build.
  57. The ``BYPRODUCTS`` option is ignored on non-Ninja generators
  58. except to mark byproducts ``GENERATED``.
  59. ``COMMAND``
  60. Specify the command-line(s) to execute at build time.
  61. If more than one ``COMMAND`` is specified they will be executed in order,
  62. but *not* necessarily composed into a stateful shell or batch script.
  63. (To run a full script, use the :command:`configure_file` command or the
  64. :command:`file(GENERATE)` command to create it, and then specify
  65. a ``COMMAND`` to launch it.)
  66. The optional ``ARGS`` argument is for backward compatibility and
  67. will be ignored.
  68. If ``COMMAND`` specifies an executable target name (created by the
  69. :command:`add_executable` command) it will automatically be replaced
  70. by the location of the executable created at build time. If set, the
  71. :prop_tgt:`CROSSCOMPILING_EMULATOR` executable target property will
  72. also be prepended to the command to allow the executable to run on
  73. the host.
  74. (Use the ``TARGET_FILE``
  75. :manual:`generator expression <cmake-generator-expressions(7)>` to
  76. reference an executable later in the command line.)
  77. Additionally a target-level dependency will be added so that the
  78. executable target will be built before any target using this custom
  79. command. However this does NOT add a file-level dependency that
  80. would cause the custom command to re-run whenever the executable is
  81. recompiled.
  82. Arguments to ``COMMAND`` may use
  83. :manual:`generator expressions <cmake-generator-expressions(7)>`.
  84. References to target names in generator expressions imply target-level
  85. dependencies, but NOT file-level dependencies. List target names with
  86. the ``DEPENDS`` option to add file-level dependencies.
  87. ``COMMENT``
  88. Display the given message before the commands are executed at
  89. build time.
  90. ``DEPENDS``
  91. Specify files on which the command depends. If any dependency is
  92. an ``OUTPUT`` of another custom command in the same directory
  93. (``CMakeLists.txt`` file) CMake automatically brings the other
  94. custom command into the target in which this command is built.
  95. If ``DEPENDS`` is not specified the command will run whenever
  96. the ``OUTPUT`` is missing; if the command does not actually
  97. create the ``OUTPUT`` then the rule will always run.
  98. If ``DEPENDS`` specifies any target (created by the
  99. :command:`add_custom_target`, :command:`add_executable`, or
  100. :command:`add_library` command) a target-level dependency is
  101. created to make sure the target is built before any target
  102. using this custom command. Additionally, if the target is an
  103. executable or library a file-level dependency is created to
  104. cause the custom command to re-run whenever the target is
  105. recompiled.
  106. Arguments to ``DEPENDS`` may use
  107. :manual:`generator expressions <cmake-generator-expressions(7)>`.
  108. ``COMMAND_EXPAND_LISTS``
  109. Lists in ``COMMAND`` arguments will be expanded, including those
  110. created with
  111. :manual:`generator expressions <cmake-generator-expressions(7)>`,
  112. allowing ``COMMAND`` arguments such as
  113. ``${CC} "-I$<JOIN:$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>,;-I>" foo.cc``
  114. to be properly expanded.
  115. ``IMPLICIT_DEPENDS``
  116. Request scanning of implicit dependencies of an input file.
  117. The language given specifies the programming language whose
  118. corresponding dependency scanner should be used.
  119. Currently only ``C`` and ``CXX`` language scanners are supported.
  120. The language has to be specified for every file in the
  121. ``IMPLICIT_DEPENDS`` list. Dependencies discovered from the
  122. scanning are added to those of the custom command at build time.
  123. Note that the ``IMPLICIT_DEPENDS`` option is currently supported
  124. only for Makefile generators and will be ignored by other generators.
  125. ``MAIN_DEPENDENCY``
  126. Specify the primary input source file to the command. This is
  127. treated just like any value given to the ``DEPENDS`` option
  128. but also suggests to Visual Studio generators where to hang
  129. the custom command. Each source file may have at most one command
  130. specifying it as its main dependency. A compile command (i.e. for a
  131. library or an executable) counts as an implicit main dependency which
  132. gets silently overwritten by a custom command specification.
  133. ``OUTPUT``
  134. Specify the output files the command is expected to produce.
  135. If an output name is a relative path it will be interpreted
  136. relative to the build tree directory corresponding to the
  137. current source directory.
  138. Each output file will be marked with the :prop_sf:`GENERATED`
  139. source file property automatically.
  140. If the output of the custom command is not actually created
  141. as a file on disk it should be marked with the :prop_sf:`SYMBOLIC`
  142. source file property.
  143. ``USES_TERMINAL``
  144. The command will be given direct access to the terminal if possible.
  145. With the :generator:`Ninja` generator, this places the command in
  146. the ``console`` :prop_gbl:`pool <JOB_POOLS>`.
  147. ``VERBATIM``
  148. All arguments to the commands will be escaped properly for the
  149. build tool so that the invoked command receives each argument
  150. unchanged. Note that one level of escapes is still used by the
  151. CMake language processor before add_custom_command even sees the
  152. arguments. Use of ``VERBATIM`` is recommended as it enables
  153. correct behavior. When ``VERBATIM`` is not given the behavior
  154. is platform specific because there is no protection of
  155. tool-specific special characters.
  156. ``WORKING_DIRECTORY``
  157. Execute the command with the given current working directory.
  158. If it is a relative path it will be interpreted relative to the
  159. build tree directory corresponding to the current source directory.
  160. Arguments to ``WORKING_DIRECTORY`` may use
  161. :manual:`generator expressions <cmake-generator-expressions(7)>`.
  162. ``DEPFILE``
  163. Specify a ``.d`` depfile for the :generator:`Ninja` generator.
  164. A ``.d`` file holds dependencies usually emitted by the custom
  165. command itself.
  166. Using ``DEPFILE`` with other generators than Ninja is an error.
  167. Build Events
  168. ^^^^^^^^^^^^
  169. The second signature adds a custom command to a target such as a
  170. library or executable. This is useful for performing an operation
  171. before or after building the target. The command becomes part of the
  172. target and will only execute when the target itself is built. If the
  173. target is already built, the command will not execute.
  174. .. code-block:: cmake
  175. add_custom_command(TARGET <target>
  176. PRE_BUILD | PRE_LINK | POST_BUILD
  177. COMMAND command1 [ARGS] [args1...]
  178. [COMMAND command2 [ARGS] [args2...] ...]
  179. [BYPRODUCTS [files...]]
  180. [WORKING_DIRECTORY dir]
  181. [COMMENT comment]
  182. [VERBATIM] [USES_TERMINAL])
  183. This defines a new command that will be associated with building the
  184. specified ``<target>``. The ``<target>`` must be defined in the current
  185. directory; targets defined in other directories may not be specified.
  186. When the command will happen is determined by which
  187. of the following is specified:
  188. ``PRE_BUILD``
  189. On :ref:`Visual Studio Generators`, run before any other rules are
  190. executed within the target.
  191. On other generators, run just before ``PRE_LINK`` commands.
  192. ``PRE_LINK``
  193. Run after sources have been compiled but before linking the binary
  194. or running the librarian or archiver tool of a static library.
  195. This is not defined for targets created by the
  196. :command:`add_custom_target` command.
  197. ``POST_BUILD``
  198. Run after all other rules within the target have been executed.
  199. .. note::
  200. Because generator expressions can be used in custom commands,
  201. it is possible to define ``COMMAND`` lines or whole custom commands
  202. which evaluate to empty strings for certain configurations.
  203. For **Visual Studio 2010 (and newer)** generators these command
  204. lines or custom commands will be omitted for the specific
  205. configuration and no "empty-string-command" will be added.
  206. This allows to add individual build events for every configuration.