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. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers