-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Inconsistent detection of python version in pybind11 and default cmake #1090
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The default |
I totally agree that these things work absolutely inconsistent. However they are used often. May be just mention this in big red letters in the docs? :) |
Sure -- can you create a PR with your suggested wording? |
Done. I'm hope that I did everything correctly - I'm new to github. |
The module is even deprecated and |
I'm facing this issue too. Any plans to move to using |
Yep: #2370 :) |
Uh oh!
There was an error while loading. Please reload this page.
If both python 2.7 and 3.5 are installed in Linux there is an inconsistent behavior (tested with cmake 3.5).
cmake functions
find_package(PythonInterp)
andfind_package(PythonLibs)
find 2.7 by default.In contrast pybind11 finds 3.5 by default.
This leads to weird bugs in complex projects where pybind11 is used along with other python-related things because the order of find_package in CMakeLists.txt matters:
Now the opposite way:
This is very confusing. Imho, pybind11 should find 2.7 by default to be consistent with what one expects from default cmake behavior.
At least it worth mentioning this clearly in docs.
The text was updated successfully, but these errors were encountered: