[cmake-developers] Cross compiling toolchain variables

[Stephen Kelly]

Brad King wrote:

> On 10/30/2013 05:27 PM, Stephen Kelly wrote:
>> Brad King wrote:
>> 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
> 
> Can you point me to the source of the qmake logic that uses -isysroot
> plus paths not inside the SDK?  I'd like to understand why qmake is
> generating paths that don't actually exist and depend on -isysroot
> to be found, or if I'm misunderstanding your explanation.

Here's the relevant file as far as I know:

 https://qt.gitorious.org/qt/qtbase/source/stable:mkspecs/features/mac/sdk.prf

The issue could be related to order of execution. Maybe my cmake-related 
code is executed before QMAKE_INCDIR_OPENGL is populated in that file.


>> 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.
> 
> The main problem is that the two of us are not educated enough in the
> ways of Mac development to have this debate ;)

Clinton, can you help? Do you respond to offers and promises of cookies?

> I suppose with the default "root path mode" of searching re-rooted
> paths and then the original paths then treating the OSX SDK path as
> one of the rerooting prefixes makes sense.  That way any library
> provided by the system SDK will be found for the proper target
> version and otherwise the search will fall back to looking elsewhere.

Right.

> We'll have to resolve this while combining CMAKE_SYSROOT and
> CMAKE_OSX_SYSROOT.

Yes, I think so too.

Thanks,

Steve.