The behaviour of the Python_ADDITIONAL_VERSIONS variable is described in Modules/FindPythonLibs.cmake as follows: # Set up the versions we know about, in the order we will search. Always add # the user supplied additional versions to the front. set(_Python_VERSIONS ${Python_ADDITIONAL_VERSIONS} 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0 1.6 1.5) But a Gentoo patch later unconditionally overwrites _Python_VERSIONS, rendering this useless. Reproducible: Always Steps to Reproduce: put this in a CMakeLists.txt and run CMake on it: project(PythonTest NONE) cmake_minimum_required(VERSION 2.6) set(Python_ADDITIONAL_VERSIONS 3.2) find_package(PythonLibs) Actual Results: it finds 2.7 (or whatever your system default is) Expected Results: For an unpatched CMake it will find 3.2 as requested by the user. I can't see any upstream bug for this, nor do I know which behaviour this is actually fixing. Without the Gentoo patch it would still find a 2.x version first (for everything up to CMake 2.8.7). I would vote for just deleting files/cmake-2.8.4-FindPythonLibs.patch
I suspect you will have a difficult time seeing this endorsed. The list 2.7 2.6 2.5 2.4 2.3 2.2 2.1 2.0 1.6 1.5 in the quoted file lists versions long abandoned and no longer in place in gentoo. While the build appears to work without the patch, your suggestion to remove tends to also make its initial inception now around 4 years ago an unnecessary inclusion. The patch overwrites _Python_VERSIONS and thus refains from listing absent versions. So does your suggested change. Peas in a pod.
Those list gives the versions that are searched for (in order). So if e.g. 2.6 is found this is fine, a present version 2.5 will then be ignored. But if I want to override this scanning as user this will simply not work in the Gentoo version. If the code would have been changed to find the system default first when the user does not specify a preferred version that would have been fine with me. But the current way just breaks something in CMake for no known reason.
(In reply to comment #2) > Those list gives the versions that are searched for (in order). So if e.g. > 2.6 is found this is fine, a present version 2.5 will then be ignored. But > if I want to override this scanning as user this will simply not work in the > Gentoo version. If the code would have been changed to find the system > default first when the user does not specify a preferred version that would > have been fine with me. But the current way just breaks something in CMake > for no known reason. It's unlikely that we will do this, because it breaks the integration into the Gentoo build system (the python eclasses need some way to tell the program which python version to build against, and configure should rather fail than build against a different version). If you disagree very strongly, please reopen and we'll discuss it at next meeting. However, imho we really need the patch.
I can't reopen, but: If you really want to do this right in the ebuilds then just call cmake as "cmake -D PYTHON_EXECUTABLE=/usr/bin/python ...". This would not break the usage of cmake outside of emerge while it still would do what you want to inside. Although I still don't think it's a good idea.
Created attachment 309863 [details, diff] proposed replacement patch This patch should work for both cases: if the user supplies Python_ADDITIONAL_VERSIONS it is respected, if not the system default python is asked for it's version to check that first before falling back to the default version list.
(In reply to comment #5) Gentoo users can directly affect locally active version of Python using EPYTHON variable: $ python -V Python 3.2.3+ $ EPYTHON="python2.7" python -V Python 2.7.3+ $ EPYTHON="python3.3" python -V Python 3.3.0a2+ $ EPYTHON="jython2.5" python -V Jython 2.5.1+ There is also a plan to include support for permanent user-specific setting of active version of Python in eselect-python. Current patch shouldn't be changed.
(In reply to comment #5) It seems that your patch causes that, with Python_ADDITIONAL_VERSIONS="2.7 2.6" and active version of Python set to 2.6, cmake would choose Python 2.7?
(In reply to comment #7) (Python 2.6 and 2.7 are installed.)
Of course it does, because that is exactly what the developer requested: search for version 2.7 first, then 2.6, then use whatever is found. If you guys could come up with a clear description of what should happen in your opinion then please go and file a CMake bug for this and it will be done if it is sensible. But please bear in mind that it is perfectly fine for a developer to say find_package(PythonLibs 3) or find_package(PythonLibs 3.2) and your current patch breaks this by returning a version 2.x library. That just can't work.
(In reply to comment #9) > But please bear in mind that it is perfectly fine for a developer to say > > find_package(PythonLibs 3) > > or > > find_package(PythonLibs 3.2) > > and your current patch breaks this by returning a version 2.x library. That > just can't work. Ebuild would use e.g. 'python_set_active_version 3' and /usr/bin/python would refer to a 3.* version (only in environment of ebuild process). It is required in Gentoo to use locally active version of Python, not a highest installed version.
The point is not what I as admin or ebuild sets as active version. The point is: if the developer of the software using CMake said "I want a python 2.x" (or 3.x) it's irrelevant what I have as system active python. Either I have a python of the requested major version (then this python must be returned and no other) or not (in this case find_package(PythonInterp) _must_ fail). Of course a find_package(PythonInterp 2) should respect which of possible multiple 2.x versions that I have installed is marked as active python 2 version. So for all patches you may think of there are some really simple tests: #1: find_package(PythonInterp 3) if (PYTHONINTERP_FOUND AND NOT PYTHON_VERSION_MAJOR EQUAL 3) message(FATAL_ERROR "patch broken") endif() #2: find_package(PythonInterp 2) if (PYTHONINTERP_FOUND AND NOT PYTHON_VERSION_MAJOR EQUAL 2) message(FATAL_ERROR "patch broken") endif() #3: find_package(PythonInterp 2.7) if (PYTHONINTERP_FOUND AND NOT PYTHON_VERSION_MAJOR EQUAL 2) message(FATAL_ERROR "patch broken") endif() if (PYTHON_VERSION_STRING VERSION_LESS 2.7) message(FATAL_ERROR "patch broken") endif() And if you replace "PythonInterp" by "PythonLibs" and do the version check according to the returned library yourself the same logic applied to that module, too.
Well... The correct patch would do the following: * check if the one particular currently selected Gentoo python matches the constraints from the upstream FindPythonLibs command * if yes, continue * if no, fail If we want to properly integrate CMake into the Gentoo python build system, we cannot give the FindPythonLibs macro any choice between different python versions. We have to succeed with the exact python version provided by Gentoo, or fail.
However, there is one thing that we could do: differentiate between builds inside and outside portage. Inside portage, we really *need* the behaviour from my last comment, because portage is iterating over supported python versions and must force the package to use the provided version. Outside portage, if someone compiles stuff on his own, the unpatched behaviour might make more sense.
So just call cmake -D PYTHON_LIBRARIES=/what/ever ... inside portage to force one version to be used. That doesn't need a patch whatsoever and it works for all CMake versions (and for all other libraries, too).
After discussing this issue with Rolf, he proposed this patch[1] which is currently in the overlay for testing. [1]: http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=blob;f=dev-util/cmake/files/cmake-2.8.10.2-FindPythonLibs.patch;h=53b395c35b2fb3d40aa519a7bdf5b14fc036f7eb;hb=9adb3b0f90aa914c43e07a4216b77d175627bfb5
(In reply to comment #15) In this patch: s/requries/requires/
Created attachment 335088 [details, diff] cmake-2.8.10.2-FindPythonInterp.patch Between cmake-2.8.7 and cmake-2.8.8 the following change was made in Modules/FindPythonInterp.cmake: + list(APPEND _Python_NAMES python${_PYTHON_FIND_MAJ_MIN} python${_PYTHON_FIND_MAJ}) ... +list(APPEND _Python_NAMES python) + # Search for the current active python version first -find_program(PYTHON_EXECUTABLE NAMES python) +find_program(PYTHON_EXECUTABLE NAMES ${_Python_NAMES}) So a similar Gentoo patch is also needed for Modules/FindPythonInterp.cmake. See attachment.
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=commit;h=9c83061f27fbcce3dea027d90276764e2d1ee14d
Thanks everyone, in CVS now. + 14 Apr 2013; Michael Palimaka <kensington@gentoo.org> + +cmake-2.8.10.2-r2.ebuild, +files/cmake-2.8.10.2-FindImageMagick.patch, + +files/cmake-2.8.10.2-FindPythonInterp.patch, + +files/cmake-2.8.10.2-FindPythonLibs.patch: + Revision bump to fix detection of python (bug #405181) and newer imagemagic + (bug #465898).
