Use xcrun --show-sdk-version to determine macOS SDK version

[chrstphrchvz]

This approach should be more reliable than grepping the SDK path, and allow using an SDK whose path doesn’t indicate the version.

---

MacPorts provides a port for ispc. I notice that its builds for ispc 1.16.0 failed on macOS 10.15 and earlier: the SDK version fails to be detected, and this leads to trying to build ARM support when the SDK doesn’t support it:

-- Using macOS SDK path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
-- MacOS_SDK version: 
CMake Warning at CMakeLists.txt:166 (message):
  MacOS SDK version was not detected, assuming 11.0, enabling ARM support

In file included from builtins/builtins-c-cpu.cpp:69:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/unistd.h:71:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/_types.h:27:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:32:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:807:2: error: Unsupported architecture
#error Unsupported architecture
 ^

I based this approach on existing usage of xcrun in CMakeLists.txt, but I am not familiar with CMake, so I would appreciate others’ reviews.

Ping @dbabokin (author of the affected portions of CMakeLists.txt)

[dbabokin]

When I implemented initial patch, I tried xcrun --show-sdk-version in my setup, but it didn't work for me for some reason. I need to give a try with your patch and double check it in my setup. It will take some time (a day probably) - I have several macs where I try this kind of fixes to make sure that it works in all setups that I have.

[chrstphrchvz]

I had tried this change on my Mac which currently doesn’t have full Xcode, only the command line tools, and only up to the point in the configuration where I could tell the change worked (i.e. without fully building ispc; notice SDK version is then reported as 10.15.6 rather than 10.15):

-- Using macOS SDK path /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
-- MacOS_SDK version: 10.15.6
-- MacOS_SDK does NOT supports ARM (SDK ver < 11.0)

Unfortunately I now notice this change doesn’t prevent issues for MacPorts CI builds, which do use full Xcode (see macports/macports-ports#11487). I’m not aware why it doesn’t work; my guess is that xcrun behaves differently under full Xcode (which has xcodebuild).

-- Using macOS SDK path /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk
xcodebuild: error: SDK "/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk" cannot be located.
xcrun: error: unable to lookup item 'SDKVersion' in SDK '/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk'
-- MacOS_SDK version: 
CMake Warning at CMakeLists.txt:167 (message):
  MacOS SDK version was not detected, assuming 11.0, enabling ARM support

Does this resemble the issue previously encountered with xcrun --show-sdk-version?

[dbabokin]

I think that's what I had, so I decided to go with current patch.

[dbabokin]

It appears that xcrun --sdk-show-version works only against SDK installations as part of XCode. Standalone locations or as part of CommandLineTools are not working. If I move /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk, then it works in the new location. So it's not the SDK itself, but the fact that it's located in XCode folder structure.

[dbabokin]

@chrstphrchvz what is your specific problem here that you are trying to solve?

Here's what I have on my system by default:

> ls -al /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
total 0
drwxr-xr-x  6 root  wheel  192 Jul  2 12:52 .
drwxr-xr-x  6 root  wheel  192 Jan 27 14:04 ..
drwxr-xr-x  5 root  wheel  160 Jan 27 14:04 DriverKit20.2.sdk
drwxr-xr-x  7 root  wheel  224 Jan 27 14:04 MacOSX.sdk
lrwxr-xr-x  1 root  wheel   10 Dec 14  2020 MacOSX11.1.sdk -> MacOSX.sdk

Note that real folder is MacOSX.sdk and MacOSX11.1.sdk is a symlink. Current algorithm goes through symlink first and then checks the name. I think (but now I'm not sure) that I implemented it this way because Command Line Tools had it this way.

So if we check the name before (or before and after) dereferencing symlink, would that solve your problem?

PS. Experimenting further I see that doing either sudo xcode-select -s /Library/Developer/CommandLineTools or sudo xcode-select -s /Applications/Xcode.app makes xcrun --show-sdk-version work correctly.

[chrstphrchvz]

My impression is that it is preferable to allow arbitrary SDK paths by relying on a “proper” way of retrieving the SDK version, and avoid making any assumptions about the path. I don’t think MacPorts for example can rely on the SDK to have certain a path especially on user machines; it’s something outside of its control.

The next approach I’m inclined to investigate is to use xcodebuild -sdk ${ISPC_MACOS_SDK_PATH} -version SDKVersion if running xcrun --show-sdk-version fails.

Essentially what is wanted is Version key in ${ISPC_MACOS_SDK_PATH}/SDKSettings.plist, but I’m not sure whether there is still a good way of retrieving it directly from the plist file using the command line.

[dbabokin]

Yeah, xcrun --show-sdk-version would be ideal. But the problem is that it doesn't work out of the box in typical setup (I consider Command Line Tools as a common setup). On the other hand, I cannot imaging that any user would rename the MacOS SDK without really, really understanding what they are doing. So parsing the name sounds like a viable plan.

At this point it seems to me that the best way is to try xcrun --show-sdk-version and if it fails, try to fall back to parsing the name as a backup plan.

[dbabokin]

@chrstphrchvz what do you think about checking this in two steps? Does this sound like the right approach to you?

[chrstphrchvz]

I am no longer investigating this issue, sorry.