OpenCVDetectPython.cmake: prefer using FindPython
Reason for change:
- 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")
- PythonInterp will be removed soon and unusable: https://cmake.org/cmake/help/latest/module/FindPythonInterp.html, for Debian that is Debian 13
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.
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.
We do not use Python 2 ourselves, so this PR was done strictly to maintain compatibility. I have no objection to drop it.
I would also be in favour of dropping Python 2. I think its time. The module likely can be dropped for something modern.
I think so too.