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

Ray Donnelly mingw.android at gmail.com
Wed Sep 2 15:04:13 EDT 2015 

On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung <gvjung at gmail.com> wrote:
>> Would:
>> if (MSVC)
>> .. not be a better discriminator here? There's probably some people
>> who use MSYS2 in conjunction with MSVC compilers.
>>
> If they are doing that, won't they want the MSYS-installed version? If it's
> not found then the library
> reverts to the windows-registered version. It just gives the possible python
> living under the designated path the first crack.
>

Not necessarily; I mean, if MSVC is set, then CMake is going to use
MSVC and if it then finds our Python and links to it then you'll have
two c-runtimes in play .. not good .. so my vote is for "if MSVC" or
"if MINGW" with no reference to "MSYS" as that's just a general
purpose build environment.

> On Wed, Sep 2, 2015 at 4:13 AM, Ray Donnelly <mingw.android at gmail.com>
> wrote:
>>
>> 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