Re: [cmake-developers] [PATCH] Fix a few issues in FindHDF5 module

[Brad King]

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

[Tim Gallagher]

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] FindZLIB module should find debug and, release variants

[Brad King]

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] [BUG] HINTS not correctly handled in find_program

[Brad King]

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] [PATCH] Fix a few issues in FindHDF5 module

[Tim Gallagher]

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] Adding Windows 10 support

[Brad King]

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

[Brad King]

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] FindPythonLibs repaired for MINGW -vs- WIN32 version confusion

[Ray Donnelly]

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 

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

[Greg Jung]

>
> 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 

[cmake-developers] CDash broken

[Gregor Jasny via cmake-developers]

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

[cmake-developers] [CMake 0015724]: Unable to specify iwyu options

[Mantis Bug Tracker]

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

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

[Greg Jung]

>
> 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 

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

[Greg Jung]

>
> 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] [CMake] Visual Studio - Ninja Generator

[James Johnston]

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.  

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

[Ray Donnelly]

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 

[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

[Mantis Bug Tracker]

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:

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

[Greg Jung]

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 

[cmake-developers] [BUG] HINTS not correctly handled in find_program

[CHEVRIER, Marc]

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

Re: [cmake-developers] [BUG] HINTS not correctly handled in find_program

[Brad King]

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

[Brad King]

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

[CHEVRIER, Marc]

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] Fix a few issues in FindHDF5 module

[Brad King]

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

[Brad King]

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] [Patch] Build Windows Phone/Store 8.1 on VS 2015

[Brad King]

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

[Tim Gallagher]

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