Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
On 2017 M10 1, Sun 12:38:43 CEST David Cole via CMake wrote: > No, I was already promptly corrected by Brad, too. I was not > accounting for the fact that the other find_* calls used inside of > find modules also use CMAKE_PREFIX_PATH. I was thinking of its use to > find a project's config file from the find_package config mode. > > I stand corrected. Again. ;-) yeah, sorry, I had problems with receiving mail from the cmake list since August and was catching up yesterday and replied too quickly. Alex -- 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] [cmake-developers] Debugging find_package() search behavior?
No, I was already promptly corrected by Brad, too. I was not accounting for the fact that the other find_* calls used inside of find modules also use CMAKE_PREFIX_PATH. I was thinking of its use to find a project's config file from the find_package config mode. I stand corrected. Again. ;-) However, I stand by my assertion that find modules do what they want. It's still a bit of a wild wild west, and people make their own find modules that live inside their own project's source trees. Config files should be the preferred/primary mechanism for find_package calls (going on something like 5 or 6 years now...), but still people write new find modules. Thanks, David C. On Sun, Oct 1, 2017 at 11:52 AM, Alexander Neundorf wrote: > On 2017 M08 29, Tue 11:33:15 CEST David Cole via cmake-developers wrote: >> That's correct: >> >> find modules do what they want, and most do not pay attention to >> CMAKE_PREFIX_PATH. > > are you sure ? > As long as NO_DEFAULT_PATH is not used in the find_*() calls, > CMAKE_PREFIX_PATH > is used automatically by them. > > Alex > -- 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] [cmake-developers] Debugging find_package() search behavior?
On 2017 M08 29, Tue 11:33:15 CEST David Cole via cmake-developers wrote: > That's correct: > > find modules do what they want, and most do not pay attention to > CMAKE_PREFIX_PATH. are you sure ? As long as NO_DEFAULT_PATH is not used in the find_*() calls, CMAKE_PREFIX_PATH is used automatically by them. Alex -- 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] [cmake-developers] Debugging find_package() search behavior?
> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. Not always, some people sometimes feel like doing it by hand from scratch with if(EXISTS ...). Sadly. On Tue, Aug 29, 2017 at 5:49 PM, Brad King wrote: > On 08/29/2017 11:33 AM, David Cole wrote: > > That's correct: > > > > find modules do what they want, and most do not pay attention to > > CMAKE_PREFIX_PATH. > > CMAKE_PREFIX_PATH *is* used by find modules. > > The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. > See the documentation of find_library, find_path, etc. for details. > Each command searches an appropriate `/` where `` > is based on the kind of command doing the searching. > > -Brad > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more > information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/ > opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
On 08/29/2017 12:21 PM, Robert Dailey wrote: > 3. Second find_package() happens, but "AlreadyInCache" is true (line > 28 in cmFindPathCommand.cxx) this time, so it doesn't search for it > again. > > Hard to tell where the bug is here. I'd argue that AlreadyInCache > shouldn't be set to true since an exact version was not found>, and the > next find_package() command should do a full path search. Is this a > bug in the C++ code or the find module script? What determines the > AlreadyInCache variable? This is one of the problems with find modules. The individual find_* call result *was* found and is already cached. There is no way to tell that apart from the user setting it explicitly in the cache. That it proved insufficient for FPHSA's version check is not the concern of the find_ command. The find_package "config" mode uses only a single result variable and performs a version check before setting it, so it can do multiple searches like that. Find modules can't do that because they need to search for things piecemeal. At most they can report at the end that whatever was found is not suitable. In typical use cases with only a single find_package call it is then up to the user to correct the cached settings. -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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
Ok I debugged find_path() code in CMake and I determined the problem. First, let me explain what I'm doing a little more... I build third party libraries on demand during configure step in CMake. I do so via execute_process() to invoke another CMake instance, that builds and installs a library. This is similar to how ExternalProject_Add() works, but forces it to happen at configure time so I can use find_package() afterwards to find the library I just built. Each library first tries to be found, and if not found, I build it then try to find it again. Like so: ``` set( library_version 1.2.11 ) set( ZLIB_ROOT ${ZIOSK_THIRD_PARTY_INSTALL} ) find_package( ZLIB ${library_version} EXACT ) if( NOT ZLIB_FOUND OR NOT library_version VERSION_EQUAL ZLIB_VERSION_STRING ) build_third_party_library( CLEAN_BUILD ) find_package( ZLIB ${library_version} EXACT REQUIRED ) endif() ``` When Android's Toolchain is in use, this is what happens: 1. find_package() happens, it finds zlib under android NDK's root, but doesn't accept it because of a version mismatch (since I use the EXACT option) 2. I build the third party library with execute_process() 3. Second find_package() happens, but "AlreadyInCache" is true (line 28 in cmFindPathCommand.cxx) this time, so it doesn't search for it again. Hard to tell where the bug is here. I'd argue that AlreadyInCache shouldn't be set to true since an exact version was not found, and the next find_package() command should do a full path search. Is this a bug in the C++ code or the find module script? What determines the AlreadyInCache variable? On Tue, Aug 29, 2017 at 11:02 AM, David Cole wrote: > Sorry for the mis-statement. I stand corrected. > > However, it is true that there are many find modules with some > differences in approach, and if you are using one, you need to read up > on the individual documentation of that particular find module. > Especially if you need to know how to tell it how to find the exact > one you already know you have... > > > > > On Tue, Aug 29, 2017 at 11:49 AM, Brad King wrote: >> On 08/29/2017 11:33 AM, David Cole wrote: >>> That's correct: >>> >>> find modules do what they want, and most do not pay attention to >>> CMAKE_PREFIX_PATH. >> >> CMAKE_PREFIX_PATH *is* used by find modules. >> >> The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. >> See the documentation of find_library, find_path, etc. for details. >> Each command searches an appropriate `/` where `` >> is based on the kind of command doing the searching. >> >> -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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
Sorry for the mis-statement. I stand corrected. However, it is true that there are many find modules with some differences in approach, and if you are using one, you need to read up on the individual documentation of that particular find module. Especially if you need to know how to tell it how to find the exact one you already know you have... On Tue, Aug 29, 2017 at 11:49 AM, Brad King wrote: > On 08/29/2017 11:33 AM, David Cole wrote: >> That's correct: >> >> find modules do what they want, and most do not pay attention to >> CMAKE_PREFIX_PATH. > > CMAKE_PREFIX_PATH *is* used by find modules. > > The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. > See the documentation of find_library, find_path, etc. for details. > Each command searches an appropriate `/` where `` > is based on the kind of command doing the searching. > > -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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
On Tue, Aug 29, 2017 at 10:54 AM, Brad King wrote: > On 08/29/2017 11:50 AM, Robert Dailey wrote: >> Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib >> over the one provided by the Android NDK... >> >> Although I was able to get this working fine on Windows, it does not >> work with the NDK's toolchain file. > > That's because the CMAKE_FIND_ROOT_PATH settings re-root all search > paths to look only inside the NDK. This is one reason toolchain files > should not be monolithic and should only be authored locally for the > current machine. But the documentation[1] says it's a list, so if I add my own directory to that list, it should search there right? [1]: https://cmake.org/cmake/help/v3.6/variable/CMAKE_FIND_ROOT_PATH.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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
On 08/29/2017 11:50 AM, Robert Dailey wrote: > Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib > over the one provided by the Android NDK... > > Although I was able to get this working fine on Windows, it does not > work with the NDK's toolchain file. That's because the CMAKE_FIND_ROOT_PATH settings re-root all search paths to look only inside the NDK. This is one reason toolchain files should not be monolithic and should only be authored locally for the current machine. -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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib over the one provided by the Android NDK... Although I was able to get this working fine on Windows, it does not work with the NDK's toolchain file. On Tue, Aug 29, 2017 at 10:43 AM, Robert Dailey wrote: > Thanks for your help, the problem is that I was expecting too much > consistency between find module behavior. I'll treat them as if I have > no guarantees. > > Last question: Are there guarantees with find modules and > CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use > find_package(), behavior is different because the NDK's toolchain file > sets: > > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) > list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}") > > To try to "intercept" the search of NDK for libraries using > find_package(), I try this: > > set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} > ${CMAKE_FIND_ROOT_PATH} ) > > However, after running, it's always finding results in the NDK > directory set by the toolchain file, even though I put mine first in > the list. Furthermore, my install of zlib has the correct version, the > NDK one does not, but it still says it founds the NDK version. > > On Tue, Aug 29, 2017 at 10:33 AM, David Cole wrote: >> That's correct: >> >> find modules do what they want, and most do not pay attention to >> CMAKE_PREFIX_PATH. >> >> It's better to use a config file, but when you have to use a find >> module, you have to dig in and figure out the right way to use each >> one. >> >> >> >> On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey >> wrote: >>> I think the discrepancy here might be config vs module find mode. The >>> documentation I linked seems to be for config mode only, however I'm >>> utilizing the CMake-shipped FindZLIB.cmake module to find this >>> particular library. Does this offer no guarantees on how >>> CMAKE_PREFIX_PATH is used? >>> >>> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey >>> wrote: What I'm hoping for is that find_package() follows the rules it documents here: https://cmake.org/cmake/help/v3.6/command/find_package.html Specifically, it states it searches these paths (and that is treated case-insensitive): / (W) /(cmake|CMake)/ (W) /*/ (W) /*/(cmake|CMake)/ (W) /(lib/|lib|share)/cmake/*/ (U) /(lib/|lib|share)/*/(U) /(lib/|lib|share)/*/(cmake|CMake)/ (U) If this is true, then the 3rd one from the top should be a match, because is set to: E:/code/frontend/msvc_2015/third_party/installed And is set to ZLIB in find_package() first argument, so it should be adding that to the end. I need to keep CMAKE_PREFIX_PATH pointing to the parent directory ("installed") because I have other libraries that get installed in that directory, each with their own directory to contain their installation files. If find_package() is appending to like it says it should, it should find each one of them without switching the value of CMAKE_PREFIX_PATH. Am I misunderstanding something? On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: > Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? > > On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey > wrote: >> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>> On 08/29/2017 10:55 AM, Brad King wrote: On 08/29/2017 10:48 AM, Robert Dailey wrote: > CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed > CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with drive letters on Windows. >>> >>> Oops, sent too soon. >>> >>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for >>> cross-compiling >>> to re-root paths like `/usr` into some prefix on the host. >>> >>> -Brad >> >> Ok but even if I remove that, find_package() still isn't working.. >> -- >> >> 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://ww
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
On 08/29/2017 11:33 AM, David Cole wrote: > That's correct: > > find modules do what they want, and most do not pay attention to > CMAKE_PREFIX_PATH. CMAKE_PREFIX_PATH *is* used by find modules. The find modules use find_* commands, and those use CMAKE_PREFIX_PATH. See the documentation of find_library, find_path, etc. for details. Each command searches an appropriate `/` where `` is based on the kind of command doing the searching. -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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
Thanks for your help, the problem is that I was expecting too much consistency between find module behavior. I'll treat them as if I have no guarantees. Last question: Are there guarantees with find modules and CMAKE_FIND_ROOT_PATH? I'm asking because on Android, when I use find_package(), behavior is different because the NDK's toolchain file sets: set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) list(APPEND CMAKE_FIND_ROOT_PATH "${ANDROID_NDK}") To try to "intercept" the search of NDK for libraries using find_package(), I try this: set( CMAKE_FIND_ROOT_PATH ${ZIOSK_THIRD_PARTY_INSTALL} ${CMAKE_FIND_ROOT_PATH} ) However, after running, it's always finding results in the NDK directory set by the toolchain file, even though I put mine first in the list. Furthermore, my install of zlib has the correct version, the NDK one does not, but it still says it founds the NDK version. On Tue, Aug 29, 2017 at 10:33 AM, David Cole wrote: > That's correct: > > find modules do what they want, and most do not pay attention to > CMAKE_PREFIX_PATH. > > It's better to use a config file, but when you have to use a find > module, you have to dig in and figure out the right way to use each > one. > > > > On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey > wrote: >> I think the discrepancy here might be config vs module find mode. The >> documentation I linked seems to be for config mode only, however I'm >> utilizing the CMake-shipped FindZLIB.cmake module to find this >> particular library. Does this offer no guarantees on how >> CMAKE_PREFIX_PATH is used? >> >> On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey >> wrote: >>> What I'm hoping for is that find_package() follows the rules it >>> documents here: >>> https://cmake.org/cmake/help/v3.6/command/find_package.html >>> >>> Specifically, it states it searches these paths (and that is >>> treated case-insensitive): >>> >>> / (W) >>> /(cmake|CMake)/ (W) >>> /*/ (W) >>> /*/(cmake|CMake)/ (W) >>> /(lib/|lib|share)/cmake/*/ (U) >>> /(lib/|lib|share)/*/(U) >>> /(lib/|lib|share)/*/(cmake|CMake)/ (U) >>> >>> If this is true, then the 3rd one from the top should be a match, >>> because is set to: >>> >>> E:/code/frontend/msvc_2015/third_party/installed >>> >>> And is set to ZLIB in find_package() first argument, so it >>> should be adding that to the end. >>> >>> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory >>> ("installed") because I have other libraries that get installed in >>> that directory, each with their own directory to contain their >>> installation files. If find_package() is appending to >>> like it says it should, it should find each one of them without >>> switching the value of CMAKE_PREFIX_PATH. >>> >>> Am I misunderstanding something? >>> >>> >>> On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey wrote: > On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >> On 08/29/2017 10:55 AM, Brad King wrote: >>> On 08/29/2017 10:48 AM, Robert Dailey wrote: CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>> >>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>> drive letters on Windows. >> >> Oops, sent too soon. >> >> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for >> cross-compiling >> to re-root paths like `/usr` into some prefix on the host. >> >> -Brad > > Ok but even if I remove that, find_package() still isn't working.. > -- > > 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 -- 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:/
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
That's correct: find modules do what they want, and most do not pay attention to CMAKE_PREFIX_PATH. It's better to use a config file, but when you have to use a find module, you have to dig in and figure out the right way to use each one. On Tue, Aug 29, 2017 at 11:25 AM, Robert Dailey wrote: > I think the discrepancy here might be config vs module find mode. The > documentation I linked seems to be for config mode only, however I'm > utilizing the CMake-shipped FindZLIB.cmake module to find this > particular library. Does this offer no guarantees on how > CMAKE_PREFIX_PATH is used? > > On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey > wrote: >> What I'm hoping for is that find_package() follows the rules it >> documents here: >> https://cmake.org/cmake/help/v3.6/command/find_package.html >> >> Specifically, it states it searches these paths (and that is >> treated case-insensitive): >> >> / (W) >> /(cmake|CMake)/ (W) >> /*/ (W) >> /*/(cmake|CMake)/ (W) >> /(lib/|lib|share)/cmake/*/ (U) >> /(lib/|lib|share)/*/(U) >> /(lib/|lib|share)/*/(cmake|CMake)/ (U) >> >> If this is true, then the 3rd one from the top should be a match, >> because is set to: >> >> E:/code/frontend/msvc_2015/third_party/installed >> >> And is set to ZLIB in find_package() first argument, so it >> should be adding that to the end. >> >> I need to keep CMAKE_PREFIX_PATH pointing to the parent directory >> ("installed") because I have other libraries that get installed in >> that directory, each with their own directory to contain their >> installation files. If find_package() is appending to >> like it says it should, it should find each one of them without >> switching the value of CMAKE_PREFIX_PATH. >> >> Am I misunderstanding something? >> >> >> On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >>> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >>> >>> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >>> wrote: On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: > On 08/29/2017 10:55 AM, Brad King wrote: >> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >> >> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >> drive letters on Windows. > > Oops, sent too soon. > > CMAKE_FIND_ROOT_PATH should not be necessary here. It's for > cross-compiling > to re-root paths like `/usr` into some prefix on the host. > > -Brad Ok but even if I remove that, find_package() still isn't working.. -- 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 -- 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] [cmake-developers] Debugging find_package() search behavior?
Is there a ZLIBConfig.cmake file which find_package is searching for? (i.e. -- somewhere under that directory does that file exist?) On Windows the case won't matter, but on Linux, a find_package(ZLIB will expect a case-sensitive match on a ZLIBConfig.cmake file. If ZLIBConfig.cmake exists, it needs to exist in one of the locations on that find_package documentation snippet you sent. If it's not directly in the "zlib" folder, or one of the other folders listed, then it won't be found. The directory it is in, or something matching one of those in the list needs to be included in your CMAKE_PREFIX_PATH. If that file does not exist, then the CMake FindZLIB.cmake module will be used in an attempt to find your zlib... And the help for that speaks of setting a ZLIB_ROOT var if you want to direct it to find a given zlib. See the "HINTS" section here: https://cmake.org/cmake/help/v3.6/module/FindZLIB.html#hints One more hint regarding CMAKE_PREFIX_PATH : despite its name, it is a **list** of paths, and you can use multiple semi-colon separated values if necessary. So, if appending "/zlib" works, then you could always find zlib and all your other stuff too by using two directories as your CMAKE_PREFIX_PATH value. HTH, David C. On Tue, Aug 29, 2017 at 11:11 AM, Robert Dailey wrote: > What I'm hoping for is that find_package() follows the rules it > documents here: > https://cmake.org/cmake/help/v3.6/command/find_package.html > > Specifically, it states it searches these paths (and that is > treated case-insensitive): > > / (W) > /(cmake|CMake)/ (W) > /*/ (W) > /*/(cmake|CMake)/ (W) > /(lib/|lib|share)/cmake/*/ (U) > /(lib/|lib|share)/*/(U) > /(lib/|lib|share)/*/(cmake|CMake)/ (U) > > If this is true, then the 3rd one from the top should be a match, > because is set to: > > E:/code/frontend/msvc_2015/third_party/installed > > And is set to ZLIB in find_package() first argument, so it > should be adding that to the end. > > I need to keep CMAKE_PREFIX_PATH pointing to the parent directory > ("installed") because I have other libraries that get installed in > that directory, each with their own directory to contain their > installation files. If find_package() is appending to > like it says it should, it should find each one of them without > switching the value of CMAKE_PREFIX_PATH. > > Am I misunderstanding something? > > > On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >> >> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >> wrote: >>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: On 08/29/2017 10:55 AM, Brad King wrote: > On 08/29/2017 10:48 AM, Robert Dailey wrote: >> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed > > I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with > drive letters on Windows. Oops, sent too soon. CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling to re-root paths like `/usr` into some prefix on the host. -Brad >>> >>> Ok but even if I remove that, find_package() still isn't working.. >>> -- >>> >>> 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 -- 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] [cmake-developers] Debugging find_package() search behavior?
I think the discrepancy here might be config vs module find mode. The documentation I linked seems to be for config mode only, however I'm utilizing the CMake-shipped FindZLIB.cmake module to find this particular library. Does this offer no guarantees on how CMAKE_PREFIX_PATH is used? On Tue, Aug 29, 2017 at 10:11 AM, Robert Dailey wrote: > What I'm hoping for is that find_package() follows the rules it > documents here: > https://cmake.org/cmake/help/v3.6/command/find_package.html > > Specifically, it states it searches these paths (and that is > treated case-insensitive): > > / (W) > /(cmake|CMake)/ (W) > /*/ (W) > /*/(cmake|CMake)/ (W) > /(lib/|lib|share)/cmake/*/ (U) > /(lib/|lib|share)/*/(U) > /(lib/|lib|share)/*/(cmake|CMake)/ (U) > > If this is true, then the 3rd one from the top should be a match, > because is set to: > > E:/code/frontend/msvc_2015/third_party/installed > > And is set to ZLIB in find_package() first argument, so it > should be adding that to the end. > > I need to keep CMAKE_PREFIX_PATH pointing to the parent directory > ("installed") because I have other libraries that get installed in > that directory, each with their own directory to contain their > installation files. If find_package() is appending to > like it says it should, it should find each one of them without > switching the value of CMAKE_PREFIX_PATH. > > Am I misunderstanding something? > > > On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: >> Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? >> >> On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey >> wrote: >>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: On 08/29/2017 10:55 AM, Brad King wrote: > On 08/29/2017 10:48 AM, Robert Dailey wrote: >> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed > > I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with > drive letters on Windows. Oops, sent too soon. CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling to re-root paths like `/usr` into some prefix on the host. -Brad >>> >>> Ok but even if I remove that, find_package() still isn't working.. >>> -- >>> >>> 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 -- 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] [cmake-developers] Debugging find_package() search behavior?
What I'm hoping for is that find_package() follows the rules it documents here: https://cmake.org/cmake/help/v3.6/command/find_package.html Specifically, it states it searches these paths (and that is treated case-insensitive): / (W) /(cmake|CMake)/ (W) /*/ (W) /*/(cmake|CMake)/ (W) /(lib/|lib|share)/cmake/*/ (U) /(lib/|lib|share)/*/(U) /(lib/|lib|share)/*/(cmake|CMake)/ (U) If this is true, then the 3rd one from the top should be a match, because is set to: E:/code/frontend/msvc_2015/third_party/installed And is set to ZLIB in find_package() first argument, so it should be adding that to the end. I need to keep CMAKE_PREFIX_PATH pointing to the parent directory ("installed") because I have other libraries that get installed in that directory, each with their own directory to contain their installation files. If find_package() is appending to like it says it should, it should find each one of them without switching the value of CMAKE_PREFIX_PATH. Am I misunderstanding something? On Tue, Aug 29, 2017 at 10:06 AM, David Cole wrote: > Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? > > On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey > wrote: >> On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >>> On 08/29/2017 10:55 AM, Brad King wrote: On 08/29/2017 10:48 AM, Robert Dailey wrote: > CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed > CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with drive letters on Windows. >>> >>> Oops, sent too soon. >>> >>> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >>> to re-root paths like `/usr` into some prefix on the host. >>> >>> -Brad >> >> Ok but even if I remove that, find_package() still isn't working.. >> -- >> >> 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 -- 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] [cmake-developers] Debugging find_package() search behavior?
Shouldn't the "/zlib" at the end be included in your CMAKE_PREFIX_PATH? On Tue, Aug 29, 2017 at 11:01 AM, Robert Dailey wrote: > On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: >> On 08/29/2017 10:55 AM, Brad King wrote: >>> On 08/29/2017 10:48 AM, Robert Dailey wrote: CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >>> >>> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >>> drive letters on Windows. >> >> Oops, sent too soon. >> >> CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling >> to re-root paths like `/usr` into some prefix on the host. >> >> -Brad > > Ok but even if I remove that, find_package() still isn't working.. > -- > > 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 -- 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] [cmake-developers] Debugging find_package() search behavior?
On Tue, Aug 29, 2017 at 9:56 AM, Brad King wrote: > On 08/29/2017 10:55 AM, Brad King wrote: >> On 08/29/2017 10:48 AM, Robert Dailey wrote: >>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed >> >> I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with >> drive letters on Windows. > > Oops, sent too soon. > > CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling > to re-root paths like `/usr` into some prefix on the host. > > -Brad Ok but even if I remove that, find_package() still isn't working.. -- 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] [cmake-developers] Debugging find_package() search behavior?
On 08/29/2017 10:55 AM, Brad King wrote: > On 08/29/2017 10:48 AM, Robert Dailey wrote: >> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed >> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed > > I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with > drive letters on Windows. Oops, sent too soon. CMAKE_FIND_ROOT_PATH should not be necessary here. It's for cross-compiling to re-root paths like `/usr` into some prefix on the host. -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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
On 08/29/2017 10:48 AM, Robert Dailey wrote: > CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed > CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with drive letters on Windows. -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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
I am doing that. Here is a live example: Library is zlib, installed here: E:\code\frontend\msvc_2015\third_party\installed\zlib (has include, lib, bin, share inside it) I set the following variables (Using the set() command (non-cache) inside my CMake script, before the find_package calls): CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed And then the find_package() command is executed: find_package( ZLIB 1.2.11 EXACT REQUIRED ) And fails with: CMake Error at E:/Program Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find ZLIB (missing: ZLIB_LIBRARY ZLIB_INCLUDE_DIR) (Required is exact version "1.2.11") Call Stack (most recent call first): E:/Program Files/CMake/share/cmake-3.9/Modules/FindPackageHandleStandardArgs.cmake:377 (_FPHSA_FAILURE_MESSAGE) E:/Program Files/CMake/share/cmake-3.9/Modules/FindZLIB.cmake:112 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) Core/ThirdParty/zlib/CMakeLists.txt:6 (find_package) On Tue, Aug 29, 2017 at 9:33 AM, Brad King wrote: > On 08/29/2017 10:27 AM, Robert Dailey wrote: >> I'm relying on the two variables above to control this behavior, but >> CMAKE_INSTALL_PREFIX doesn't work well for both purposes. > > Use CMAKE_PREFIX_PATH, not CMAKE_INSTALL_PREFIX, to control > the set of prefixes that find commands search. > > -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
Re: [CMake] [cmake-developers] Debugging find_package() search behavior?
On 08/29/2017 10:27 AM, Robert Dailey wrote: > I'm relying on the two variables above to control this behavior, but > CMAKE_INSTALL_PREFIX doesn't work well for both purposes. Use CMAKE_PREFIX_PATH, not CMAKE_INSTALL_PREFIX, to control the set of prefixes that find commands search. -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