It would be great if the cmake executable gained a run option that could build and run a particular target. Currently a typical scenario I find myself encountering is that a repository has a tool that needs to be built and then run from a script so I see a lot of scripts that do:
cmake --build --preset X --target TARGET
./cmake-build-X/path/to/Release/TARGET --args
The issue here is that the script needs to be aware of where in the build tree the target exists, and also remember to build it first to make sure it is up to date. If ever the developers of the project decide to move the target around within the build tree, all the scripts need to be updated to point to the new path.
It seems a run command could be added to CMake that could solve this issue in a clean and elegant way:
cmake run TARGET -- --args
The double -- could be used to separate the arguments to CMake from those to the target.
It seems like this would make life easier for authoring and maintaining scripts in this kind of scenario.
I think it could be a cmake --run <--target TARGET> [--config CONFIG] [-- --args --for target] (<required> and [optional]). I don’t think bare arguments are allowed because it is conflated with configuring a run directory today.
But otherwise this sounds reasonable to me.
Things to consider (but are by no means exhaustive):
maybe a CMAKE_DEFAULT_RUN_TARGET variable can make the --target option non-required;
consider CMAKE_CROSSCOMPILING_EMULATOR to launch executables in cross-compiling mode;
an --update (or similar) flag to build the target in question;
--run --list to list available targets; and
in the future, not all executables may be built (see this issue); but this is something the one coming after can deal with rather than worrying too much about it here.
I use add_custom_command(TARGET ... POST_BUILD COMMAND ...) for this now. But yes the change detection isn’t the best this way. For example, building an assembler executable, then building executables from assembly files.
That all sounds reasonable, I did mean —run just as in —build. Also just for clarity I didn’t mean to literally have —args it was just an example of an arg for a target.
Sounds good. I’d be interested in working on the feature but I have no previous experience contributing to CMake, do I just fork the repo and get to work according to https://github.com/Kitware/CMake/blob/master/CONTRIBUTING.rst or is there an issue tracker or RFC type process this would need to go through first?
Opening an issue for design discussion first would be good (though the core of the feature makes sense, I think a lot of the details are in how and what information to pass from configure for this mode to read and understand). Other than that, yes, CONTRIBUTING.rst has the docs for that.
Hello Kamil,
Have you opened an issue for this subject?
I also need this, and if the feature --run is carried ahead, it would be good to have a link to the next step. Thank you in advance.
I have not. My workaround was to set CMAKE_RUNTIME_OUTPUT_DIRECTORY to ${CMAKE_BINARY_DIR}/bin so that regardless of where in the source tree a binary target is defined the result will always be in ${CMAKE_BINARY_DIR}/bin/${CONFIG}/ which makes it easy enough for external scripts to find.