FindPython3 offers two strategies: VERSION and LOCATION.
From a user’s point of view, the best strategy would be to check what python3 is referring to. Assume two version of Python are installed (3.6 and 3.7) and 3.6 is the default, i.e, python3 is a link to version 3.6. FindPython3 find with both strategies for one of our users 3.7. When the user want to run a program with python bindings, it crashes, as calling python3 is pointing to 3.6.
Is this intentional? Is there a reason, not to check python3 / /usr/bin/python3 first? In the predecessor of FindPython3, it worked as expected.
Yes, it is intentional. The strategy is to find the latest version available.
Every developer has a specific need and expect that this need will be the default of the module. As you might expect, this is not possible to have a such behavior.
Now, I agree it is a little problematic to not have an easy way to pick-up the default python interpreter in the PATH. I add this to m TODO list.
In the meantime, you can specify a version to search for or set the variable
Python3_EXECUTABLE to pick-up the expected interpreter.
Do you see any workaround which I could include into the CMake code to spare my users from giving an explicit Python version? They mind feel this would be a regression compared to the old behavior before FindPython3.
There is no workaround except specifying
But I just submit a MR to solve this problem. In your case, specifying
set(Python3_FIND_GENERIC_NAMES FIRST) will enable your expected behavior.
Thank you for fixing my issue in the upcoming CMake version! I just found the time to give it a try. It did not work when I set
Python_FIND_UNVERSIONED_NAMES but only for
Python3_FIND_UNVERSIONED_NAMES. Grepping for the generic variable name revealed, that it is never used. Is this a bug or do I misinterpret the documentation?
I think you misunderstood the usage of variables with prefix
Python. These variables are not
generic. They must be used if you use package
Prefix of variables must match with the package name:
Ah I see, makes perfectly sense!
I have one more question: Why did you decide to make
LAST the default. From a user’s point of view, I would expect it to be
FIRST, because I type into my terminal
python3, sometimes I don’t even know the exact version but the distribution or my admin does take care that it is a sane default.
This was also the behavior of
FindPythonInterp, not sure whether it was intentional or by chance.
It is not allowed to change the behavior of any part of
CMake after publication, so
FIRST cannot be the default. And, anyway, this initial behavior is fully intentional because it enables the possibility to pick-up the right version when specified as part of
Ok, makes sense. Thanks for the clarification!