FindPython ignores Python3_ROOT_DIR in favor of a newer interpreter
My situation: I have two Python installations on my machine: python3.8 installed in an MSYS2 environment, and a system python3.7 installed to Program Files that I use for most tasks. I have a CMake script containing
find_package(Python3 COMPONENTS Interpreter). I want this to find the system python3.7 because this has packages installed that I'm using.
The problem: no matter what I do as a user, FindPython3 finds the MSYS2 python3.8 instead of my python3.7. This includes passing
-DPython3_ROOT_DIR=C:/Program Files/Python37, and putting python3.7 ahead in my PATH. From what I can figure, I have an idea why this happens. It looks like FindPython3 starts with the most recent Python version (3.8), and scans all system installations for one that matches that version. If it finds one, it uses that without further searching. So, the MSYS python3.8 is found before it scans for python3.7.
I understand that this behavior is desirable in most cases, but it seems very problematic that there is no documented way for the user to override this and force an older Python version even though that version meets the requirements in the original find_package() call. The only way that I could prevent this would be to remove MSYS2 from my PATH completely, or to modify FindPythonSuport/Support.cmake to remove the error check in _python_validate_interpreter() for a mismatching interpreter version (what I ended up doing).
The simplest fix would be to have FindPython3 check the installation specified in Python3_ROOT_DIR before entering the loop that checks for each version in sequence. Also, I would really appreciate some kind of
Python3_DEBUG mode that would print an explanation of why an installation was ignored -- at several times, a printout like "The python interpreter X was rejected because it was an incompatible ABI/architecture/version/etc" would have saved me like an hour of debugging.
Anyway, thanks for taking a look at this, and I hope we can figure out a fix.