[cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion

Ray Donnelly mingw.android at gmail.com
Wed Sep 2 07:13:39 EDT 2015 

On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung <gvjung at gmail.com> wrote:
> To revive this issue, I show a comparison of the CMakeCache entries for
> cmake run from the same configuration, 1) cmake 3.2.3 with "old" PythonLibs
> .vs. 2) cmake 3.3.1 with the new FindPythonLibs.cmake.
>
> Cmake 1):
>
> # This is the CMakeCache file.
> # For build in directory: d:/mingw/msys32/tmp/bld-32
> # It was generated by CMake: D:/mingw/msys32/mingw32/bin/cmake.exe
>  [...]
> //Path to a program.
> PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe
>
> //Path to a file.
> PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7
>
> //Path to a library.
> PYTHON_LIBRARY:FILEPATH=E:/Python27/libs/libpython27.a
>
> //Dependencies for the target
> _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a;
>
> //Dependencies for the target
> plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;E:/Python27/libs/libpython27.a;
> //Path to CMake executable.
> CMAKE_COMMAND:INTERNAL=D:/mingw/msys32/mingw32/bin/cmake.exe
> //Details about finding PythonLibs
> FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[E:/Python27/libs/libpython27.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()]
>
>
> Cmake 2): cmake 3.3.1 run from outside the msys tree,using the patched
> FindPythonLibs.cmake
>
> # This is the CMakeCache file.
> # For build in directory: d:/mingw/msys32/tmp/bld-32
> # It was generated by CMake: D:/programs/CMake-3.3/bin/cmake.exe
> [...]
> //Path to a program.
> PYTHON_EXECUTABLE:FILEPATH=D:/mingw/msys32/mingw32/bin/python.exe
>
> //Path to a file.
> PYTHON_INCLUDE_DIR:PATH=D:/mingw/msys32/mingw32/include/python2.7
>
> //Path to a library.
> PYTHON_LIBRARY:FILEPATH=D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a
>
> //Dependencies for the target
> _plplotcmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a;
>
> //Dependencies for the target
> plplot_widgetmodule_LIB_DEPENDS:STATIC=general;plplot;general;D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a;
> //Path to CMake executable.
> CMAKE_COMMAND:INTERNAL=D:/programs/CMake-3.3/bin/cmake.exe
> //Details about finding PythonLibs
> FIND_PACKAGE_MESSAGE_DETAILS_PythonLibs:INTERNAL=[D:/mingw/msys32/mingw32/lib/libpython2.7.dll.a][D:/mingw/msys32/mingw32/include/python2.7][v2.7.10()]
>
>
> So, my windows-y python installation which is registered in the windows
> registry, interferes with my use of
> python until I replace the FindPythonLibs.cmake with the modified version.
> The new routine will find the registry  version in the same manner  if
> (WIN32 AND NOT (MINGW OR MSYS)).
>


Would:
if (MSVC)
.. not be a better discriminator here? There's probably some people
who use MSYS2 in conjunction with MSVC compilers.

>   Someone using this routine from windows (MSVC) or from a non-win32
> environment should have the same results as before.  If the MSYS user only
> has a separate windows-based registry-registered python
> and there is nothing found in the unix-style searches, the previous behavior
> of providing answers from the registry-based installation kicks in.
>
> Regards, Greg
>
> On Fri, Aug 7, 2015 at 4:05 PM, Greg Jung <gvjung at gmail.com> wrote:
>>>
>>> >   I have two changes in FindPythonLibs that should make for less
>>> > failure in
>>> > the MINGW/MSYS camp.
>>>
>>> While I support this stuff, I think for it to not
>>> break other people (who use either mingw.org/MinGW-w64 compilers or
>>> the old MSYS with 'normal' Windows CPython),
>>
>>
>> If there is not a python installation to be found in the mingw path, the
>> patched routine will drop into the registry search. which will look
>> exactly like previous.
>>
>>> I think you explicitly mean the MSYS2 camp here. We have our own
>>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a
>>> Linux-y layout.
>>
>>
>>   I've been running with msys2, and lately I've done a lot of test-running
>> of plplot using plain vanilla
>> CMake without the patches I used to think were needed.   I found that from
>> the CMake point of view,
>> msys1 or msys2 is a distinction without a difference.
>>
>>>
>>> CMake needs to be able to
>>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a
>>> patch making that distinction be acceptable to CMake?
>>
>> I have used CMakeFindMSYSmake and CMakeFindUnixMake to set a variable
>> designating
>> what /usr translates to:
>> #
>> # the variable MSYS_USR_PATH is here  created for use
>> # where the /usr provided by an MSYS app needs to be translated for
>> Windows.
>> #
>> unset(_BIN)
>> find_path( _BIN   msys-1.0.dll   NAMES msys-2.0.dll         HINTS ENV PATH
>>    NO_DEFAULT_PATH)
>> if(_BIN)
>>   set(MSYS 1)
>> find_path( MSYS_USR_PATH bin   PATHS ${_BIN}/../    NO_DEFAULT_PATH)
>>
>>    mark_as_advanced(MSYS_USR_PATH)
>>    message(STATUS "<CMakeUnixFindMake>: MSYS dll found on
>> ${MSYS_USR_PATH}")
>> endif()
>> unset(_BIN)
>>
>>
>>
>>
>> On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly <mingw.android at gmail.com>
>> wrote:
>>>
>>> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung <gvjung at gmail.com> wrote:
>>> > Hi there,
>>> >   A patch for review:
>>> >
>>> >   I have two changes in FindPythonLibs that should make for less
>>> > failure in
>>> > the MINGW/MSYS camp.
>>>
>>> I think you explicitly mean the MSYS2 camp here. We have our own
>>> Pythons (4 of them, 2 native and 2 cygwin-y) all of which use a
>>> Linux-y layout. While I support this stuff, I think for it to not
>>> break other people (who use either mingw.org/MinGW-w64 compilers or
>>> the old MSYS with 'normal' Windows CPython), CMake needs to be able to
>>> identify MSYS2 distinctly from both MINGW and MSYS first. Would a
>>> patch making that distinction be acceptable to CMake?
>>>
>>> > 1. Distinguish mingw and win32.  Avoid the registry lookup.
>>> > if(WIN32) => if(WIN32 AND NOT (MINGW OR MSYS)) for the DEBUG library
>>> > search,
>>> > a full unix-style find_library call without reference to possible
>>> > registry
>>> > entries.
>>> >
>>> > +    NAMES
>>> > +    python${_CURRENT_VERSION_NO_DOTS}
>>> > +    python${_CURRENT_VERSION}mu
>>> > +    python${_CURRENT_VERSION}m
>>> > +    python${_CURRENT_VERSION}u
>>> > +    python${_CURRENT_VERSION}
>>> > +#
>>> > +    NAMES_PER_DIR
>>> > +    # Avoid finding the .dll in the PATH.  We want the .lib.
>>> > +# The NAMES_PER_DIR above should allow the library to be found where
>>> > it was
>>> > desired
>>> > +# in the prioritized location of PATH - cmake V3.3 behavior;
>>> > +#    NO_SYSTEM_ENVIRONMENT_PATH works counter to cmake-3.3 improvement
>>> > where CMake will look into path.
>>> > +#
>>> > +  )
>>> > +endif()
>>> >
>>> > 2. NAMES_PER_DIR replaces NO_SYSTEM_ENVIRONMENT_PATH to modify the
>>> > search
>>> > such that windows/system32/python27.dll
>>> > (for instance) is not picked up before finding the proper library under
>>> > <path component>/lib
>>> >
>>> >
>>> >   Instead of throwing all of the possible locations into a single
>>> > find_library(), for WIN32+MINGW builds this may latch into a windows'
>>> > python.
>>> > This is not an issue when CMake is run from /MINGW.
>>> > CMake-3.3.0 (and above) can use PATH to discover targets of
>>> > find_library,
>>> > allowing
>>> > a user with several MINGW installations to use a single cmake (and
>>> > cmake-gui) instead of
>>> > installing several copies for each mingw to be built with.  Unless the
>>> > find_path or
>>> > find_library uses "NO_SYSTEM_ENVIRONMENT_PATH" which kills the new
>>> > feature.
>>> >   Even though /mingw32/bin is frontmost in the path,
>>> > windows/system32/python27.dll
>>> > was latched onto because the name matches earlier in the NAMES list
>>> > than
>>> > python2.7.
>>> > to avoid this all of the names are tested as the direcftories are
>>> > presented,
>>> > this via the
>>> > NAMES_PER_DIR qualifier.
>>> >
>>> >    This makes is possible for me to run builds using Cmake-gui without
>>> > installing cmake-gui
>>> > in /mingw32/bin (and qt5 along with it!).
>>> >
>>> > Regards,
>>> > Greg
>>> >
>>> > --
>>> >
>>> > Powered by www.kitware.com
>>> >
>>> > Please keep messages on-topic and check the CMake FAQ at:
>>> > http://www.cmake.org/Wiki/CMake_FAQ
>>> >
>>> > Kitware offers various services to support the CMake community. For
>>> > more
>>> > information on each offering, please visit:
>>> >
>>> > CMake Support: http://cmake.org/cmake/help/support.html
>>> > CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> > CMake Training Courses: http://cmake.org/cmake/help/training.html
>>> >
>>> > Visit other Kitware open-source projects at
>>> > http://www.kitware.com/opensource/opensource.html
>>> >
>>> > Follow this link to subscribe/unsubscribe:
>>> > http://public.kitware.com/mailman/listinfo/cmake-developers
>>
>>
>

More information about the cmake-developers mailing list