-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Python bindings don't respect CMAKE_INSTALL_PREFIX #10820
Comments
Thanks very much @m-elwin for highlighting this CMake issue to the RealSense community and advising about a manual workaround! |
…INSTALL_PREFIX ${Python_SITEARCH} seems to return an absolute path so it can't be used to find the install location of python libraries. Instead the directory is now specified in a manner similar to that used for cmake versions < 3.12 (which use an older cmake module to find Python)
Case closed due to no further comments received. Thanks again @m-elwin for sharing your workaround! |
@m-elwin Do you have two different Python installations? Is CMake finding the wrong Python executable? |
Wanted to install under my home directory instead of system python directory (which requires root). |
Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):
All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)
Issue Description
When configuring a build with -DBUILD_PYTHON_BINDINGS=ON, the generated
python libraries are always installed relative to / (e.g., /usr/lib/python3.10/dist-packages), regardless of the value of CMAKE_INSTALL_PREFIX.
Specifying -DPYTHON_INSTALL_DIR manually works around this issue.
I believe the issue is related to how the Python install directory is determined.
In wrappers/python/CMakeLists.txt:64, PYTHON_INSTALL_DIR is set to ${Python_SITEARCH}, which I believe is always an absolute path.
I think the code used for CMake Version <3.12 may not have this issue.
The text was updated successfully, but these errors were encountered: