Hi @native-api, thanks for you suggestions!
I’ve used cmake --trace to check why python 3.7 was identified as 1.4. Here is the full log if you are interested, but the thing is that cmake tries to launch the following commands in order to extract python version:
${PYTHON_EXECUTABLE} -c import sys; sys.stdout.write(';'.join([str(x) for x in sys.version_info[:3]]))${PYTHON_EXECUTABLE} -c import sys; sys.stdout.write(sys.version)
Looks like both of them fails and cmake decides that python is pretty old.
So, I’ve tried to launch the same commands by myself to see what’s happening. Here is the results:
- first experiment
- second experiment
- and the third experiment which was successful
Looks like /opt/pyenv/shims/python3.7 command is not available anymore if certain python version wasn’t specified explicitly via pyenv
I think this might be considered as solved (or at least work-arounded), but actually, it would be good if /opt/pyenv/shims/python3.7 wasn’t there at all since it doesn’t work by default.
I haven’t investigated why cmake has selected exact this path to see if it is possible to change its behavior. However, this might not be easy, since FindPythonInterp module hasn’t launched directly by cmake from KhronosGroup/SPIRV-LLVM-Translator, but it is launched from CMakeLists.txt from another project - we have to update it there to fix our problem.