mraa icon indicating copy to clipboard operation
mraa copied to clipboard

OpenCVDetectPython.cmake: prefer using FindPython

Open CodeChenL opened this issue 1 year ago • 5 comments

Reason for change:

  1. PythonInterp will misdetect Python3 as Python2 in distributions using newer versions of CMake:
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.11.2", minimum required is "2.7")
-- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.11.so (found suitable exact version "3.11.2")
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.11.2", minimum required is "3")
-- Found PythonLibs: /usr/lib/aarch64-linux-gnu/libpython3.11.so (found suitable exact version "3.11.2")
  1. PythonInterp will be removed soon and unusable: https://cmake.org/cmake/help/latest/module/FindPythonInterp.html, for Debian that is Debian 13

CodeChenL avatar Sep 11 '24 12:09 CodeChenL

Hi @tingleby, can you take a look at this PR? This issue currently causes build failure when we cross build from AMD64 to ARM64 on Debian 12, thus blocking us from release prebuilt package to our users.

RadxaYuntian avatar Sep 29 '24 07:09 RadxaYuntian

Thank you for this contribution, but I think we should better simply get rid of that OpenCV module at all. It's been a while, so I may be mistaken, but it was primarily introduced to avoid writing the Python2/3 + version range handling and selection logic by ourselves. These days it's (a) no longer needed to account for Python 2 and (b) as you've observed, the logic is outdated, so I think we should at least try to simplify this to use the built-in modules.

I plan on tackling this after #1148 is merged + after we setup a basic build/test GH workflow to have basic PR checks (I'm working on this now based on the initial version @tingleby researched in a dedicated branch).

With that, I think we don't need this PR but feel free to elaborate if you have any other thoughts here.

alext-mkrs avatar Nov 02 '25 18:11 alext-mkrs

We do not use Python 2 ourselves, so this PR was done strictly to maintain compatibility. I have no objection to drop it.

RadxaYuntian avatar Nov 03 '25 02:11 RadxaYuntian

I would also be in favour of dropping Python 2. I think its time. The module likely can be dropped for something modern.

tingleby avatar Nov 03 '25 05:11 tingleby

I think so too.

CodeChenL avatar Nov 03 '25 05:11 CodeChenL