[cmake-developers] Cross compiling toolchain variables

Brad King brad.king at kitware.com
Wed Oct 30 14:50:48 EDT 2013


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.

Why do you need NO_DEFAULT_PATH when looking for GL libraries?
You're looking for a system-provided library so why tell CMake not
to search the system paths it knows?

>> 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.  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 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.

>> behavior should be the same in CMake 2.8.12.1.

We will not be changing non-regressed behavior in a tweak release.

> I pushed the osx-sysroot-no-system topic to illustrate what I mean by this. 
> I haven't tested it, because I'm not familiar enough with mac, so I haven't 
> merged it to next yet. 

Don't mess with the "CMAKE_*_IMPLICIT_*" variables.  Those are for
link line computation, not "find_*" commands.

-Brad



More information about the cmake-developers mailing list