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
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: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
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()
> 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:
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
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.
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
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
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
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
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
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(),
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
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
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
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)/
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
18 matches
Mail list logo