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