Created attachment 243635 [details] 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 python3 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 python 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 detected for python 3.9, but the general Python3_EXECUTABLE is returned as python3.10, 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.conf 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 ports default version. AMD64; 13.2-p1 release, live system building
Duplicate of bug 262109?
Is this still an issue with 6.5.2? I wasn't seeing this behavior when testing that version.
(In reply to Jan Beich from comment #1) didn't even see that one, always wondered how to post bugs on Mk system issues. but yeah, removing my local hacks to qt6-webengine, and removing the recently committed ports patch to qgis, and instead applying the patch to python.mk in that PR fixes both ports finding the proper python to use as set in my case default, but presumably if overridden by make.conf python.mk would return that one instead. I added reference to to the python.mk bug, and I suppose this one could close, assuming PR 262109 is merged to resolve things permanently to provide cmake a hint for the python to use. Sure hope PR 262109 's patch is merged soon.
(In reply to Jason E. Hale from comment #2) not sure, I just updated last night, thunderstorms in the area make me not want to try building 6.5.2, 6.5.0 seems to be the latest in ports but did 6.5.2 just get committed? If it relies on cmake-core for findpython routines then likely yes, one of those seeks will get mangled. This is an issue with cmake-core updating the routines and no longer allowing the version to be specified with PYTHON_VER being set by python.mk, we now seem to need to explicitly hint the executable to use. Basically the Interp routines are deprecated in cmake it now has FindPython, FindPython2 and FindPython3 routines that are to be used, they don't check for a version hint. assuming you are using python 3.9 as the default, try installing python 3.10 then launching configure. CmakeCache.txt will indicate the python it will use via the Python_EXECUTABLE and Python3_EXECUTABLE variables. boost will find the right version though for some reason, least it did with 6.5.0 on my systems. Think you will have to do a live build, this isn't going to happen in poudriere.
(In reply to alt2600 from comment #4) Yes, I just committed 6.5.2 about hour and a half ago. I did do a live build with python 3.9 and 3.11 installed and it used 3.9 which I have as default. I made a change to BINARY_ALIAS for python in the update, though. https://cgit.freebsd.org/ports/blame/www/qt6-webengine/Makefile#n81 Without this change, I am seeing Python 3.11 getting picked up, but with it, I only see 3.9 in CMakeCache.txt.
(In reply to Jason E. Hale from comment #5) With the storms passed, I ran the upgrades of qt6 over night, and yes they seemed to work fine on webengine. I reconfirmed this morning by checking CMakeCache.txt after running an explicit make clean configure. Hopefully if 262109 gets merged these workarounds to cmake fighting ports won't be needed. not sure if I should go with closed, duplicate bug, or just fixed. duplicate feels more correct as python.mk and cmakes FindPython set of routines conflict seems to be the root of it all.
Closing as dup of the issue that Jan suggested. *** This bug has been marked as a duplicate of bug 262109 ***