[Interest] [OS X] qmake - "Could not resolve SDK path for 'macosx10.8'"

[Till Oliver Knoll]

Am 06.10.2014 um 10:06 schrieb Gustavsen Richard <Richard.Gustavsen at theqtcompany.com>:

> Note that this issue is fixed for Qt-5.3, which is build against the latest SDK.

5.3? Are you sure? I still had Qt 5.3.1 installed when noticing this issue. So I took this as an occasion to install the latest Qt 5.3.2 (after de-installing the previous one) and when running qmake (within Qt Creator which came with that stock Qt installation) it would still complain about a "missing 10.8 SDK".

That is, at the time when qmake is trying a so-called .qmake.stash (?) file.

On existing projects of mine - where said .qmake.stash file already exists from previous qmake runs - qmake would happily create the corresponding Makefiles, but while compiling the build process then fails with "/Applications/Xcode/.../10.8/SDK/.../include" not found and corresponding follow-up errors such as "NSUrl.h" not found etc.

Again, setting the qmake "SDK_VERSION" (?) variable to "10.9" (either "per project"  or "globally", as suggested by Sean) fixes things for me.

I am not an Xcode/Apple developer expert. However I have understood that there is the concept of "weak linking" which is controlled by setting the "SDK" and "Minimum Target" variables. And as long as an application/library makes explicit runtime checks for availability of functions it can run on lower OS releases as well (where the functionality is not yet present) - as long as this functionality is /optional/ for the application, off course.

So let's assume the upcoming Qt 5.4 was build on OS X 10.10 Yosemite with some Xcode 7 and an "10.10 SDK" which would not be available to Xcode 6 on OS X 10.9 Mavericks (I assume).

While Qt itself would certainly "run" on my 10.9, wouldn't that also mean that I could not use that Qt installation anymore for building my applications, since I was missing that "10.10 SDK"? Or could I work around this (again) by setting that "SDK VERSION" variable explicitly to 10.9, just like in the above case where Qt was (apparently) build against a /lower/ SDK?

In any case, as long as Apple continues shipping their Xcode with only /one/ SDK I don't think there could be a solution which "pleases us all": There will always be folks among us who will have to set some variables manually (besides compiling Qt from source).

Not a big issue - just something one has to keep in mind.

Unless "per OS version (compiler/SDK versions?)" builds of Qt are provided ;) But that's most likely out of the question.

Cheers,
  Oliver