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
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
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
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
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
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
>
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(
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
>
>
> 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
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:
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15724
==
Reported By:Jeremie Delaitre
Assigned To:
>
> 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
>
> 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
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
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):
>
> #
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15723
==
Reported By:Adam Strzelecki
Assigned To:
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
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
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:
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
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
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,
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
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
--
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
25 matches
Mail list logo