See e.g. bug #835361 The package merely does: find_package(Python3 REQUIRED COMPONENTS Interpreter) the python-any-r1 eclass exports PYTHON and EPYTHON to the proper values, but the cmake module ignores this and simply uses the highest version
(In reply to Alexis Ballier from comment #0) > See e.g. bug #835361 > > The package merely does: > find_package(Python3 REQUIRED COMPONENTS Interpreter) > > the python-any-r1 eclass exports PYTHON and EPYTHON to the proper values, > but the cmake module ignores this and simply uses the highest version I hope I understood correctly your request / query. Otherwise I will gladly give answer based on more info for your question. The python* eclasses can't correctly define needed variable for all build systems. I know cmake is super frequent one, but we should look at all of them as same priority. Mostly the ebuild should define the vars it need for build. To correctly pass (force) the needed python version of python on cmake based package, you should pass it the following cmake arg (if they use FindPython3 [1]): -DPython3_EXECUTABLE="${PYTHON}" For more "full" example, you can view "dev-lang/yap/yap-7.0.1.ebuild" in ::gentoo tree (this was the first ebuild I found in fast search - so no idea the quality of other parts in ebuild, but python arg is correct). In next python project discussion I will introduce the idea of adding some documentation on setting cmake for python into out python-guide [2] (for easier documentation). [1] https://cmake.org/cmake/help/latest/module/FindPython3.html [2] https://projects.gentoo.org/python/guide/index.html
(In reply to Arthur Zamarin from comment #1) > (In reply to Alexis Ballier from comment #0) > > See e.g. bug #835361 > > > > The package merely does: > > find_package(Python3 REQUIRED COMPONENTS Interpreter) > > > > the python-any-r1 eclass exports PYTHON and EPYTHON to the proper values, > > but the cmake module ignores this and simply uses the highest version > > I hope I understood correctly your request / query. Otherwise I will gladly > give answer based on more info for your question. > > The python* eclasses can't correctly define needed variable for all build > systems. I know cmake is super frequent one, but we should look at all of > them as same priority. Mostly the ebuild should define the vars it need for > build. I do not want to change any eclass here. My issue is that FindPythonInterp.cmake honours EPYTHON while the others FindPython*.cmake do not. We have cmake-3.9.0_rc2-FindPythonInterp.patch for FindPythonInterp.cmake that only searches for "python" and then works fine because our wrapper uses EPYTHON. This is not working anymore with e.g. FindPython3.cmake. I can workaround that by patching ament (or, as you suggest, passing the proper variables) but I thought it would be more benefical if cmake could work out of the box. It may or may not be possible, or easy, or desired, which is why I wanted input from cmake maintainers.
Hello, I am kind of facing the same issue here (as normal user, not in an ebuild). Using (CMake): > find_package(PythonInterp 3 REQUIRED) works as expected and gives me python 3.9, which is my system default python. (PYTHON_SINGLE_TARGET="python3_9" PYTHON_TARGETS="python3_9") The only problem is that this is deprecated in CMake. Using the newer (not deprecated) > find_package(Python3) gives me the newest installed python 3.11, which lacks several modules. It may works fine for ebuilds (as python-any-r1 exports the necessary variables), but it does not work for normal user cmake projects, where the old "PythonInterp" worked fine. Now sure who is actually responsible for this... Or how to correctly workaround this, as the python system default is defined by portage, so I would not expect the user to workaround it. And there are some really nasty projects which makes it hard to pass the variable. Are my assumptions correct? If not, please correct me :) FULL CMakeLists.txt as normal user: > cmake_minimum_required(VERSION 3.12) > project(test) > find_package (Python3)
Created attachment 782441 [details, diff] cmake-python-support.patch for dev-util/cmake I attached a patch (just as a proposal) to maybe make my point more clear. As gentoo sets the correct "python3", all "find_package(Python3)" has to do is search for any python3 version, hence adding just "3" without any minor version works fine. What do you think about it? :)
We hit the same problem with csdiff: https://github.com/csutils/csdiff/pull/113#issuecomment-1451879156 attachment #782441 [details, diff] fixes the issue (without the need to provide -DPython3_EXECUTABLE=python3 manually for each project that uses it).
Gentoo shouldn't be patching CMake to override upstream behavior. This is against the principle of least surprise. This is especially harmful to software developers that are going to see inconsistent behavior between Gentoo and other distributions.
I think in this case Gentoo is specific because /usr/bin/python3 is often not the latest installed version of Python 3. In case of csdiff, the CI matrix was all green on Ubuntu and Fedora-based images, yet it failed on Gentoo Linux. So I was actually surprised the other way around. Has anyone tried to propose the patch upstream? If not, I can give it a try...
TL;DR: I did not try to upstream it, but I think it makes sense. Please give it a try :) Longer Story: At the time I wrote the patch I did not think that it would make sense to upstream it, as I was wrongly thinking that https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-util/cmake/files/cmake-3.9.0_rc2-FindPythonInterp.patch influences the python finding behavior. But that was wrong. The call > find_package(PythonInterp 3) gives the major version and causes in /usr/share/cmake/Modules/FindPythonInterp.cmake:75 -> list(APPEND _Python_NAMES python${PythonInterp_FIND_VERSION_MAJOR}) python3 to be searched. You could argue that it is a bug that > find_package(Python3) does not behave the same, as (only) the major version is given as well. FTR: I noticed this while trying to build VPP (https://github.com/FDio/vpp) on gentoo.
(In reply to Kamil Dudka from comment #7) > I think in this case Gentoo is specific because /usr/bin/python3 is often > not the latest installed version of Python 3. In case of csdiff, the CI > matrix was all green on Ubuntu and Fedora-based images, yet it failed on > Gentoo Linux. So I was actually surprised the other way around. > > Has anyone tried to propose the patch upstream? If not, I can give it a > try... Could you try please?
Upstream merge request: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8287
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/kde.git/commit/?id=282dbd873deafc6f3c956294ba741e080dac8ea6 commit 282dbd873deafc6f3c956294ba741e080dac8ea6 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2023-03-06 00:23:26 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2023-03-22 18:54:40 +0000 cmake.eclass: Set Python3_FIND_UNVERSIONED_NAMES FIRST See also: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8287 Bug: https://bugs.gentoo.org/835799 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/cmake.eclass | 1 + 1 file changed, 1 insertion(+)
FindBLAS.cmake has also always been patched for our downstream purpose and cmake.eclass (by history from cmake-utils.eclass) even has CMAKE_REMOVE_MODULES_LIST facility that removes incompatible bundled FindBLAS/FindLAPACK modules from package dirs.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a0e313b883d68d1f58c007a2b431a0d544dd6871 commit a0e313b883d68d1f58c007a2b431a0d544dd6871 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2023-03-06 00:23:26 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2023-03-26 12:34:44 +0000 cmake.eclass: Set Python3_FIND_UNVERSIONED_NAMES FIRST See also: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8287 Bug: https://bugs.gentoo.org/835799 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> eclass/cmake.eclass | 1 + 1 file changed, 1 insertion(+)
