Re: [cmake-developers] [CMake] Debugging find_package() search behavior?
On 08/29/2017 05:28 PM, Robert Dailey wrote: > One other thing: Is there a way to make find_package() default to > CONFIG mode? Right now it seems to search MODULE first, then CONFIG. > But right now the only way to enable config is to explicitly use the > CONFIG option or make sure CMake can't find a find module by > manipulating CMAKE_MODULE_PATH. It only searches in one mode. The presence or non-presence of a find module in CMAKE_MODULE_PATH is the way the mode is selected if an explicit CONFIG option is not given. There is an issue about this here: https://gitlab.kitware.com/cmake/cmake/issues/16805 with an unfinished/expired MR: https://gitlab.kitware.com/cmake/cmake/merge_requests/768 Some find modules call `find_package(MyPackage CONFIG ...)` as their first step if the external package may be found by either method. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Debugging find_package() search behavior?
One other thing: Is there a way to make find_package() default to CONFIG mode? Right now it seems to search MODULE first, then CONFIG. But right now the only way to enable config is to explicitly use the CONFIG option or make sure CMake can't find a find module by manipulating CMAKE_MODULE_PATH. On Tue, Aug 29, 2017 at 12:51 PM, Robert Dailey wrote: > On Tue, Aug 29, 2017 at 12:12 PM, Rolf Eike Beer wrote: >> Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey: >>> 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. >> >> The trick with ExternalProject_Add is to also build your project with it, and >> not with add_subdirectory, i.e. the CMakeLists.txt that drives the build >> needs >> to be one level above your actual project. This way all things are done in >> order, so the dependencies are build before your main project. > > That's not going to work since for multi-configuration generators you > want to be able to edit and build your code through the IDE, not via > command line. > > Regarding find modules: it seems simpler at this point to just redo > the install logic of upstream libraries using configuration packages > instead, that way I can have finer control over how packages are > found. Plus it's good for upstream repositories to be able to > contribute this back. > > Thanks to everyone for their feedback. I have a much better > understanding of this now, although I still strongly feel this is > crazy complex. But nothing we can do about that I guess... it's just > the nature of things. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Debugging find_package() search behavior?
On Tue, Aug 29, 2017 at 12:12 PM, Rolf Eike Beer wrote: > Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey: >> 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. > > The trick with ExternalProject_Add is to also build your project with it, and > not with add_subdirectory, i.e. the CMakeLists.txt that drives the build needs > to be one level above your actual project. This way all things are done in > order, so the dependencies are build before your main project. That's not going to work since for multi-configuration generators you want to be able to edit and build your code through the IDE, not via command line. Regarding find modules: it seems simpler at this point to just redo the install logic of upstream libraries using configuration packages instead, that way I can have finer control over how packages are found. Plus it's good for upstream repositories to be able to contribute this back. Thanks to everyone for their feedback. I have a much better understanding of this now, although I still strongly feel this is crazy complex. But nothing we can do about that I guess... it's just the nature of things. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] Debugging find_package() search behavior?
Am Dienstag, 29. August 2017, 11:21:42 schrieb Robert Dailey: > 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. The trick with ExternalProject_Add is to also build your project with it, and not with add_subdirectory, i.e. the CMakeLists.txt that drives the build needs to be one level above your actual project. This way all things are done in order, so the dependencies are build before your main project. Eike -- signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers
Re: [cmake-developers] [CMake] 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-developers
