Re: [CMake] Find Vulkan on 32 bit builds
Hi,
I've filed a bug report with LunarG. The issue is here:
https://vulkan.lunarg.com/issue/view/587509589ab0fa2af19621ca
In the meantime, I'll prepare an update which can handle /lib, /lib32
and adds the NO_DEFAULT_PATH in case of 32-bit Windows. Thanks for the
report!
Cheers,
Matthäus
Am 10.01.2017 um 17:11 schrieb Saad Khattak:
> That makes sense! Removing the variable from PATH does indeed fix the issue.
>
> It is not a blocking issue for me.
>
> I agree that this is a Vulkan packaging issue. However, since you are
> looking for $ENV{VULKAN_SDK} in the find module and assuming it exists,
> then it 'should' override the other path? I do see what you are saying
> in that this now becomes a special case just because Vulkan SDK didn't
> package the libs properly.
>
> Thanks Matthäus and Andreas for your help!
>
> On Tue, Jan 10, 2017 at 10:38 AM Matthäus G. Chajdas <cm...@anteru.net
> <mailto:cm...@anteru.net>> wrote:
>
> Hi,
>
> the problem here is that the Vulkan SDK helpfully adds
> D:/VulkanSDK/1.0.37.0/Bin <http://1.0.37.0/Bin> into PATH, while the
> Vulkan module dutifully
> searches Bin on x64 and Bin32 on x86. However, because /Bin is in the
> PATH, and because the libraries for both architectures are named the
> same, it will pick up the one from /Bin first (as the search order for
> find_library is system paths first, and PATHS/HINTS variable second).
>
> There's a couple of ways to fix this; for instance, on Windows I could
> use NO_DEFAULT_PATH on the find_library call and that would resolve the
> issue. The main reason why I haven't done this yet is because I think
> that's a packaging bug in the Vulkan SDK side which I was going to
> report there (I want to ask them to move the libraries into a lib/
> subfolder, and ideally use different names for different architectures.)
>
> For now the easiest workaround is to remove the path to the Vulkan SDK
> from PATH; and I'll try to report this with the LunarG SDK and see how
> far I get there. If this doesn't work out, I'll guess I'll have to
> special-case the find_library call to ignore default paths on Windows &
> 32-bit only.
>
> If this is a blocker for you, please file an issue and I'll fix it on
> the CMake end before even starting the discussion with LunarG.
>
> Cheers,
> Matthäus
>
> Am 08.01.2017 um 14:36 schrieb Andreas Naumann:
> > Hello,
> > Am 08.01.2017 um 07:22 schrieb Saad Khattak:
> >> Hello,
> >>
> >> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
> >> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
> >> variables both point to the "Bin" folder for the Vulkan installation
> >> instead of the "Bin32" folder.
> >>
> >> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
> >> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
> >> mistake setting up. The message does indeed print confirming that my
> >> pointer size is 4 and thus the current toolchain selected is 32 bit.
> >>
> >> What's perplexing is that when I do a MESSAGE(STATUS
> >> ${Vulkan_LIBRARY}) the path is:
> >>
> >>
> >> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib
> <http://1.0.37.0/Bin/vulkan-1.lib> <http://1.0.37.0/Bin/vulkan-1.lib>
> >>
> >>
> >> instead of
> >>
> >>
> >> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
> <http://1.0.37.0/Bin32/vulkan-1.lib>
> >> <http://1.0.37.0/Bin32/vulkan-1.lib>
> >>
> >>
> >> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is
> CMake
> >> ignoring 32?
> >>
> > You should think the other way around: Why should cmake look in a
> > special directory, when it finds a library with an appropriate name
> > before this one?
> > This decision should be in the corresponding FindVulkan.cmake,
> i.e. the
> > corresponding find_library call should be constrained to
> > ${VULKAN_DIR}/Bin32 in the 32bit case.
> >>
> >>
> >
> > Regards,
> > Andreas
>
--
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
Re: [CMake] Find Vulkan on 32 bit builds
Hi,
the problem here is that the Vulkan SDK helpfully adds
D:/VulkanSDK/1.0.37.0/Bin into PATH, while the Vulkan module dutifully
searches Bin on x64 and Bin32 on x86. However, because /Bin is in the
PATH, and because the libraries for both architectures are named the
same, it will pick up the one from /Bin first (as the search order for
find_library is system paths first, and PATHS/HINTS variable second).
There's a couple of ways to fix this; for instance, on Windows I could
use NO_DEFAULT_PATH on the find_library call and that would resolve the
issue. The main reason why I haven't done this yet is because I think
that's a packaging bug in the Vulkan SDK side which I was going to
report there (I want to ask them to move the libraries into a lib/
subfolder, and ideally use different names for different architectures.)
For now the easiest workaround is to remove the path to the Vulkan SDK
from PATH; and I'll try to report this with the LunarG SDK and see how
far I get there. If this doesn't work out, I'll guess I'll have to
special-case the find_library call to ignore default paths on Windows &
32-bit only.
If this is a blocker for you, please file an issue and I'll fix it on
the CMake end before even starting the discussion with LunarG.
Cheers,
Matthäus
Am 08.01.2017 um 14:36 schrieb Andreas Naumann:
> Hello,
> Am 08.01.2017 um 07:22 schrieb Saad Khattak:
>> Hello,
>>
>> When I run "find_package(VULKAN)" in a CMakeLists for a Visual Studio
>> 2015 32-bit project, the ${Vulkan_LIBRARY} and ${Vulkan_LIBRARIES}
>> variables both point to the "Bin" folder for the Vulkan installation
>> instead of the "Bin32" folder.
>>
>> I looked at the FindVulkan.cmake module and even put MESSAGE(STATUS
>> ...) on the "elseif(CMAKE_SIZEOF_VOID_P EQUAL 4)" to see if I made a
>> mistake setting up. The message does indeed print confirming that my
>> pointer size is 4 and thus the current toolchain selected is 32 bit.
>>
>> What's perplexing is that when I do a MESSAGE(STATUS
>> ${Vulkan_LIBRARY}) the path is:
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin/vulkan-1.lib
>>
>>
>> instead of
>>
>>
>> D:/VulkanSDK/1.0.37.0/Bin32/vulkan-1.lib
>>
>>
>>
>> It makes no sense. Line 47 of FindVulkan.cmake has Bin32. Why is CMake
>> ignoring 32?
>>
> You should think the other way around: Why should cmake look in a
> special directory, when it finds a library with an appropriate name
> before this one?
> This decision should be in the corresponding FindVulkan.cmake, i.e. the
> corresponding find_library call should be constrained to
> ${VULKAN_DIR}/Bin32 in the 32bit case.
>>
>>
>
> Regards,
> Andreas
--
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
Re: [cmake-developers] [PATCH] Fix FindOpenCL on Mac OS
Here we go:
https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=48dc6343bba3b3f296d35ab060681c50f0eb8cde
Thanks again for the patch!
Cheers,
Matthäus
Am 05.08.2016 um 22:09 schrieb Matthäus G. Chajdas:
> Hi,
>
> all right. Yes, that sounds like a problem with
> find_package_handle_standard_args, I wonder if setting the version to
> 0.0 by default would solve that particular problem?
>
> _DIR and _DIRS is there because that seems to be true for most packages.
>
> I'll push your patch this weekend - thanks again.
>
> Cheers,
> Matthäus
>
> Am 01.08.2016 um 21:04 schrieb jerry@web.de:
>> Hi,
>>
>>> The version is not listed as a required variable, so that's why it
>>> passes through. If you pass in a version into your find_package call, it
>>> should bail out if no version is specified.
>> Sadly not. The current version in master does not fail when invoked with
>> "find_package(OpenCL 1.2 REQUIRED)". My first email shows exactly the
>> output. You see that it says "Required is at least version "1.2""
>> while also saying "Found OpenCL:..." while also no version was found. The
>> patch now fails if invoked for example with find_package(OpenCL 2.0
>> REQUIRED).
>> It seems that does not work as expected when
>> OpenCL_VERSION_STRING is empty.
>>
>>> I assume this was from testing, not
>>> because that changed something on macOS?
>> You are right _DIR and _DIRS are working.
>> I think I only changed it because for example FindGLUT uses it, for the
>> library the singular variant LIBRARY is used and I
>> don't understand the difference of _DIR and _DIRS :)
>>
>> Jerry
>>
>> On 01.08.2016 14:32, Matthäus G. Chajdas wrote:
>>> Hi Jerry,
>>>
>>> thanks for giving it a spin :)
>>>
>>> I don't have a Mac to test myself - as your changes are confined to
>>> macOS, they look safe to me.
>>>
>>> The version is not listed as a required variable, so that's why it
>>> passes through. If you pass in a version into your find_package call, it
>>> should bail out if no version is specified.
>>>
>>> I only got one minor nit-pick: Why did you change the line
>>> INTERFACE_INCLUDE_DIRECTORIES "${OpenCL_INCLUDE_DIR}")
>>> to use _DIR instead of _DIRS? I assume this was from testing, not
>>> because that changed something on macOS?
>>>
>>> Other than that, the patch looks good to me. I'll apply it this week.
>>>
>>> Cheers,
>>> Matthäus
>>>
>
--
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 FindOpenCL on Mac OS
Hi,
all right. Yes, that sounds like a problem with
find_package_handle_standard_args, I wonder if setting the version to
0.0 by default would solve that particular problem?
_DIR and _DIRS is there because that seems to be true for most packages.
I'll push your patch this weekend - thanks again.
Cheers,
Matthäus
Am 01.08.2016 um 21:04 schrieb jerry@web.de:
> Hi,
>
>> The version is not listed as a required variable, so that's why it
>> passes through. If you pass in a version into your find_package call, it
>> should bail out if no version is specified.
> Sadly not. The current version in master does not fail when invoked with
> "find_package(OpenCL 1.2 REQUIRED)". My first email shows exactly the
> output. You see that it says "Required is at least version "1.2""
> while also saying "Found OpenCL:..." while also no version was found. The
> patch now fails if invoked for example with find_package(OpenCL 2.0 REQUIRED).
> It seems that does not work as expected when
> OpenCL_VERSION_STRING is empty.
>
>> I assume this was from testing, not
>> because that changed something on macOS?
> You are right _DIR and _DIRS are working.
> I think I only changed it because for example FindGLUT uses it, for the
> library the singular variant LIBRARY is used and I
> don't understand the difference of _DIR and _DIRS :)
>
> Jerry
>
> On 01.08.2016 14:32, Matthäus G. Chajdas wrote:
>> Hi Jerry,
>>
>> thanks for giving it a spin :)
>>
>> I don't have a Mac to test myself - as your changes are confined to
>> macOS, they look safe to me.
>>
>> The version is not listed as a required variable, so that's why it
>> passes through. If you pass in a version into your find_package call, it
>> should bail out if no version is specified.
>>
>> I only got one minor nit-pick: Why did you change the line
>> INTERFACE_INCLUDE_DIRECTORIES "${OpenCL_INCLUDE_DIR}")
>> to use _DIR instead of _DIRS? I assume this was from testing, not
>> because that changed something on macOS?
>>
>> Other than that, the patch looks good to me. I'll apply it this week.
>>
>> Cheers,
>> Matthäus
>>
--
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 FindOpenCL on Mac OS
Hi Jerry,
thanks for giving it a spin :)
I don't have a Mac to test myself - as your changes are confined to
macOS, they look safe to me.
The version is not listed as a required variable, so that's why it
passes through. If you pass in a version into your find_package call, it
should bail out if no version is specified.
I only got one minor nit-pick: Why did you change the line
INTERFACE_INCLUDE_DIRECTORIES "${OpenCL_INCLUDE_DIR}")
to use _DIR instead of _DIRS? I assume this was from testing, not
because that changed something on macOS?
Other than that, the patch looks good to me. I'll apply it this week.
Cheers,
Matthäus
Am 01.08.2016 um 09:58 schrieb jerry@web.de:
> Hi,
>
> I tried the FindOpenCL.cmake with the imported target OpenCL::OpenCL and
> found out that it does not work on MacOS.
>
> The first problem is that it does not detect the version. In line 56 the path
> needs to be changed from ${OpenCL_INCLUDE_DIR}/OpenCL/cl.h" to
> “${OpenCL_INCLUDE_DIR}/Headers/cl.h“ because OpenCL_INCLUDE_DIR points to the
> root of the OpenCL framework directory and the Headers are located under
> Headers.
>
> Also there seems to be a bug in find_package_handle_standard_args (?).
> Because without the change above - when there is no version found - the
> variable OpenCL_VERSION_STRING is empty. But an empty version string does not
> let cmake fail. This is the output
>
> -- Looking for CL_VERSION_2_0
> -- Looking for CL_VERSION_2_0 - not found
> -- Looking for CL_VERSION_1_2
> -- Looking for CL_VERSION_1_2 - not found
> -- Looking for CL_VERSION_1_1
> -- Looking for CL_VERSION_1_1 - not found
> -- Looking for CL_VERSION_1_0
> -- Looking for CL_VERSION_1_0 - not found
> -- Found OpenCL: /System/Library/Frameworks/OpenCL.framework (Required is at
> least version "1.2")
>
> The other problems are with the imported locations in line 147ff. With the
> current solution the linker step fails because OpenCL_LIBRARY points to the
> root of the framework directory - i.e.
> /System/Library/Frameworks/OpenCL.framework. Long time ago there was a bug
> report [1] but the proposed solution was to have an if/else statement to
> handle the special case of Apple frameworks. So I based my solution on [2]
> and [3]. This works fine with Makefile and Ninja generators but the Xcode
> generator still fails. The problem now is that with Xcode 7 Apple switched
> the way how framework libraries work [5]. The final solution is based on [4]
> where the Apple framework case is changed to an INTERFACE IMPORTED library
> and the framework is stored in INTERFACE_LINK_LIBRARIES. This way cmake
> resolves the library path to -framework OpenCL.
>
> So with this patch I provide my final solution. Is it correct (it works at
> least for me now on Win, Linux and Apple)?
>
> What’s with this empty version bug? I don’t found a solution for this.
>
> jerry
>
> [1] https://cmake.org/Bug/view.php?id=14105
> [2] https://github.com/Kitware/CMake/blob/master/Modules/FindGLUT.cmake
> [3] https://github.com/rpavlik/cmake-modules/blob/master/FindSDL2.cmake
> [4] http://public.kitware.com/pipermail/cmake/2016-April/063179.html
> [5]
> http://public.kitware.com/pipermail/cmake-developers/2015-August/026110.html
>
>
>
--
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] FindVulkan.cmake
Thanks a lot! I've pushed a squashed commit which does everything in one go, and merged it into next. Cheers, Matthäus Am 06.06.2016 um 17:22 schrieb Brad King: > On 06/06/2016 11:09 AM, Matthäus G. Chajdas wrote: >> thanks a lot. Is this make test or is there something special needed to >> get the ModuleNotices? make test is super-slow, I wonder if there's a >> faster way to get to the relevant test. > > Just run: > >ctest -R ModuleNotices > > To run the whole test suite in parallel: > >ctest -j 8 > > or: > >make test ARGS='-j 8' > > -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] FindVulkan.cmake
Hi Brad, thanks a lot. Is this make test or is there something special needed to get the ModuleNotices? make test is super-slow, I wonder if there's a faster way to get to the relevant test. Cheers, Matthäus Am 06.06.2016 um 15:36 schrieb Brad King: > On 06/04/2016 02:54 PM, Matthäus G. Chajdas wrote: >> I've pushed an add-FindVulkan topic branch which adds a module to search >> for the Vulkan graphics API (https://www.khronos.org/vulkan/). >> >> I'm also happy to maintain this going forward. > > Thanks. Please run the CMake test suite and fix the ModuleNotices > test failure. Then squash the topic back together and merge to > 'next' for testing. > > -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
[cmake-developers] FindVulkan.cmake
Hi, I've pushed an add-FindVulkan topic branch which adds a module to search for the Vulkan graphics API (https://www.khronos.org/vulkan/). I'm also happy to maintain this going forward. The complete diff can be found here: https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=276fa1497efd37872fdaa2f223ae71b5795f7ade Cheers, Matthäus -- 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] Topic "add-opencl-imported-target" good to merge?
Thanks! Cheers, Matthäus Am 02.06.2016 um 15:44 schrieb Brad King: > On 06/01/2016 03:00 PM, Matthäus G. Chajdas wrote: >> done - I had to squash and force push once more, because I used the >> wrong author in the first commit. >> >> Everything is now in one commit here: >> https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e95b62110715c06fb76b57fdfb13ea493a94c0c4 >> >> Thanks for the timely feedback! > > I renamed the topic to 'FindOpenCL-imported-target', added some minor > tweaks, and merged to 'next' for testing: > > FindOpenCL: Add an imported target > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b66d4739 > > If any fixes are needed please extend the topic and merge to 'next' > again. > > 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] Topic "add-opencl-imported-target" good to merge?
Hi Brad, done - I had to squash and force push once more, because I used the wrong author in the first commit. Everything is now in one commit here: https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e95b62110715c06fb76b57fdfb13ea493a94c0c4 Thanks for the timely feedback! Cheers, Matthäus Am 01.06.2016 um 20:22 schrieb Brad King: > On 06/01/2016 02:15 PM, Matthäus G. Chajdas wrote: >> Hopefully done > > The revised history looks good. The change itself looks good. > > Please also add a `Help/release/dev/FindOpenCL-imported-target.rst` > file with a release note for the feature. Look at other files > in that directory for a sample. See Help/release/*.rst for other > examples. > > As part of the modernization of find modules we're also trying > to add better testing for them. Please see Tests/FindPNG and the > CMake_TEST_FindPNG code path in Tests/CMakeLists.txt and construct > a similar test for the FindOpenCL module. > > 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] Topic "add-opencl-imported-target" good to merge?
Hopefully done - I'm not the biggest git expert but the history looks like I'd expect it to look like :) Cheers, Matthäus Am 01.06.2016 um 19:57 schrieb Brad King: > On 06/01/2016 01:53 PM, Matthäus G. Chajdas wrote: >> updated to latest master and pushed again (I merged latest master into >> this - is that fine or does it have to be a rebase? In that case I'll redo.) > > Please rebase and force push. > > 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] Topic "add-opencl-imported-target" good to merge?
Hi Brad, updated to latest master and pushed again (I merged latest master into this - is that fine or does it have to be a rebase? In that case I'll redo.) Cheers, Matthäus Am 01.06.2016 um 17:18 schrieb Brad King: > On 05/31/2016 03:17 PM, Matthäus G. Chajdas wrote: >> I've just pushed "add-opencl-imported-target" which adds an imported >> target to FindOpenCL. The whole change is rather small: >> >> https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=6c53137a19e482140db3dc97b626af38348f2c71 >> >> Good to merge this to next for testing? > > Please rebase on 'master' now that post-3.6 development is open. > > 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
[cmake-developers] Topic "add-opencl-imported-target" good to merge?
Hi, I've just pushed "add-opencl-imported-target" which adds an imported target to FindOpenCL. The whole change is rather small: https://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=6c53137a19e482140db3dc97b626af38348f2c71 Good to merge this to next for testing? Cheers, Matthäus -- 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] "Pre-configure" step in CMake
Hi,
that sounds like it would do the trick. I wasn't aware that
execute_process will block the script until it's done executing. Need to
check this out but that definitely looks like the way to go, thanks!
Cheers,
Matthäus
Am 24.09.2015 um 10:14 schrieb Tamás Kenéz:
> What if you call your dependency-fetcher script with a straight
> macro/function call or `include` or `execute_process` instead of putting
> it into a custom target? I'm thinking of something like this:
>
> set(DEP_SCRIPT_OUT ${CMAKE_CURRENT_BINARY_DIR}/dep-script-out.cmake)
> if(NOT EXISTS "${DEP_SCRIPT_OUT}")
> execute_process(${CMAKE_COMMAND}
> -DC_COMPILER_ID=${CMAKE_C_COMPILER_ID}
> -DC_COMPILER_VERSION=${CMAKE_C_COMPILER_VERSION}
> -DDEP_SCRIPT_OUT =${DEP_SCRIPT_OUT}
> -P dependency-fetcher.cmake)
> endif()
> include(${DEP_SCRIPT_OUT})
>
> or, simply:
>
> if(NOT DEPENDENCIES_FETCHED)
> include(dependency-fetcher.cmake)
> # fetch_dependencies() # call it in case it's implemented as a
> macro/function
> set(DEPENDENCIES_FETCHED ON CACHE BOOL "" FORCE)
> endif()
>
> In the latter case there's no need to write the variables into a script
> since the fetcher runs in the same scope.
>
> Tamas
>
>
> On Wed, Sep 23, 2015 at 9:49 PM, Matthäus G. Chajdas <cm...@anteru.net
> <mailto:cm...@anteru.net>> wrote:
>
> Hi,
>
> I'm trying to solve the following the problem: I have a C++ application
> and a dependency fetching script. I want to simplify the initial build
> such that the following happens: On the first run of cmake, the compiler
> ID and version is passed to an external script, which fetches some
> pre-build binaries. It then writes a CMake file which contains basically
> only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir)
> commands. CMake would then read this file and subsequent find_library
> calls would pick up the values from this new CMake file. The idea is
> that "actual" build is dependent on this first dependency step, but it's
> already within the CMake framework so I can grab the compiler info and
> other build info.
>
> The obvious problem is that while I can easily run the external script
> by using configure_file, and have a custom target that does the
> dependency fetching and CMake configure file generation. But I don't see
> an easy way to get CMake to make the "rest of the project" depend on
> that configure file. How can I make such a "two-stage" build with CMake?
>
> Cheers,
> Matthäus
> --
>
> Powered by www.kitware.com <http://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
>
>
>
>
--
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
Re: [CMake] "Pre-configure" step in CMake
Hi, how does the ExternalProject interact with subsequent find_library calls? I've seen projects building dependencies through ExternalProject, but those would the project manually by querying ExternalProject and adding a new imported target. How would I connect an ExternalProject to one or more find_library calls? Is there a downside from configure taking an unknown amount of time? My expectation was that there is no timeout for the configure step. Cheers, Matthäus Am 24.09.2015 um 22:30 schrieb Bill Hoffman: > On 9/24/2015 4:26 PM, Matthäus G. Chajdas wrote: >> Hi, >> >> that sounds like it would do the trick. I wasn't aware that >> execute_process will block the script until it's done executing. Need to >> check this out but that definitely looks like the way to go, thanks! > ExternalProject might be a better option. It pushes the downloads to > build time and handles dependencies without having to re-run CMake. If > you run a download script at CMake time, it could take an unknown amount > of time to configure. > > -Bill > > -- 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
[CMake] "Pre-configure" step in CMake
Hi, I'm trying to solve the following the problem: I have a C++ application and a dependency fetching script. I want to simplify the initial build such that the following happens: On the first run of cmake, the compiler ID and version is passed to an external script, which fetches some pre-build binaries. It then writes a CMake file which contains basically only set(FOO_INCLUDE_DIR /dep-dir), set(FOO_LIBRARY_DIR /dep-dir) commands. CMake would then read this file and subsequent find_library calls would pick up the values from this new CMake file. The idea is that "actual" build is dependent on this first dependency step, but it's already within the CMake framework so I can grab the compiler info and other build info. The obvious problem is that while I can easily run the external script by using configure_file, and have a custom target that does the dependency fetching and CMake configure file generation. But I don't see an easy way to get CMake to make the "rest of the project" depend on that configure file. How can I make such a "two-stage" build with CMake? Cheers, Matthäus -- 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
[cmake-developers] CMake 3.0 find_patch changes?
Hi, I've just tried my FindOpenCL Module in cmake-next, and with 3.0, it doesn't work as expected (on Windows) Before I submit the fix, I wanted to check back that I was indeed doing it wrong before. In my find_path, I used the following call: find_path(OpenCL_INCLUDE_DIR NAMES CL/cl.h OpenCL/cl.h PATHS ENV PROGRAMFILES(X86) AMDAPPSDKROOT INTELOCLSDKROOT NVSDKCOMPUTE_ROOT CUDA_PATH ATISTREAMSDKROOT PATH_SUFFIXES OpenCL/common/inc AMD APP/include) which I had to change to find_path(OpenCL_INCLUDE_DIR NAMES CL/cl.h OpenCL/cl.h PATHS ENV PROGRAMFILES(X86) ENV AMDAPPSDKROOT ENV INTELOCLSDKROOT ENV NVSDKCOMPUTE_ROOT ENV CUDA_PATH ENV ATISTREAMSDKROOT PATH_SUFFIXES include OpenCL/common/inc AMD APP/include) Notice that I have to repeat ENV now for every environment variable, and I had to add include to PATH_SUFFIXES. Without repeating ENV, only the first environment variable is expanded. However, I cannot find anything in the CMake 3.0.0 release notes regarding find_path which would explain why these changes are necessary, and this code used to work with CMake 2.8.12. Is this a regression, or was I simply lucky that it worked? Cheers, Matthäus -- 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] [New Module] FindOpenCL, FindHg
Hi Brad, thanks for splitting the patches the review. I've just pushed the requested changes to the add-FindOpenCL topic. If there is still something missing, please drop me a line; I appreciate your patience with a new contributor! Cheers, Matthäus On 25.02.2014 17:36, Brad King wrote: Hi Matthäus, On 02/23/2014 03:34 AM, Rolf Eike Beer wrote: Looks better. Thanks for your work on these. I've split your branch into separate topics for FindHg and FindOpenCL. The FindHg changes are now in master: FindHg: Search for TortoiseHg http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8993df6c FindHg: Add Hg_WC_INFO macro http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bcefbe73 I rebased and squashed the FindOpenCL module topic, with the current draft here: Add FindOpenCL module http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=85f681f2 in a topic called 'add-FindOpenCL'. However, the names of the cache entries and result variables are not correct. Please read the Find Modules section of the cmake-developer(7) manual: http://cmake.org/gitweb?p=cmake.git;a=blob;f=Help/manual/cmake-developer.7.rst;hb=8619a453#l667 Basically the names OpenCL_LIBRARY OpenCL_INCLUDE_DIR should be cache entries (through find_library, find_path, etc.) that the user can set to the location of individual components of the package. They do not need to be in the documentation but could be mentioned in a separate section about what cache entries the module defines. The names OpenCL_FOUND OpenCL_INCLUDE_DIRS OpenCL_LIBRARIES OpenCL_VERSION_STRING should be normal variables, not cache entries, that report the results for use by the calling application code. These should be documented. Please fetch and checkout the topic from the stage and add commits to revise the module accordingly. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi, So, I'm very sorry to come up with those things now and not having catched them earlier. If you now do no problem, I should have also checked what I was adding with git :/ I think I fixed everything now in my latest commit. At least `git diff origin/master Modules/FindHg.cmake` looks reasonable now. I struggled a bit with rebasing it today (I'm really new to git), but I hope everything worked out correctly in the end. As far as I can tell, the commit here: http://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=274ecf045ec7db4dd82caa74fb74be496a1bf5b8 is the correct one :) Cheers, Matthäus -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi, I'm following that guide -- I have a Mantis CDash account, and I'm at step 4 which is wait for acceptance. Most projects I know have some policy like ping the maintainer after two weeks or ask the code owner or similar if a patch is in limbo. I have no problem waiting longer, but it would be definitely helpful for first-time contributers like me to have a rough indication how fast the process goes. Is there something else I can do to speed up the process? Cheers, Matthäus On 19.02.2014 16:30, Brad King wrote: On 02/17/2014 02:27 PM, Matthäus G. Chajdas wrote: As I said in the last mail, how do we continue from here on? Are the modules ready for acceptance, and if so, who is the person to ask for commit access, or is there something left to fix? Please follow the instructions here: http://www.cmake.org/Wiki/CMake:Module_Maintainers#New_Maintainer to get push access and become maintainer of the modules. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi, at least the documentation here: http://www.cmake.org/cmake/help/git-master/manual/cmake-developer.7.html#find-modules says so, unless there is another one I should be referring to. I've changed it to _VERSION. As I said in the last mail, how do we continue from here on? Are the modules ready for acceptance, and if so, who is the person to ask for commit access, or is there something left to fix? Cheers, Matthäus On 16.02.2014 22:11, Stephen Kelly wrote: Rolf Eike Beer wrote: Am Sonntag, 16. Februar 2014, 18:43:01 schrieb Matthäus G. Chajdas: Hi Eike, thanks for reviewing! I've just pushed a new version, which should fix all the issues you mentioned. I'm also setting now Hg_FOUND using FOUND_VAR (this is also recommended in the documentation.) Anything more left to do? The only thing which bothers me is the _VERSION_STRING in FindHg (which is similar to FindGit) and the same variable being called _VERSION in OpenCL, if there is a policy on that, I would like to use the same variable name in both. Right now I was aiming more for consistency with existing packages. There has been a Modules/readme.txt, no idea where it is now in rst. But the preferred nameing ins Hg_VERSION_STRING and OpenCL_VERSION_STRING. If the readme file says that, then the readme file is wrong. The canonical way to name it is *_VERSION, not *_VERSION_STRING, as that is how config- file packages work. If the readme file says that, then it should be changed, just like a recommendation was changed in commit 140692d84c. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi Eike, thanks for reviewing! I've just pushed a new version, which should fix all the issues you mentioned. I'm also setting now Hg_FOUND using FOUND_VAR (this is also recommended in the documentation.) Anything more left to do? The only thing which bothers me is the _VERSION_STRING in FindHg (which is similar to FindGit) and the same variable being called _VERSION in OpenCL, if there is a policy on that, I would like to use the same variable name in both. Right now I was aiming more for consistency with existing packages. Cheers, Matthäus On 15.02.2014 19:33, Rolf Eike Beer wrote: Am Samstag, 15. Februar 2014, 18:54:47 schrieb Stephen Kelly: Rolf Eike Beer wrote: Matthäus G. Chajdas wrote: Hi Eike, all right, then Hg, as it's FindHg, unless there is a naming policy I'm not aware of. I was just confused a bit due to FindGit, which uses GIT_ as the prefix. How do I proceed from here? What should I do next? I think you can reduce FindHg quite a bit. Here are some examples: -do not set Hg_FOUND to anything, FPHSA will do it for you You need to set it explicitly when using FPHSA actually, because it sets uppercase(Hg_FOUND) == HG_FOUND instead by default. I consider that a bug, but the 'fix decision' was to require explicitly specifying the _FOUND variable in order to get a sane value. Well, then the fix is simply to pass FOUND_VAR Hg_FOUND to it, no? Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi, couldn't find it in the documentation either :( I've changed it to OPENCL_VERSION_STRING. Should I apply for commit access now? Cheers, Matthäus On 16.02.2014 20:10, Rolf Eike Beer wrote: Am Sonntag, 16. Februar 2014, 18:43:01 schrieb Matthäus G. Chajdas: Hi Eike, thanks for reviewing! I've just pushed a new version, which should fix all the issues you mentioned. I'm also setting now Hg_FOUND using FOUND_VAR (this is also recommended in the documentation.) Anything more left to do? The only thing which bothers me is the _VERSION_STRING in FindHg (which is similar to FindGit) and the same variable being called _VERSION in OpenCL, if there is a policy on that, I would like to use the same variable name in both. Right now I was aiming more for consistency with existing packages. There has been a Modules/readme.txt, no idea where it is now in rst. But the preferred nameing ins Hg_VERSION_STRING and OpenCL_VERSION_STRING. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi Eike, thanks again! I've just read the Wiki regarding commit access, and it says I should wait for acceptance on the mailing list before applying for access. This is the first time ever I try to contribute something to CMake, so please bear with me if I'm missing something here. Should I ping someone regarding the modules or wait for another review/acceptance notification? The account setup page specifically says After you have been invited, and that didn't happen yet. Could you shed some light on the normal process? Cheers, Matthäus On 16.02.2014 20:29, Rolf Eike Beer wrote: Am Sonntag, 16. Februar 2014, 20:26:22 schrieb Matthäus G. Chajdas: Hi, couldn't find it in the documentation either :( Help/manual/cmake-developer.7.rst I've changed it to OPENCL_VERSION_STRING. Should be OpenCL_VERSION_STRING: the variables should follow the casing of the module name. Should I apply for commit access now? I will not stop you ;) Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi Eike, all right, then Hg, as it's FindHg, unless there is a naming policy I'm not aware of. I was just confused a bit due to FindGit, which uses GIT_ as the prefix. How do I proceed from here? What should I do next? Cheers, Matthäus On 08.02.2014 17:38, Rolf Eike Beer wrote: Am Samstag, 8. Februar 2014, 16:38:02 schrieb Matthäus G. Chajdas: Hi Eike, thanks for taking a look. I've changed the module accordingly. Is there a recommendation whether to use HG_ or Hg_ as the prefix for the variables? As I guess there will be a bit back forth here, I've also pushed them to a repository on github: https://github.com/Anteru/findhgcl That's simple: the same way as the module is called. CMake set's some automatic variables, e.g. to reflect the REQUIRED and version arguments given to the find_package() call. These are set the same way as the module name is spelled, and so does FPHSA. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [New Module] FindOpenCL, FindHg
Hi,
I would like to propose two new modules for inclusion in CMake:
FindOpenCL to find OpenCL and FindHg for Mercurial (see attached.)
FindOpenCL is written in similar spirit to FindOpenGL, while FindHg is
basically the equivalent of FindSubversion for Mercurial.
The modules have been tested on Windows, Linux, and Mac, using a variety
of OpenCL runtimes.
I would be happy to be the maintainer of these modules, if they get
accepted into the CMake distribution.
Cheers,
Matthäus
#.rst:
# FindOpenCL
# --
#
# Try to find OpenCL
#
# Once done this will define
#
# ::
#
# OPENCL_FOUND- system has OpenCL
# OPENCL_INCLUDE_DIR - the OpenCL include directory
# OPENCL_LIBRARY - Link against this library to use OpenCL
# OPENCL_VERSION - OpenCL version (eg. 1.0)
#
#
FUNCTION(_FIND_OPENCL_VERSION)
INCLUDE(CheckSymbolExists)
INCLUDE(CMakePushCheckState)
CMAKE_PUSH_CHECK_STATE()
FOREACH(VERSION 2_0 1_2 1_1 1_0)
SET(CMAKE_REQUIRED_INCLUDES ${OPENCL_INCLUDE_DIR})
IF(APPLE)
CHECK_SYMBOL_EXISTS(
CL_VERSION_${VERSION}
${OPENCL_INCLUDE_DIR}/OpenCL/cl.h
OPENCL_VERSION_${VERSION})
ELSE()
CHECK_SYMBOL_EXISTS(
CL_VERSION_${VERSION}
${OPENCL_INCLUDE_DIR}/CL/cl.h
OPENCL_VERSION_${VERSION})
ENDIF()
IF(OPENCL_VERSION_${VERSION})
STRING(REPLACE _ . VERSION ${VERSION})
SET(OPENCL_VERSION_FOUND ${VERSION} CACHE
STRING Highest supported OpenCL version)
BREAK()
ENDIF()
ENDFOREACH()
CMAKE_POP_CHECK_STATE()
ENDFUNCTION()
FIND_PATH(OPENCL_INCLUDE_DIR
NAMES
CL/cl.h OpenCL/cl.h
PATHS
$ENV{PROGRAMFILES(X86)}/AMD APP/include
$ENV{AMDAPPSDKROOT}/include
$ENV{INTELOCLSDKROOT}/include
$ENV{NVSDKCOMPUTE_ROOT}/OpenCL/common/inc
$ENV{CUDA_PATH}/include
# Legacy Stream SDK
$ENV{ATISTREAMSDKROOT}/include)
IF(CMAKE_SIZEOF_VOID_P EQUAL 4)
SET(OPENCL_LIB_SEARCH_PATH
${OPENCL_LIB_SEARCH_PATH}
$ENV{PROGRAMFILES(X86)}/AMD APP/lib/x86
$ENV{AMDAPPSDKROOT}/lib/x86
$ENV{INTELOCLSDKROOT}/lib/x86
$ENV{CUDA_PATH}/lib/Win32
$ENV{NVSDKCOMPUTE_ROOT}/OpenCL/common/lib/Win32
# Legacy Stream SDK
$ENV{ATISTREAMSDKROOT}/lib/x86)
ELSEIF(CMAKE_SIZEOF_VOID_P EQUAL 8)
SET(OPENCL_LIB_SEARCH_PATH
${OPENCL_LIB_SEARCH_PATH}
$ENV{PROGRAMFILES(X86)}/AMD APP/lib/x86_64
$ENV{AMDAPPSDKROOT}/lib/x86_64
$ENV{INTELOCLSDKROOT}/lib/x64
$ENV{CUDA_PATH}/lib/x64
$ENV{NVSDKCOMPUTE_ROOT}/OpenCL/common/lib/x64
# Legacy stream SDK
$ENV{ATISTREAMSDKROOT}/lib/x86_64)
ENDIF(CMAKE_SIZEOF_VOID_P EQUAL 4)
FIND_LIBRARY(
OPENCL_LIBRARY
NAMES OpenCL
PATHS ${OPENCL_LIB_SEARCH_PATH})
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(
OpenCL
DEFAULT_MSG
OPENCL_LIBRARY OPENCL_INCLUDE_DIR)
if(OPENCL_FOUND)
set(OPENCL_LIBRARIES ${OPENCL_LIBRARY})
_FIND_OPENCL_VERSION()
else(OPENCL_FOUND)
set(OPENCL_LIBRARIES)
endif(OPENCL_FOUND)
mark_as_advanced(
OPENCL_INCLUDE_DIR
OPENCL_LIBRARY
)
#.rst:
# FindHg
# --
#
# Extract information from a mercurial working copy
#
# The module defines the following variables:
#
# ::
#
# Hg_EXECUTABLE - path to mercurial command line client
# Hg_FOUND - true if the command line client was found
#
#
# If the command line client executable is found the following macro is defined:
#
# ::
#
# Hg_WC_INFO(dir var-prefix)
#
# Hg_WC_INFO extracts information of a mercurial working copy
# at a given location. This macro defines the following variables:
#
# ::
#
# var-prefix_WC_CHANGESET - current changeset
# var-prefix_WC_REVISION - current revision
#
# Example usage:
#
# ::
#
# find_package(Hg)
# if(Hg_FOUND)
# Hg_WC_INFO(${PROJECT_SOURCE_DIR} Project)
# message(Current revision is ${Project_WC_REVISION})
# message(Current changeset is ${Project_WC_CHANGESET})
# endif()
SET(Hg_FOUND FALSE)
FIND_PROGRAM(Hg_EXECUTABLE
NAMES hg hg.exe
HINTS /usr/bin
PATHS [HKEY_LOCAL_MACHINE\\Software\\TortoiseHg]
[HKEY_LOCAL_MACHINE\\Software\\Wow6432Node\\TortoiseHg]
DOC hg command line client)
MARK_AS_ADVANCED(Hg_EXECUTABLE)
IF(Hg_EXECUTABLE)
SET(Hg_FOUND TRUE)
MACRO(Hg_WC_INFO dir prefix)
EXECUTE_PROCESS(COMMAND ${Hg_EXECUTABLE} id -i -n
WORKING_DIRECTORY ${dir}
ERROR_VARIABLE Hg_error
OUTPUT_VARIABLE ${prefix}_WC_DATA
OUTPUT_STRIP_TRAILING_WHITESPACE)
IF(NOT ${Hg_error} EQUAL 0)
MESSAGE(SEND_ERROR Command \${Hg_EXECUTBALE} id -n\ in directory ${dir} failed with output:\n${Hg_error})
ENDIF(NOT ${Hg_error} EQUAL 0)
STRING(REPLACE ; ${prefix}_WC_DATA ${${prefix}_WC_DATA})
LIST(GET ${prefix}_WC_DATA 0 ${prefix}_WC_CHANGESET)
LIST(GET ${prefix}_WC_DATA 1 ${prefix}_WC_REVISION)
STRING(REGEX REPLACE \\+$ ${prefix}_WC_REVISION ${${prefix}_WC_REVISION})
STRING(REGEX REPLACE \\+$ ${prefix}_WC_CHANGESET ${${prefix}_WC_CHANGESET})
ENDMACRO(Hg_WC_INFO)
ENDIF(Hg_EXECUTABLE)
IF(NOT Hg_FOUND)
IF(NOT Hg_FIND_QUIETLY)
MESSAGE(STATUS Mercurial was not found)
ELSE(NOT Hg_FIND_QUIETLY)
IF(Hg_FIND_REQUIRED)
Re: [cmake-developers] [New Module] FindOpenCL, FindHg
Hi Eike, thanks for taking a look. I've changed the module accordingly. Is there a recommendation whether to use HG_ or Hg_ as the prefix for the variables? As I guess there will be a bit back forth here, I've also pushed them to a repository on github: https://github.com/Anteru/findhgcl Cheers, Matthäus On 08.02.2014 14:59, Rolf Eike Beer wrote: Am Samstag, 8. Februar 2014, 14:28:37 schrieb Matthäus G. Chajdas: Hi, I would like to propose two new modules for inclusion in CMake: FindOpenCL to find OpenCL and FindHg for Mercurial (see attached.) FindOpenCL is written in similar spirit to FindOpenGL, while FindHg is basically the equivalent of FindSubversion for Mercurial. The modules have been tested on Windows, Linux, and Mac, using a variety of OpenCL runtimes. I would be happy to be the maintainer of these modules, if they get accepted into the CMake distribution. Without looking much into the details: -the hg.exe should not be needed, CMake should add that itself -use FPHSA in that module, too -please add version detection to the Hg module I have not really looked into FindOpenCL yet. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
