On 2017 M10 1, Sun 12:38:43 CEST David Cole via CMake wrote:
> No, I was already promptly corrected by Brad, too. I was not
> accounting for the fact that the other find_* calls used inside of
> find modules also use CMAKE_PREFIX_PATH. I was thinking of its use to
> find a project's config file fro
No, I was already promptly corrected by Brad, too. I was not
accounting for the fact that the other find_* calls used inside of
find modules also use CMAKE_PREFIX_PATH. I was thinking of its use to
find a project's config file from the find_package config mode.
I stand corrected. Again. ;-)
Howev
On 2017 M08 29, Tue 11:33:15 CEST David Cole via cmake-developers wrote:
> That's correct:
>
> find modules do what they want, and most do not pay attention to
> CMAKE_PREFIX_PATH.
are you sure ?
As long as NO_DEFAULT_PATH is not used in the find_*() calls, CMAKE_PREFIX_PATH
is used automaticall
> 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:
> >
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. Th
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
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
>> w
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 CMA
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 hel
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_
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(), behavio
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:
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 nee
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 AM, Robert Dailey wrote:
CMAKE_PREFIX_PATH:
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
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 inter
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
--
P
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):
CM
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
--
Pow
22 matches
Mail list logo
