The main CMake binary could use the subcommands like cmake test, cmake install, cmake pack which may, like Git, call the wrappers like cmake-test, cmake-install, cmake-pack.
Users also may add their user extensions (like cmake-pgo which may run PGO scripts and collect profiles - see cargo-pgo, vcpkg/conan deps resolving (like similar --resolve-package-references in cmake --build`), etc.). These extensions could be handled via CMake configs in user home or system paths (whitelists, configs, etc.).
There is an even some repos with similar “subcommands-like” tools, like the cmake-init
To avoid breakage, the old cmake <path> command may be marked as deprecated and will be used if <path> exists, with gradual removing in favor of subcommands.
I’ve thought about this a few times, but I’m concerned about creating even more ways to do the same things. If we were starting from scratch today we’d use this approach, but we have almost 25 years of inertia behind the current command-line conventions.
the old cmake <path> command may be marked as deprecated and will be used if <path> exists
The meaning of cmake <path> is entrenched, so IMO the namespace for cmake subcommands is not available. We’d need a new top-level cm <subcommand> entry point. Mapping of new entry points to existing functionality, such as cm build to cmake --build would need to be carefully designed on a case-by-case basis.
One of the most common ways to invoke cmake is to just configure/generate a new build tree or regenerate an existing one. What cm <subcommand> signature(s) might you propose for that? They’d need to be no harder to type than cmake -B build or cmake --preset xyz.
I think that we may use abbreviated terms from ccmake, like gen with more longer alias generate.
I also thought about cfg , but it looks ambiguous (is it "configuring the current project or setting the config values for CMake itself?).
The ccmake btw may me called via nice short command cm tui , and cmake-gui may be cm gui.