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
<rcdailey.li...@gmail.com> 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 <dlrd...@aol.com> 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
>> <rcdailey.li...@gmail.com> 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
>>> <rcdailey.li...@gmail.com> 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 <name> is
>>>> treated case-insensitive):
>>>>
>>>> <prefix>/ (W)
>>>> <prefix>/(cmake|CMake)/ (W)
>>>> <prefix>/<name>*/ (W)
>>>> <prefix>/<name>*/(cmake|CMake)/ (W)
>>>> <prefix>/(lib/<arch>|lib|share)/cmake/<name>*/ (U)
>>>> <prefix>/(lib/<arch>|lib|share)/<name>*/ (U)
>>>> <prefix>/(lib/<arch>|lib|share)/<name>*/(cmake|CMake)/ (U)
>>>>
>>>> If this is true, then the 3rd one from the top should be a match,
>>>> because <prefix> is set to:
>>>>
>>>> E:/code/frontend/msvc_2015/third_party/installed
>>>>
>>>> And <name> 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 <name> to <prefix>
>>>> 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 <dlrd...@aol.com> 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
>>>>> <rcdailey.li...@gmail.com> wrote:
>>>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <brad.k...@kitware.com> 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
