> > 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.
On Wed, Sep 2, 2015 at 4:13 AM, Ray Donnelly <mingw.andr...@gmail.com> wrote: > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung <gvj...@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 <gvj...@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.andr...@gmail.com> > >> wrote: > >>> > >>> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung <gvj...@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 > >> > >> > > >
-- 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