Skip to content

Conversation

@CodeChenL
Copy link

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

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")
```

2. PythonInterp will be removed soon and unusable: https://cmake.org/cmake/help/latest/module/FindPythonInterp.html, for Debian that is Debian 13

Signed-off-by: Chen Jiali <[email protected]>
@RadxaYuntian
Copy link
Contributor

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.

@alext-mkrs
Copy link
Contributor

alext-mkrs commented Nov 2, 2025

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.

@RadxaYuntian
Copy link
Contributor

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

@tingleby
Copy link
Member

tingleby commented Nov 3, 2025

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

@CodeChenL
Copy link
Author

I think so too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants