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:
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
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
--
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):
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
--
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