# Feature request: Add support for subcommands like git and many CLI utils do (cargo, npm)

**URL:** https://discourse.cmake.org/t/feature-request-add-support-for-subcommands-like-git-and-many-cli-utils-do-cargo-npm/11514
**Category:** Development
**Created:** [August 23, 2024, 3:02pm UTC](https://discourse.cmake.org/t/feature-request-add-support-for-subcommands-like-git-and-many-cli-utils-do-cargo-npm/11514 "2024-08-23T15:02:34Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![brad.king](https://discourse.cmake.org/user_avatar/discourse.cmake.org/brad.king/32/11_2.png) [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [August 23, 2024, 3:23pm UTC](https://discourse.cmake.org/t/feature-request-add-support-for-subcommands-like-git-and-many-cli-utils-do-cargo-npm/11514/2 "2024-08-23T15:23:04Z")

</div>

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`.

---

_[View the full topic](https://discourse.cmake.org/t/feature-request-add-support-for-subcommands-like-git-and-many-cli-utils-do-cargo-npm/11514)._