# CMAKE\_COMMAND variable resolves to a different executable
**URL:** https://discourse.cmake.org/t/cmake-command-variable-resolves-to-a-different-executable/15633
**Category:** Usage
**Created:** [April 27, 2026, 7:06pm UTC](https://discourse.cmake.org/t/cmake-command-variable-resolves-to-a-different-executable/15633 "2026-04-27T19:06:07Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@nshustov](https://discourse.cmake.org/u/nshustov)
#### Post date: [April 27, 2026, 7:06pm UTC](https://discourse.cmake.org/t/cmake-command-variable-resolves-to-a-different-executable/15633/1 "2026-04-27T19:06:07Z")
Hi,
I have a question about CMAKE\_COMMAND variable.
We have multiple cmake executables in the same /my/bin directory, different in the name:
**/my/bin/cmake** , **/my/bin/cmake-3.30.3** , **/my/bin/cmake-4.1** and so on.
When I launch my script with “ **/my/bin/cmake-3.30.3 -P script.cmake** ”, the ${CMAKE\_COMMAND} in it resolves _not_ to **/my/bin/cmake-3.30.3** but to **/my/bin/cmake**.
I looked into the source code of 3.30.3 and found that CMAKE\_COMMAND does not seem to be composed from argv[0] of CMake executable which runs the CMake script. The logic locates “cmake” executable, explicitly by that name (plus extension, on platforms where applicable, e.g. Windows) in the directory where the CMake executable was launched from.
This messes things up, because the **/my/bin/cmake** and **/my/bin/cmake-3.30.3** are of different versions.
What is the rationale behind the decision to have CMAKE\_COMMAND resolved like that, as opposite of just using executable from argv[0] of the CMake main?
I have a poor workaround to try to force set CMAKE\_COMMAND in variables cache with the executable I use, but this is not quite feasible for building the libraries that are of other authors.
Are there any better solutions to have it solved?
Yeah, I know, there is an apparent “just don’t do that”, but it is not much up to me.
---
### Author:  [@craig.scott](https://discourse.cmake.org/u/craig.scott)
#### Post date: [April 27, 2026, 9:44pm UTC](https://discourse.cmake.org/t/cmake-command-variable-resolves-to-a-different-executable/15633/2 "2026-04-27T21:44:54Z")
Official CMake packages never name the executable anything other than `cmake` (or `cmake.exe` on Windows). The fact that you have multiple cmake executables in `/my/bin` but with different version suffixes suggests trying to collocate multiple installs to one place, but that is not a supported arrangement. The other files that CMake relies on can differ between versions in ways that require coordination between built binaries and those files.
A potentially valid way to set up an arrangement with versioned command names might be to install each CMake version to its own separate versioned directory, say `/opt/cmake/3.30.3` and `/opt/cmake/4.1.0`. Then you create symlinks in `/my/bin`:
- `/my/bin/cmake-3.30.3` → `/opt/cmake/3.30.3/bin/cmake`
- `/my/bin/cmake-4.1.0` → `/opt/cmake/4.1.0/bin/cmake`
But even then, developers don’t generally expect to have to use a versioned name like `cmake-3.30.3` to run CMake, they expect a plain `cmake` command to be available.
I understand that you may be asking about an arrangement you are not in control of. I’m only commenting on the arrangement you described, not how it is managed. I don’t know why the current logic was implemented how it currently is, but this should be a problem you can avoid. Indeed, this is a case of “just don’t do that”.
---
### Author:  [@nshustov](https://discourse.cmake.org/u/nshustov)
#### Post date: [April 27, 2026, 10:35pm UTC](https://discourse.cmake.org/t/cmake-command-variable-resolves-to-a-different-executable/15633/3 "2026-04-27T22:35:55Z")
Thank you, I understand.
I just would like to note that, to me, it feels there must be a valid reason for having more complicated, than just argv[0], logic for finding CMake executable filepath. I hope I can learn from knowing, why.