On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung <[email protected]> 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 <[email protected]> > wrote: >> >> On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >> wrote: >> >>> >> >>> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung <[email protected]> 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
