[prev in list] [next in list] [prev in thread] [next in thread]
List: cmake
Subject: Re: [CMake] CMAKE_SYSROOT and CMAKE_OSX_SYSROOT
From: Craig Scott <craig.scott () crascit ! com>
Date: 2018-03-26 10:32:00
Message-ID: CA+dygYn49nadDkausyea2fLaWvr5ryhcc2GKwBftXWG=ezE65w () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Mon, Mar 26, 2018 at 8:19 PM, James Weir <james.weir@wesio.co.uk> wrote:
> I've recently been experimenting with using Conan as a package manager for
> our C++ components, the good news is most things work really well but I've
> come across something which I'm not sure what the behaviour should be with
> regards to CMake. The problem occurs for me when building for Darwin
> targets (macOS and iOS), specifically around the behaviour of CMAKE_SYSROOT
> and CMAKE_OSX_SYSROOT.
>
> In short conan cmake builder sets CMAKE_SYSROOT but not CMAKE_OSX_SYSROOT
> and this causes me problems as I end up with multiple isysroot parameters
> given to the compiler, typically the host one trumps and so I end up with
> build errors due to trying to use includes from the macOS platform SDK
> rather than the appropriate iOS one. I can work around it by setting
> CMAKE_OSX_SYSROOT explicitly to to the same as CMAKE_SYSROOT and then
> everything works correctly, but could someone tell me why there are two
> SYSROOTs in the first place and what the expected behaviour should be?
>
While I can't answer the "why" part, my understanding is that CMAKE_SYSROOT
isn't usually set when building for any Apple platform, but you do
definitely want CMAKE_OSX_SYSROOT set as it is the one that controls the
SDK used, etc. The CMAKE_OSX_SYSROOT can be something as simple as
"iphoneos" rather than a full path to the actual SDK location (the need to
use a full path to an SDK should be rare, it's usually going to be more
flexible to specify just the basic family of SDK you want to use).
--
Craig Scott
Melbourne, Australia
https://crascit.com
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar \
26, 2018 at 8:19 PM, James Weir <span dir="ltr"><<a \
href="mailto:james.weir@wesio.co.uk" \
target="_blank">james.weir@wesio.co.uk</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">I've recently been experimenting with using Conan as a \
package manager for our C++ components, the good news is most things work really well \
but I've come across something which I'm not sure what the behaviour should be with \
regards to CMake. The problem occurs for me when building for Darwin targets (macOS \
and iOS), specifically around the behaviour of CMAKE_SYSROOT and \
CMAKE_OSX_SYSROOT.<br> <br>
In short conan cmake builder sets CMAKE_SYSROOT but not CMAKE_OSX_SYSROOT and this \
causes me problems as I end up with multiple isysroot parameters given to the \
compiler, typically the host one trumps and so I end up with build errors due to \
trying to use includes from the macOS platform SDK rather than the appropriate iOS \
one. I can work around it by setting CMAKE_OSX_SYSROOT explicitly to to the same as \
CMAKE_SYSROOT and then everything works correctly, but could someone tell me why \
there are two SYSROOTs in the first place and what the expected behaviour should \
be?<br></blockquote><div><br></div><div>While I can't answer the "why" \
part, my understanding is that CMAKE_SYSROOT isn't usually set when building for \
any Apple platform, but you do definitely want CMAKE_OSX_SYSROOT set as it is the one \
that controls the SDK used, etc. The CMAKE_OSX_SYSROOT can be something as simple as \
"iphoneos" rather than a full path to the actual SDK location (the need to \
use a full path to an SDK should be rare, it's usually going to be more flexible \
to specify just the basic family of SDK you want to \
use).</div></div><div><br></div>-- <br><div class="gmail_signature" \
data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div \
dir="ltr">Craig Scott<br><div>Melbourne, Australia</div><div><a \
href="https://crascit.com" \
target="_blank">https://crascit.com</a><br></div></div></div></div></div></div></div> \
</div></div>
--
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:
https://cmake.org/mailman/listinfo/cmake
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic