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 <dlrd...@aol.com> 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 <brad.k...@kitware.com> 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 via email to