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.
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:
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”.
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.