[cmake-developers] Cross compiling toolchain variables

[Stephen Kelly]

Brad King wrote:

> On 10/30/2013 12:12 PM, Stephen Kelly wrote:
>> Stephen Kelly wrote:
>>> I think there is a bug here.
> 
> Behavior is as documented so it is at most a missing feature.

That reminds me - CMAKE_OSX_SYSROOT is not documented at all.

> Why do you need NO_DEFAULT_PATH when looking for GL libraries?

I want to make sure that downstream uses the same GL headers and libraries 
as the ones used to build Qt itself. The PATHS is populated with information 
from qmake, and I wanted to prevent cmake finding different headers and 
libraries.

I've just staged a patch to remove that behavior for mac though:

 https://codereview.qt-project.org/#change,69605
 
>>> The paths you added are ignored if I set
>>> NO_DEFAULT_PATH. It seems to me that _CMAKE_OSX_SYSROOT_PATH should be
>>> treated as a root path - controlled by NO_CMAKE_FIND_ROOT_PATH, not by
>>> NO_DEFAULT_PATH. This is the source of the Qt bug report, I think.
>>>
>>> The CMAKE_FIND_ROOT_PATH entries are searched even if NO_DEFAULT_PATH is
>>> specified. That is also the behavior of CMAKE_SYSROOT and if
>>> CMAKE_OSX_SYSROOT is to be merged/made obsolete by CMAKE_SYSROOT, then
>>> the
> 
> We still don't understand the right way to combine them.  In fact this
> might be a distinguishing case between them.

I considered that too. I don't know if selecting an sdk counts as cross-
compiling, or can count as cross-compiling. I think you can select an iphone 
sdk?

> Using CMAKE_SYSROOT is
> an explicit choice to use in typical cross-compiling cases.  Using
> CMAKE_OSX_SYSROOT is common in host-only builds. 

I can imagine setting up a 'cross-compile' to build for fedora on an ubuntu 
system. I'd set up a fedora 'sysroot' with libraries in their fedora 
locations (and {so,}versions). I'd then 'cross-compile' to the same 
architecture use that sysroot to build a binary. I could also have some 
third-party package available on neither distro in a different prefix which 
I add to CMAKE_FIND_ROOT_PATH. 

I could even do that from current ubuntu to an older ubuntu, instead of 
fedora. 

Is that so different to what's happening on mac with OSX_SYSROOT (I don't 
know)?

> I see no reason that
> CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY should cause library searches
> to be restricted to CMAKE_OSX_SYSROOT when no CMAKE_FIND_ROOT_PATH
> or CMAKE_SYSROOT is set.  CMAKE_OSX_SYSROOT is about where the system
> provided SDKs are found, not an isolated cross-compiling development
> tool prefix.

Ok. I thought a mac sdk was 'isolated' and self-contained as far as system 
APIs are concerned (which seems similar to CMAKE_SYSROOT). Where does the 
isolation break-down? Honestly I don't see much of a distinction.

Thanks,

Steve.