add_custom_command¶
Add a custom build rule to the generated build system.
There are two main signatures for add_custom_command.
Generating Files¶
The first signature is for adding a custom command to produce an output:
add_custom_command(OUTPUT output1 [output2 ...]
COMMAND command1 [ARGS] [args1...]
[COMMAND command2 [ARGS] [args2...] ...]
[MAIN_DEPENDENCY depend]
[DEPENDS [depends...]]
[BYPRODUCTS [files...]]
[IMPLICIT_DEPENDS <lang1> depend1
[<lang2> depend2] ...]
[WORKING_DIRECTORY dir]
[COMMENT comment]
[DEPFILE depfile]
[JOB_POOL job_pool]
[VERBATIM] [APPEND] [USES_TERMINAL]
[COMMAND_EXPAND_LISTS])
This defines a command to generate specified OUTPUT file(s).
A target created in the same directory (CMakeLists.txt file)
that specifies any output of the custom command as a source file
is given a rule to generate the file using the command at build time.
Do not list the output in more than one independent target that
may build in parallel or the two instances of the rule may conflict
(instead use the add_custom_target() command to drive the
command and make the other targets depend on that one).
In makefile terms this creates a new target in the following form:
OUTPUT: MAIN_DEPENDENCY DEPENDS
COMMAND
The options are:
APPENDAppend the
COMMANDandDEPENDSoption values to the custom command for the first output specified. There must have already been a previous call to this command with the same output. TheCOMMENT,MAIN_DEPENDENCY, andWORKING_DIRECTORYoptions are currently ignored when APPEND is given, but may be used in the future.BYPRODUCTSSpecify the files the command is expected to produce but whose modification time may or may not be newer than the dependencies. If a byproduct name is a relative path it will be interpreted relative to the build tree directory corresponding to the current source directory. Each byproduct file will be marked with the
GENERATEDsource file property automatically.Explicit specification of byproducts is supported by the
Ninjagenerator to tell theninjabuild tool how to regenerate byproducts when they are missing. It is also useful when other build rules (e.g. custom commands) depend on the byproducts. Ninja requires a build rule for any generated file on which another rule depends even if there are order-only dependencies to ensure the byproducts will be available before their dependents build.The Makefile Generators will remove
BYPRODUCTSand otherGENERATEDfiles duringmake clean.COMMANDSpecify the command-line(s) to execute at build time. If more than one
COMMANDis specified they will be executed in order, but not necessarily composed into a stateful shell or batch script. (To run a full script, use theconfigure_file()command or thefile(GENERATE)command to create it, and then specify aCOMMANDto launch it.) The optionalARGSargument is for backward compatibility and will be ignored.If
COMMANDspecifies an executable target name (created by theadd_executable()command), it will automatically be replaced by the location of the executable created at build time if either of the following is true:The target is not being cross-compiled (i.e. the
CMAKE_CROSSCOMPILINGvariable is not set to true).The target is being cross-compiled and an emulator is provided (i.e. its
CROSSCOMPILING_EMULATORtarget property is set). In this case, the contents ofCROSSCOMPILING_EMULATORwill be prepended to the command before the location of the target executable.
If neither of the above conditions are met, it is assumed that the command name is a program to be found on the
PATHat build time.Arguments to
COMMANDmay usegenerator expressions. Use theTARGET_FILEgenerator expression to refer to the location of a target later in the command line (i.e. as a command argument rather than as the command to execute).Whenever a target is used as a command to execute or is mentioned in a generator expression as a command argument, a target-level dependency will be added automatically so that the mentioned target will be built before any target using this custom command. However this does NOT add a file-level dependency that would cause the custom command to re-run whenever the executable is recompiled. List target names with the
DEPENDSoption to add such file-level dependencies.COMMENTDisplay the given message before the commands are executed at build time.
DEPENDSSpecify files on which the command depends. Each argument is converted to a dependency as follows:
If the argument is the name of a target (created by the
add_custom_target(),add_executable(), oradd_library()command) a target-level dependency is created to make sure the target is built before any target using this custom command. Additionally, if the target is an executable or library, a file-level dependency is created to cause the custom command to re-run whenever the target is recompiled.If the argument is an absolute path, a file-level dependency is created on that path.
If the argument is the name of a source file that has been added to a target or on which a source file property has been set, a file-level dependency is created on that source file.
If the argument is a relative path and it exists in the current source directory, a file-level dependency is created on that file in the current source directory.
Otherwise, a file-level dependency is created on that path relative to the current binary directory.
If any dependency is an
OUTPUTof another custom command in the same directory (CMakeLists.txtfile), CMake automatically brings the other custom command into the target in which this command is built. A target-level dependency is added if any dependency is listed asBYPRODUCTSof a target or any of its build events in the same directory to ensure the byproducts will be available.If
DEPENDSis not specified, the command will run whenever theOUTPUTis missing; if the command does not actually create theOUTPUT, the rule will always run.Arguments to
DEPENDSmay usegenerator expressions.COMMAND_EXPAND_LISTSLists in
COMMANDarguments will be expanded, including those created withgenerator expressions, allowingCOMMANDarguments such as${CC} "-I$<JOIN:$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>,;-I>" foo.ccto be properly expanded.IMPLICIT_DEPENDSRequest scanning of implicit dependencies of an input file. The language given specifies the programming language whose corresponding dependency scanner should be used. Currently only
CandCXXlanguage scanners are supported. The language has to be specified for every file in theIMPLICIT_DEPENDSlist. Dependencies discovered from the scanning are added to those of the custom command at build time. Note that theIMPLICIT_DEPENDSoption is currently supported only for Makefile generators and will be ignored by other generators.JOB_POOLSpecify a
poolfor theNinjagenerator. Incompatible withUSES_TERMINAL, which implies theconsolepool. Using a pool that is not defined byJOB_POOLScauses an error by ninja at build time.MAIN_DEPENDENCYSpecify the primary input source file to the command. This is treated just like any value given to the
DEPENDSoption but also suggests to Visual Studio generators where to hang the custom command. Each source file may have at most one command specifying it as its main dependency. A compile command (i.e. for a library or an executable) counts as an implicit main dependency which gets silently overwritten by a custom command specification.OUTPUTSpecify the output files the command is expected to produce. If an output name is a relative path it will be interpreted relative to the build tree directory corresponding to the current source directory. Each output file will be marked with the
GENERATEDsource file property automatically. If the output of the custom command is not actually created as a file on disk it should be marked with theSYMBOLICsource file property.USES_TERMINALThe command will be given direct access to the terminal if possible. With the
Ninjagenerator, this places the command in theconsolepool.VERBATIMAll arguments to the commands will be escaped properly for the build tool so that the invoked command receives each argument unchanged. Note that one level of escapes is still used by the CMake language processor before add_custom_command even sees the arguments. Use of
VERBATIMis recommended as it enables correct behavior. WhenVERBATIMis not given the behavior is platform specific because there is no protection of tool-specific special characters.WORKING_DIRECTORYExecute the command with the given current working directory. If it is a relative path it will be interpreted relative to the build tree directory corresponding to the current source directory.
Arguments to
WORKING_DIRECTORYmay usegenerator expressions.DEPFILESpecify a
.ddepfile for theNinjagenerator. A.dfile holds dependencies usually emitted by the custom command itself. UsingDEPFILEwith other generators than Ninja is an error.
Build Events¶
The second signature adds a custom command to a target such as a library or executable. This is useful for performing an operation before or after building the target. The command becomes part of the target and will only execute when the target itself is built. If the target is already built, the command will not execute.
add_custom_command(TARGET <target>
PRE_BUILD | PRE_LINK | POST_BUILD
COMMAND command1 [ARGS] [args1...]
[COMMAND command2 [ARGS] [args2...] ...]
[BYPRODUCTS [files...]]
[WORKING_DIRECTORY dir]
[COMMENT comment]
[VERBATIM] [USES_TERMINAL]
[COMMAND_EXPAND_LISTS])
This defines a new command that will be associated with building the
specified <target>. The <target> must be defined in the current
directory; targets defined in other directories may not be specified.
When the command will happen is determined by which of the following is specified:
PRE_BUILDOn Visual Studio Generators, run before any other rules are executed within the target. On other generators, run just before
PRE_LINKcommands.PRE_LINKRun after sources have been compiled but before linking the binary or running the librarian or archiver tool of a static library. This is not defined for targets created by the
add_custom_target()command.POST_BUILDRun after all other rules within the target have been executed.
Note
Because generator expressions can be used in custom commands,
it is possible to define COMMAND lines or whole custom commands
which evaluate to empty strings for certain configurations.
For Visual Studio 2010 (and newer) generators these command
lines or custom commands will be omitted for the specific
configuration and no “empty-string-command” will be added.
This allows to add individual build events for every configuration.