[cmake-developers] [CMake 0015724]: Unable to specify iwyu options
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15724 == Reported By:Jeremie Delaitre Assigned To: == Project:CMake Issue ID: 15724 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2015-09-03 11:41 NZST Last Modified: 2015-09-03 11:41 NZST == Summary:Unable to specify iwyu options Description: I am trying the new include-what-you-use support of CMake (3.3.0). It is working fine when I just run iwyu, but I'd like to specify some additional options (most importantly "-Xiwyu --mapping-file=..."). I could not find a way to make it work. I tried to specify the options with: set(CMAKE_CXX_INCLUDE_WHAT_YOU_USE "/usr/bin/iwyu -Xiwyu --mapping-file=...") without success (I tried other iwyu options too). The command line generated looks like: FAILED: /usr/bin/cmake -E __run_iwyu --iwyu="/usr/bin/include-what-you-use -Xiwyu --mapping_file=" -- /g++ --sysroot= Error running '/usr/bin/include-what-you-use -Xiwyu --mapping_file=""': No such file or directory I tried to change the command by hand (e.g. moving the iwyu option after the "--") but it did not work neither. Any hint? Additional Information: - CMake 3.3.0 - include-what-you-use 0.3 based on clang version 3.5.0 (tags/RELEASE_350/final) == Issue History Date ModifiedUsername FieldChange == 2015-09-03 11:41 Jeremie DelaitreNew Issue == -- 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
[cmake-developers] CDash broken
Hello, from time to time the CMake Dashboard at http://www.cdash.org/CDash/index.php?project=CMake is very slow. Right now I cannot access it at all. Does anyone know what's wrong? Thanks, Gregor -- 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
Re: [cmake-developers] [CMake] Visual Studio - Ninja Generator
Recently I have wondered if it would be useful if the Visual Studio generators in CMake were refactored somewhat (to what degree, I am not sure). Not that I have time to work on it right now, and I have not studied this section of CMake code in detail, so I may be a little off base with some of this - please bear with me... Example: instead of Visual C++ 2008 generator, we have a back-end generator for VC++2005/2008 projects. Then instead of Visual C++ 2010 generator, we have back-end MSBuild generator. (Perhaps the back-end generators could be tools reused by existing normal "Visual Studio 2008" CMake generators and so on). If a VC++ 2008 project is needed, the back-end VC2008 generator is used. If a C# 2008 project is needed, the back-end MSBuild generator is used. There are some use cases: * The example given by Guillaume Dumont. In this case, it would be useful to have Visual Studio available as an "Extra" CMake generator. For example, specification of "Visual Studio 2015 - Ninja" (much like how you can do "CodeBlocks - Ninja" today, etc.). This would run Ninja in background to do the building, while retaining the IDE. Presumably this generator will have to share a lot of code with the regular VS2015 generator. I would be very happy if this feature existed and would use it tomorrow. The MSBuild system has serious concurrency issues resulting in serious over/undersubscription. * Recently there have been mailings from Michael Stuermer about adding C# as a language CMake. Another feature I would use tomorrow if it worked well. I skimmed through some of the commits to see how he is doing it; while helpful, I think there are some shortcomings that may not be easy to fix without some preliminary work related to Visual Studio project generation. IIRC the author's code works for generating Visual C# 2013 projects using the Visual C++ 2013 generator, but that's it. Ideally you really want to be able to: (1) build C# 2005/2008 projects, (2) use more efficient tools like Ninja. And to do that I think requires decoupling the language from the project file generator. Right now, CMake makes the assumption that the language project file format of each VS version is basically identical (e.g. all MSBuild, or not), and this is not true. To elaborate on the C# example some more, suppose the user wants to generate a Visual Studio 2008 solution. So they pick the normal VS2008 generator. In this situation: (1) C++ projects need to be generated using the C++ project generation code in the existing VS2008 generator, (2) C# projects need to be generated using an MSBuild generator, which is very different from the VS2008 C++ project format - i.e. these projects will need to use code from the current VC++ 2010 generator. Summary: to do this right for VS2005/2008 requires using significant code from two different existing CMake generators: some code from existing VS2005/2008 generator, and some code from VS2010 generator. The Ninja C# example is also tricky to get right. It may not be practical to invoke csc.exe directly; there might be other tools involved and a lot of how things "should" work is currently largely undocumented and hidden away inside of the system MSBuild .targets files. An example is resolving assembly references. If you pass in an unqualified assembly reference directly to csc.exe, the compiler searches for the assembly in various directories using rules defined here: https://msdn.microsoft.com/en-us/library/s5bac5fx.aspx - however, these rules do not match what actually happens when you add an assembly reference to a Visual C# project and compile it with MSBuild.exe. In that situation, MSBuild.exe resolves assemblies using a COMPLETELY DIFFERENT set of rules than csc.exe, and then passes absolute paths to csc.exe. The correct rules to use are probably the ones inside of Microsoft.Common.targets file, which doesn't seem to be documented in MSDN, and only documented by a comment in the XML: For example, I found when building with MSBuild, absolute paths to assemblies in "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5" were used, and this location is not used if I pass an unqualified path directly to csc.exe and use csc's rules. This blog post suggests that these new assembly resolution rules are very important: http://blogs.msdn.com/b/msbuild/archive/2007/04/12/new-reference-assemblies-location.aspx --- Therefore, I have to conclude that there are only two valid ways of compiling a C# project from CMake: a. Reverse engineer the MSBuild files for each Visual Studio project and teach CMake largely undocumented rules for things like assembly resolution and whatever else we run into. If it's just assembly resolution it might be manageable, but I fear it's a rabbit hole... b. Have CMake generate a C# project file for each C# project - even when using non-VS generators like Ninja. Th
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
> > On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung 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. If MSVC is the only compiler that is capable of using the registered python, then replacing if(WIN32 AND NOT (MINGW OR MSYS)) with if(MSVC) and if((NOT WIN32) OR (MINGW OR MSYS)) replaced by if(NOT MSVC) would definitely be a better read. On Wed, Sep 2, 2015 at 12:04 PM, Ray Donnelly wrote: > On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung 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 > > wrote: > >> > >> On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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) > >> .
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
> > As a reminder, another branch of this discussion is pending over here: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13948/focus=13982 That devolved into another issue. This also applies to msys-1 with a targetted python installation. I don't think there are any "structural" issues in running the mingw-w64/msys2 system using "MSYS Makefiles". The cmake adapted to running posix-mode msys2 is another matter. On Wed, Sep 2, 2015 at 6:02 AM, Brad King wrote: > On 09/02/2015 07:13 AM, Ray Donnelly wrote: > > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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. > > As a reminder, another branch of this discussion is pending over here: > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13948/focus=13982 > > -Brad > > -- 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
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
> > 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 wrote: > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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 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 CMakeFindMSYS
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On Wed, Sep 2, 2015 at 7:59 PM, Greg Jung 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 > wrote: >> >> On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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 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. >> >> >>
Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program
On 09/02/2015 09:09 AM, CHEVRIER, Marc wrote: > On 02/09/15 14:58, "Brad King" wrote: >> On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote: >>> find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) >> >> find_program (MY_EXE >> NAMES my_exe >> HINTS PATH1 PATH2 PATH3 >> ) > Same problem. HINTS which are also defined in the environment > variable PATH are ignored. I'm having trouble reproducing this. Please provide a tarball with a full CMakeLists.txt and supporting files that demonstrate this. You can "set(ENV{PATH} ...)" if needed. Thanks, -Brad -- 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
Re: [cmake-developers] FindZLIB module should find debug and, release variants
On 09/01/2015 03:56 PM, Michael Scott wrote: > The attached patch should maintain that compatibility now. If > ZLIB_LIBRARY is set manually, then it won't try and find the library and > it'll set the ZLIB_LIBRARIES and IMPORTED_LOCATION variables using the > provided ZLIB_LIBRARY variable (if the library was found). Thanks. Applied: FindZLIB: Find debug and release variants separately http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11097f52 -Brad -- 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
Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module
On 09/02/2015 11:35 AM, Tim Gallagher wrote: > it looks like this work supersedes that patch. Okay, thanks for checking! -Brad -- 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
Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module
Good catch! The version I patched against didn't have the HDF5_Fortran_HL_LIBRARY_NAMES_INIT variable at the time. There was only the HDF5_Fortran_LIBRARY_NAMES_INIT variable. I'm not sure which version of the code my original patch was against after this long. However, since I submitted my ticket in July of 2011, Will committed support for the HL libraries in August of 2011 with commit http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad218e4 , which added the HDF5_Fortran_HL_LIBRARY_NAMES_INIT variable. Perhaps that commit was intended to reference/fix my ticket? At any rate, since what I submitted wouldn't apply against the current version, it looks like this work supersedes that patch. Tim - Original Message - From: "Brad King" To: "tim gallagher" Cc: cmake-developers@cmake.org, "Paul Romano" Sent: Wednesday, September 2, 2015 11:16:34 AM Subject: Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module On 09/02/2015 11:07 AM, Tim Gallagher wrote: > It looks like the 2nd commit you linked to does the same thing as > my patch (add hdf5hl_fortran to the Fortran library list). Not quite. It is: > -set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran > +set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran hdf5_hl One can see hdf5hl_fortran was already in that list. Your patch was: > -set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran > ${HDF5_C_LIBRARY_NAMES_INIT} ) > +set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran hdf5hl_fortran > ${HDF5_C_LIBRARY_NAMES_INIT} ) which adds it to a different list, though perhaps the wrong one since it is not for the _HL component. -Brad -- 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
Re: [cmake-developers] [Patch] Adding Windows 10 support
On 09/01/2015 05:19 PM, Gilles Khouzam wrote: > For VS_DEFAULT_TARGET_PLATFORM_VERSION, what I'm trying to > achieve is almost an internal property that is used for the > try_compile phase. Since the generator is not used in that > scenario, the project is using the template from > Modules/CompilerId/VS-10.vcxproj.in. In that case, we need to set > the tag for the WindowsTargetPlatformVersion. During the > generation, I query for the latest SDK version in the > GlobalGenerator and set the VS_DEFAULT_TARGET_PLATFORM_VERSION > property that is then used in CMakeDetermineCompilerId.cmake to > set the variable that the template uses in the Windows 10 case. The generator *is* used for try_compile calls. The template in Modules/CompilerId/VS-10.vcxproj.in is used *only* for the compiler identification step which occurs before we have enough information to do a full try_compile. The compiler id step does need special handling to set this value, but it should be based on however the value is determined for the generator normally. As discussed in http://www.cmake.org/Bug/view.php?id=15670 the SDK for the latest Windows version may not be the proper default choice. Perhaps it should be the SDK for the host machine's version of Windows to make sure we don't use APIs that cannot run on the current machine. IIRC this is the default on OS X with CMAKE_OSX_SYSROOT. Unlike CMAKE_OSX_SYSROOT, which is used by all generators on OS X, the WindowsTargetPlatformVersion value is something only for the VS IDE generators. In any command-line build we expect the INCLUDE/LIB environment variables to already be set to the proper location. Therefore we need to define a way to set the WindowsTargetPlatformVersion only for VS IDE generators since they generate the environment in which to run the toolchain. CMAKE_GENERATOR_TOOLSET and CMAKE_GENERATOR_PLATFORM are existing options with generator-specific behavior. For VS they set and , respectively. There is quite a bit of C++-side infrastructure to propagate these values to all the right places (and honor cmake -T and -A options on the command line). I'd rather not have something quite so heavyweight for WindowsTargetPlatformVersion because it is a pretty narrow case that should not need a dedicated command-line option and won't be meaningful to other generators. We could simply define a CMAKE_VS_TARGET_PLATFORM_VERSION variable that is used to initialize VS_TARGET_PLATFORM_VERSION target properties (see SetPropertyDefault calls in the source). Then the generator can look just at the target property. If not set it should choose a default based on the current host version of Windows as discussed above. Then we just need to teach cmCoreTryCompile to propagate this setting. The above-linked issue also mentions that TargetFrameworkVersion may need similar infrastructure. -Brad -- 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
Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module
On 09/02/2015 11:07 AM, Tim Gallagher wrote: > It looks like the 2nd commit you linked to does the same thing as > my patch (add hdf5hl_fortran to the Fortran library list). Not quite. It is: > -set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran > +set( HDF5_Fortran_HL_LIBRARY_NAMES_INIT hdf5hl_fortran hdf5_hl One can see hdf5hl_fortran was already in that list. Your patch was: > -set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran > ${HDF5_C_LIBRARY_NAMES_INIT} ) > +set( HDF5_Fortran_LIBRARY_NAMES_INIT hdf5_fortran hdf5hl_fortran > ${HDF5_C_LIBRARY_NAMES_INIT} ) which adds it to a different list, though perhaps the wrong one since it is not for the _HL component. -Brad -- 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
Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module
It looks like the 2nd commit you linked to does the same thing as my patch (add hdf5hl_fortran to the Fortran library list). So it should work fine and my patch is no longer needed. I will have to see if I have a project that still uses the HL library, it's been 4 years since I think I've used it. So it wasn't an outstanding issue for me -- I just wanted to help close out an open issue if they were related! Thanks, Tim - Original Message - From: "Brad King" To: "Tim Gallagher" Cc: cmake-developers@cmake.org, "Paul Romano" Sent: Wednesday, September 2, 2015 10:59:34 AM Subject: Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module On 09/02/2015 10:44 AM, Tim Gallagher wrote: > I haven't followed the discussion on this issue, but how does it > relate to the ticket I opened awhile ago? > > http://public.kitware.com/Bug/view.php?id=12316 Sorry we missed that patch. > It looks like it may supersede or fix that issue? If so, I guess > the issue can be closed! I've updated the issue with links to this thread and the fixes so far. Please check if it resolves the problem and comment in the issue. Otherwise we can look at taking your patch from there too. Thanks, -Brad -- 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
Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module
On 09/02/2015 10:44 AM, Tim Gallagher wrote: > I haven't followed the discussion on this issue, but how does it > relate to the ticket I opened awhile ago? > > http://public.kitware.com/Bug/view.php?id=12316 Sorry we missed that patch. > It looks like it may supersede or fix that issue? If so, I guess > the issue can be closed! I've updated the issue with links to this thread and the fixes so far. Please check if it resolves the problem and comment in the issue. Otherwise we can look at taking your patch from there too. Thanks, -Brad -- 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
Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module
I haven't followed the discussion on this issue, but how does it relate to the ticket I opened awhile ago? http://public.kitware.com/Bug/view.php?id=12316 It looks like it may supersede or fix that issue? If so, I guess the issue can be closed! Tim - Original Message - From: "Brad King" To: "Paul Romano" Cc: cmake-developers@cmake.org Sent: Wednesday, September 2, 2015 10:19:52 AM Subject: Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module On 08/31/2015 10:45 PM, Paul Romano wrote: > Here is a set of three patches that breaks out the changes. Thanks. I've applied the first two: FindHDF5: Fix support for HL and Fortran_HL components http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19e7db07 FindHDF5: Add hdf5_hl to list of libraries to search for Fortran_HL http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f7f73df1 I've also drafted a find_program NAMES_PER_DIR option, merged to 'next' for testing here: Merge topic 'find_program-NAMES_PER_DIR' into next http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2bc3f46b Please look at basing work on commit 8ea7611b to use NAMES_PER_DIR for FindHDF5. Of course HDF5_PREFER_PARALLEL may also still be needed in case both executables sit in the same directory. Thanks, -Brad -- 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
Re: [cmake-developers] [Patch] Build Windows Phone/Store 8.1 on VS 2015
On 09/01/2015 05:09 PM, Gilles Khouzam wrote: > Fixing issue: > https://public.kitware.com/Bug/view.php?id=15662 Thanks, applied and merged to 'next' for testing: VS: Find Desktop SDK for current VS version (#15662) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b8b9168 -Brad -- 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
Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module
On 08/31/2015 10:45 PM, Paul Romano wrote: > Here is a set of three patches that breaks out the changes. Thanks. I've applied the first two: FindHDF5: Fix support for HL and Fortran_HL components http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=19e7db07 FindHDF5: Add hdf5_hl to list of libraries to search for Fortran_HL http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f7f73df1 I've also drafted a find_program NAMES_PER_DIR option, merged to 'next' for testing here: Merge topic 'find_program-NAMES_PER_DIR' into next http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2bc3f46b Please look at basing work on commit 8ea7611b to use NAMES_PER_DIR for FindHDF5. Of course HDF5_PREFER_PARALLEL may also still be needed in case both executables sit in the same directory. Thanks, -Brad -- 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
Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program
Same problem. HINTS which are also defined in the environment variable PATH are ignored. On 02/09/15 14:58, "Brad King" wrote: >On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote: >> find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) > >Try it with > > find_program (MY_EXE > NAMES my_exe > HINTS PATH1 PATH2 PATH3 > ) > >-Brad > -- 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
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On 09/02/2015 07:13 AM, Ray Donnelly wrote: > On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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. As a reminder, another branch of this discussion is pending over here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13948/focus=13982 -Brad -- 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
Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program
On 09/02/2015 05:31 AM, CHEVRIER, Marc wrote: > find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) Try it with find_program (MY_EXE NAMES my_exe HINTS PATH1 PATH2 PATH3 ) -Brad -- 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
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
On Wed, Sep 2, 2015 at 10:33 AM, Greg Jung 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 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 ": MSYS dll found on >> ${MSYS_USR_PATH}") >> endif() >> unset(_BIN) >> >> >> >> >> On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly >> wrote: >>> >>> On Fri, Aug
[cmake-developers] [CMake 0015723]: Regression: FindCUDA fails for C++ only projects in CMake 3.3.1 due find_package(Threads), while it works well in CMake 3.2.3
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15723 == Reported By:Adam Strzelecki Assigned To: == Project:CMake Issue ID: 15723 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2015-09-02 06:31 EDT Last Modified: 2015-09-02 06:31 EDT == Summary:Regression: FindCUDA fails for C++ only projects in CMake 3.3.1 due find_package(Threads), while it works well in CMake 3.2.3 Description: CUDA language is C++ superset, so developers may prefer using C++ only project together with CUDA. FindCUDA already supports such case (1) when neither CUDA_HOST_COMPILER nor CMAKE_C_COMPILER is defined, just skips adding --ccbin. Another case (2) is that user defined its own CUDA_HOST_COMPILER that is different than CMAKE_C_COMPILER, then custom host compiler is passed to --ccbin. The problem is that recently CUDA_USE_STATIC_CUDA_RUNTIME (default ON) started calling find_package(Threads REQUIRED) that tries to lookup pthread using CMAKE_C_COMPILER which is invalid in both cases (1) (2). However I don't see any clear solution here. I understand that linking CUDA static rt requires pthread linkage, but maybe we should just check if current linker can either link -lpthread or -pthread, rather falling back to C compiler that may be undefined for the project? Steps to Reproduce: # CMakeList.txt cmake_minimum_required(VERSION 2.6) project(OnlyCXXCUDA CXX) find_package(CUDA) $ cmake . -- The CXX compiler identification is AppleClang 7.0.0.759 -- Check for working CXX compiler: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- Check for working CXX compiler: /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Looking for include file pthread.h CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/CheckIncludeFiles.cmake:79 (try_compile): Unknown extension ".c" for file /Users/ono/Documents/Bugs/CMake/FindCUDA/CMakeFiles/CMakeTmp/CheckIncludeFiles.c try_compile() works only for enabled languages. Currently these are: CXX See project() command to enable other languages. Call Stack (most recent call first): /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindThreads.cmake:123 (CHECK_INCLUDE_FILES) /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindCUDA.cmake:741 (find_package) CMakeLists.txt:3 (find_package) -- Looking for include file pthread.h - not found CMake Error at /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find Threads (missing: Threads_FOUND) Call Stack (most recent call first): /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE) /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindThreads.cmake:204 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) /Applications/CMake.app/Contents/share/cmake-3.3/Modules/FindCUDA.cmake:741 (find_package) CMakeLists.txt:3 (find_package) -- Configuring incomplete, errors occurred! See also "/Users/ono/Documents/Bugs/CMake/FindCUDA/CMakeFiles/CMakeOutput.log". See also "/Users/ono/Documents/Bugs/CMake/FindCUDA/CMakeFiles/CMakeError.log". == Issue History Date ModifiedUsername FieldChange == 2015-09-02 06:31 Adam StrzeleckiNew Issue == -- 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.kitw
Re: [cmake-developers] [PATCH] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion
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)). 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 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 ": MSYS dll found on > ${MSYS_USR_PATH}") > endif() > unset(_BIN) > > > > > On Fri, Aug 7, 2015 at 2:25 AM, Ray Donnelly > wrote: > >> On Fri, Aug 7, 2015 at 7:58 AM, Greg Jung 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
[cmake-developers] [BUG] HINTS not correctly handled in find_program
Hi, I discovered a curious problem regarding handling of argument HINTS. If I use the following command: find_program (MY_EXE my_exe HINTS PATH1 PATH2 PATH3) And my_exe is available in various paths. In this case, paths specified in HINTS AND also defined in environment variable PATH are ignored ! For example, with environment variable PATH=PATH1:PATH2, find_program will gives PATH3/my_exe as result. This problem occurs on Windows and Linux (at least) in versions 3.2.1 and 3.3.1. The behavior is correct with version 3.1.3. Marc -- 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