Debugging find_package() search behavior?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Debugging find_package() search behavior?

Robert Dailey-2
So I'm trying to get CMake to find a package, and it isn't finding it.
I am setting CMAKE_PREFIX_PATH to try to get it to find it. Is there a
way I can view the search paths & prefixes that CMake is using with
each find_package() call? I tried enabling debug and trace output, but
neither of these seem to show any detail of what happens internally
with find_package() searches.

Thanks in advance.
--

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
Reply | Threaded
Open this post in threaded view
|

Re: Debugging find_package() search behavior?

Robert Dailey-2
I want to clarify my post since I've spent some more time on this.

find_package() doesn't seem to work intuitively on Windows. On Linux,
for example, installation prefixes are like "/usr/local", so if I'm
building & installing a library in linux, you'd get a structure like:

/usr/local/include
/usr/local/lib
/usr/local/bin

On Windows, if I make the prefix "C:/Program Files", then you get:

C:/Program Files/include
C:/Program Files/lib
C:/Program Files/bin

This is not the idiomatic way to install libraries on windows.
Instead, it should be:

C:/Program Files/MyLibrary/include
C:/Program Files/MyLibrary/lib
C:/Program Files/MyLibrary/bin

I can achieve this during installation by setting my
CMAKE_INSTALL_PREFIX to "C:/Program Files/MyLibrary", however
CMAKE_INSTALL_PREFIX seems like it should be different when used with
find_package().

After doing tons of reading, the search behavior for find_package() is
very confusing outside of linux. Combined with CMAKE_FIND_ROOT_PATH, I
have no idea what the heck these should be on Windows.

Suppose I want to use a super build to build a lot of third party
libraries and install them relative to my CMAKE_BINARY_DIR, and
completely ignore system root paths for find_package() searching. My
first instinct would be to do this:

-D CMAKE_FIND_ROOT_PATH=${CMAKE_BINARY_DIR}/installed_libraries
-D CMAKE_INSTALL_PREFIX=${name_of_library}

Note that there are two goals:

1. The library being built must install its files to
${CMAKE_BINARY_DIR}/installed_libraries/${name_of_library}
2. Any find_package() invocations made by the library being built
should search within ${CMAKE_BINARY_DIR}/installed_libraries

I'm relying on the two variables above to control this behavior, but
CMAKE_INSTALL_PREFIX doesn't work well for both purposes. I can't make
it relative on Windows because it puts it somewhere random on my
filesystem, I think in program files. I'm not sure what
CMAKE_INSTALL_PREFIX does if it isn't an absolute path (but based on
linux behavior it should just append to the end of
CMAKE_FIND_ROOT_PATH I think?)

How can I get the proper install & find_package behavior on Windows
based on the requirements above?

On Sun, Aug 27, 2017 at 2:55 PM, Robert Dailey <[hidden email]> wrote:
> So I'm trying to get CMake to find a package, and it isn't finding it.
> I am setting CMAKE_PREFIX_PATH to try to get it to find it. Is there a
> way I can view the search paths & prefixes that CMake is using with
> each find_package() call? I tried enabling debug and trace output, but
> neither of these seem to show any detail of what happens internally
> with find_package() searches.
>
> Thanks in advance.
--

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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Brad King
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Robert Dailey-2
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Brad King
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Brad King
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Robert Dailey-2
On Tue, Aug 29, 2017 at 9:56 AM, Brad King <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

CMake mailing list
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
<[hidden email]> wrote:

> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Robert Dailey-2
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 <[hidden email]> 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
> <[hidden email]> wrote:
>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Robert Dailey-2
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
<[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> wrote:
>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

CMake mailing list
In reply to this post by Robert Dailey-2
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
<[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> wrote:
>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

CMake mailing list
In reply to this post by Robert Dailey-2
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
<[hidden email]> 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
> <[hidden email]> 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 <[hidden email]> 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
>>> <[hidden email]> wrote:
>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Robert Dailey-2
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 <[hidden email]> 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
> <[hidden email]> 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
>> <[hidden email]> 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 <[hidden email]> 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
>>>> <[hidden email]> wrote:
>>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Brad King
In reply to this post by CMake mailing list
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 `<prefix>/<dir>` where `<dir>`
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Robert Dailey-2
In reply to this post by Robert Dailey-2
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
<[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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
>>> <[hidden email]> 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 <[hidden email]> 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
>>>>> <[hidden email]> wrote:
>>>>>> On Tue, Aug 29, 2017 at 9:56 AM, Brad King <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Brad King
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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Robert Dailey-2
On Tue, Aug 29, 2017 at 10:54 AM, Brad King <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

CMake mailing list
In reply to this post by Brad King
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 <[hidden email]> 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 `<prefix>/<dir>` where `<dir>`
> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Robert Dailey-2
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 <[hidden email]> 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 <[hidden email]> 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 `<prefix>/<dir>` where `<dir>`
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [cmake-developers] Debugging find_package() search behavior?

Brad King
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
12