It strikes me that Cargo and CMake are very different things, in this context.
cargo is a packaging tool (with compiler integration) for a single language (Rust). Other analogous tools:
gem (Ruby), etc.
cargo run exists because most Rust packages contain one or more binary targets, defined in their own documentation as “executable programs that can be run after being compiled.” Its metadata format (
Cargo.toml) allows tagging a binary target as
npm run is actually an alias for
npm run-script, which works with the
scripts object of its JSON metadata format (
package.json). There, arbitrary commands can be named as “scripts”, runnable both automatically at certain stages of the package lifecycle, or manually using
npm run. This is necessary because no JS packages are standalone executable binaries.
npm is therefore an overachiever on this front.
pip run does not exist, because most Python modules are not executable as such, they are scripts to run through an interpreter, and many are library packages meant to be called from other Python code rather than directly.
Some packages do install one or more “entry-points”, scripts used to launch a module, but even those require an installed package. (If a module is runnable from the build directory, those semantics are for the most part up to the author.) An entry point script or
python3 -m <module> is the preferred way to launch a runnable module.
gem run does not exist, because most Ruby gems are not executable as such, they are scripts to be run through an interpreter. (etc, etc.)
CMake, OTOH, is a build system generator that supports (in theory) building any type of output, for any platform, in any source language. While C/C++/Fortran are the most common, and while CMake does have the concept of an “executable target”, the run semantics of that target are impossibly diverse:
- It could be cross-compiled, in which case it’s not runnable on the current host platform
- It may be a binary component of a macOS application Bundle, in which case it requires a particular filesystem layout from which to be run
- It may be a Windows executable, in which case it may require a specific
%PATH% environment variable and/or the consolidation of
.dll dependencies in order to be runnable.
- It may have been compiled using
BUILD_WITH_INSTALL_RPATH, or other options that may render it non-executable from the build directory.
- It may be a Qt program, and require further configuration of plugin dirs or other paths via a
qt.conf file in order to be properly executable.
The notion of “running the results of a CMake build” really isn’t as concrete a notion as “running a compiled Rust binary”, not to the point where it would be as easy (or as useful) to generalize it into a built-in utility command. But, like @hex suggested, there’s certainly nothing stopping you from using
add_custom_target() to create a
run target, with
COMMAND arguments defining how your executable(s) should be run (much like
scripts definitions), and then using
cmake --build <builddir> --target run to run it.