[CMake] Temp workaround for FindPythonLibs on Win7 64-bit

Adam Wolf adamwolf at feelslikeburning.com
Fri May 31 13:07:34 EDT 2013


If this gets looked at, maybe we can add my Linux FindPythonLibs
improvements at the same time? ;)

http://cmake.3232098.n2.nabble.com/FindPythonLibs-Bug-0013794-fix-td7584055.html

Adam Wolf

On Fri, May 31, 2013 at 11:54 AM, Jeremy Carter <jeremy at jeremycarter.ca> wrote:
> Hi,
>
> It has been established that the FindPythonLibs module fails to find
> 64-bit Python on Win7 64-bit, due to the fact that CMake can't read
> the 64-bit portion of the Windows Registry (and that's where the
> module looks to find Python). See:
> http://www.cmake.org/Bug/view.php?id=11303 .
>
> I made a temporary fix that requires the Python libs folder to be in
> the Windows Path. It hasn't been tested on platforms other than
> Windows 7 64-bit, so I'm sorry if it breaks things, and it's the first
> time I've posted on this list and also the first time I've patched
> anything, anyway, here's the patch I'm using until there's an official
> CMake fix:
>
> # ---------- begin patch ----------
>
> --- C:\Program Files (x86)\CMake
> 2.8\share\cmake-2.8\Modules\FindPythonLibs.cmake    2013-05-15
> 13:46:30 -0400
> +++ FindPythonLibs.cmake    2013-05-31 12:50:10 -0400
> @@ -31,6 +31,13 @@
>  #=============================================================================
>  # (To distribute this file outside of CMake, substitute the full
>  #  License text for the above reference.)
> +#=============================================================================
> +# This is a modified version of FindPythonLibs.cmake, hacked to support
> +# finding Python 64-bit on Windows 7 64-bit. It requires the Python libs
> +# directory to be in the Windows Path, since CMake is unable to read the
> +# 64-bit Windows Registry.
> +#
> +# Modified by Jeremy Carter (jeremy [at] jeremycarter [dot] ca) on 2013-05-31.
>
>  include(${CMAKE_CURRENT_LIST_DIR}/CMakeFindFrameworks.cmake)
>  # Search for the python framework on Apple.
> @@ -81,6 +88,11 @@
>
>  foreach(_CURRENT_VERSION ${_Python_VERSIONS})
>    string(REPLACE "." "" _CURRENT_VERSION_NO_DOTS ${_CURRENT_VERSION})
> +
> +  # Registry lookup doesn't work on Windows 7 64-bit with 64-bit Python.
> +  # Find Python in Windows Path instead.
> +  set(WINDOWS_PATH $ENV{Path})
> +
>    if(WIN32)
>      find_library(PYTHON_DEBUG_LIBRARY
>        NAMES python${_CURRENT_VERSION_NO_DOTS}_d python
> @@ -89,6 +101,7 @@
>        [HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs/Debug
>        [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
>        [HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
> +      ${WINDOWS_PATH} # Not tested. Added to look in Windows Path.
>        )
>    endif()
>
> @@ -102,6 +115,7 @@
>      PATHS
>        [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
>        [HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/libs
> +      ${WINDOWS_PATH} # Added to look in Windows Path.
>      # Avoid finding the .dll in the PATH.  We want the .lib.
>      NO_SYSTEM_ENVIRONMENT_PATH
>    )
> @@ -129,12 +143,16 @@
>      endforeach()
>    endif()
>
> +  # Added this because find_path() wasn't finding Python include dir
> from $ENV{Path} for some reason.
> +  get_filename_component(WINDOWS_PYTHON_LIB_PATH ${PYTHON_LIBRARY} PATH)
> +
>    find_path(PYTHON_INCLUDE_DIR
>      NAMES Python.h
>      PATHS
>        ${PYTHON_FRAMEWORK_INCLUDES}
>        [HKEY_LOCAL_MACHINE\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/include
>        [HKEY_CURRENT_USER\\SOFTWARE\\Python\\PythonCore\\${_CURRENT_VERSION}\\InstallPath]/include
> +      ${WINDOWS_PYTHON_LIB_PATH}/../include # The Python include
> directory is probably here.
>      PATH_SUFFIXES
>        python${_CURRENT_VERSION}mu
>        python${_CURRENT_VERSION}m
>
> # ---------- end patch ----------
>
> This might work in the short term, but CMake should probably be fixed
> so that this hack isn't necessary. I'm also open to suggestions on how
> this could be done better.
>
> Regards,
> Jeremy Carter
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake


More information about the CMake mailing list