Date: Thu, 27 Jul 2023 00:34:33 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 272745] www/qt6-webengine cmake find python routines no longer respect python.mk, highest python version install always found Message-ID: <bug-272745-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272745 Bug ID: 272745 Summary: www/qt6-webengine cmake find python routines no longer respect python.mk, highest python version install always found Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: kde@FreeBSD.org Reporter: alt2600@icloud.com Assignee: kde@FreeBSD.org Flags: maintainer-feedback?(kde@FreeBSD.org) Created attachment 243635 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D243635&action= =3Dedit qt6-webengine_pythondef.diff ran into this recently with graphics/qgis , and now with qt6-webengine. The cmake routines for FindPython, and its variants seemingly for finding pytho= n3 or python2 do not care to check what python.mk has defined for the python version to build for. They would return the greatest version installed by default. After installing blender this started happening as it requires pyt= hon 3.10, so now python 3.9 used for everything else is causing issues finding = the python executable. In this port some items like py-boost were properly dete= cted for python 3.9, but the general Python3_EXECUTABLE is returned as python3.1= 0, and this caused py39-html5lib from not being found. Had to explicitly pass a hint to CMake to override the default behavior of the ports installed cmake-core system. Those find python routines in /usr/local/share/cmake/Modules/ do not look at PYTHON_VER defined in python= .mk any longer, nor force the hint for Python_EXECUTABLE, Python3_EXECUTABLE in this case, nor Python2_EXECUTABLE to use default or as overridden in make.c= onf to use other system version. As such they default to returning the highest version of python installed, unless an alternate selection strategy is set = by the port using python in their call to FindPython. see PR 168159 patch forces the version returned by python.mk to be used, in my case the p= orts default version. AMD64; 13.2-p1 release, live system building --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-272745-7788>