[Bug 272457] graphics/qgis multiple installed pythons break build, latest version is always selected by cmake

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272457

            Bug ID: 272457
           Summary: graphics/qgis multiple installed pythons break build,
                    latest version is always selected by cmake
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: rhurlin@FreeBSD.org
          Reporter: alt2600@icloud.com
          Assignee: rhurlin@FreeBSD.org
             Flags: maintainer-feedback?(rhurlin@FreeBSD.org)

So i recently had to add python 3.10 so I could install blender, but now qgis
complains that doesn't have python 3.10 sip installed, which is true in my
case, I have it for 3.9 . even if I figure how to fix this, it seems like maybe
multi-python may be a problem as it will seemingly default to using the newest
installed python. Still trying to work out how the detection routines work. I
could certain install a more complete python 3.10 to get all the dependencies
needed, but don't see as a fix. I tried amending USES python:3.8+ but this is a
cmake routine finding the newer installed version. I'm sure this could be
resolved once the right Cmake variable is forced, but when I find it that would
seemingly force the python version to support. Not sure what you may want to
do, either drop multi python, or just target the default python version. I
think if targeting default once cmake is taked all that is needed is swapping
PY_FLAVOR and PYTHON_PKGNAMEPREFIX with like a PYVER forcing one. But this is
the kind of thing that would be your call as maintainer. I could certainly try
to work a patch that does that, but don't want to do so if this is not the
direction you'd want to take. I know of no trick to find a more suitable python
except some evile Makefile magic to check the depends ahead of the dependency
checks to pick a python version to pass to cmake, but this just feels wrong to
me. I'll keep checking for a cleaner way to trick cmake into using my preferred
python, but still looking for which cmake routine is doing the search. I didn't
notice in the source, so I'm assuming its the system cmake routines.

PR 168159 seems to suggest cmake should respect PYTHON_VER set in python.mk,
but not sure if a flag needs to be set or a possible regression in cmake???

I'm going to dig some more, but not clear totally what is wrong

-- Found Python: /usr/local/bin/python3.10 (found suitable version "3.10.12",
minimum required is "3.7") found components: Interpreter Development
Development.Module Development.Embed 
-- Found Python executable: /usr/local/bin/python3.10 (version 3.10.12)
-- Python library: /usr/local/lib/libpython3.10.so
-- Python site-packages: /usr/local/lib/python3.10/site-packages
Traceback (most recent call last):
  File "/usr/ports/graphics/qgis/work/qgis-3.32.0/cmake/FindSIP.py", line 34,
in <module>
    import sipbuild
ModuleNotFoundError: No module named 'sipbuild'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/ports/graphics/qgis/work/qgis-3.32.0/cmake/FindSIP.py", line 47,
in <module>
    import sipconfig
ModuleNotFoundError: No module named 'sipconfig'
CMake Error at cmake/FindSIP.cmake:58 (MESSAGE):
  Could not find SIP
Call Stack (most recent call first):
  CMakeLists.txt:983 (find_package)


-- Configuring incomplete, errors occurred!
*** Error code 1

-- 
You are receiving this mail because:
You are the assignee for the bug.