To run custom build stages in CMake, you’ll often want what I call a “custom command/target pair”:
set(CLEAN_FS_IMG ${CMAKE_CURRENT_BINARY_DIR}/clean-fs.img)
add_custom_target(CleanFsImage DEPENDS ${CLEAN_FS_IMG})
add_custom_command(
OUTPUT ${CLEAN_FS_IMG}
COMMAND ${CMAKE_CURRENT_BINARY_DIR}/fsformat ${CLEAN_FS_IMG} 1024 ${FS_IMG_FILES}
WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
DEPENDS fsformat ${FS_IMG_FILES}
VERBATIM
)This is an example from my CMake-rewrite of the JOS OS build system. It generates a filesystem image, using a custom host tool (fsformat). The fs image includes a number of files generated by the build process. If any of those files changes, we want to rebuild the fs image.
At the core, we want to have a CMake target, just like an executable or library, that runs an arbitrary command line instead of a compiler.
Surprisingly, we need this “command/target pair” pattern to accomplish this.
add_custom_target() alone is not correct. This target is always out of date. If we put the command there, we will regenerate the fs every build, even if nothing has changed. This makes custom targets only suitable for helper commands that must always run (e.g. perhaps a helper target to run QEMU)
add_custom_command() does implement efficient rebuilding, only when an input has changed, but is also not sufficient alone, because it does not produce a named target.
This is admittedly a matter of personal taste — I prefer having named targets available because it allows manually trigger just this target in a build command. This would not be otherwise possible with a custom command.
If you don’t have this requirement, just a custom command could be fine, since you can depend on the output file path elsewhere in your build.
The combination of both produces what I want:
- A named target that can be independently triggered with a build command
- A build stage that runs an arbitrary command that only rebuilds when necessary
In other words, what this pair states is:
- Build CleanFsImage target always
- When building it, ensure ${CLEAN_FS_IMG} is created/up to date by running whatever operation necessary (i.e. the custom command)
- Then it’s up to the custom command to decide to run the command or not, based on if it’s necessary
A gotcha
One gotcha to be aware of is with chaining these command/target pairs.
set(FS_IMG ${CMAKE_CURRENT_BINARY_DIR}/fs.img)
add_custom_target(FsImage ALL DEPENDS ${FS_IMG})
add_custom_command(
OUTPUT ${FS_IMG}
COMMAND cp ${CLEAN_FS_IMG} ${FS_IMG}
# We cannot depend on CleanFsImage target here, because custom targets don't create
# a rebuild dependency (only native targets do).
DEPENDS ${CLEAN_FS_IMG}
VERBATIM
)In my build, I also have a FsImage target that just copies the clean one. This is one mounted by the OS, and might be mutated.
This custom command cannot depend on the CleanFsImage target, but rather must depend on the ${CLEAN_FS_IMG} path directly. That’s because custom targets don’t create a rebuild dependency (unlike native targets), just a build ordering.
In practice, the FsImage wasn’t being regenerated when the CleanFsImage was. To properly create a rebuild dependency, you must depend on the command target’s output path.
