Xcode configuration woes

[Ryan Schmidt]

On Nov 9, 2018, at 13:40, Vincent Habchi wrote:

>> Yup, NSAppearanceNameDarkAqua is new in macOS 10.14.
> […]
> 
>> So you must be on macOS 10.13 with Xcode 10.
> 
> Unfortunately not : 
>> uname -a
> Darwin Air.local 18.2.0 Darwin Kernel Version 18.2.0: Sat Nov  3 12:30:49 PDT 2018; root:xnu-4903.231.1~11/RELEASE_X86_64 x86_64
> 
> As you can see, I even run a beta of 10.14.2.
> 
> Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/
> total 43720
> -rwxr-xr-x    1 root  wheel  47503104  4 Nov 09:31 AppKit
> -rw-r--r--    1 root  wheel    309176 25 Jul 18:33 AppKit.tbd
> drwxr-xr-x  259 root  wheel      8288 25 Jul 18:33 Headers
> drwxr-xr-x    3 root  wheel        96 25 Jul 18:33 Modules
> drwxr-xr-x   77 root  wheel      2464  7 Nov 22:57 Resources
> drwxr-xr-x    8 root  wheel       256 21 Sep 05:59 XPCServices
> drwxr-xr-x    3 root  wheel        96  7 Nov 22:57 _CodeSignature
> 
> Air > ls -l /System/Library/Frameworks/AppKit.framework/Versions/Current/Headers/
> total 1328
> -rw-r--r--  1 root  wheel  301352 15 Mar  2018 AppKit.apinotes
> -rw-r--r--  1 root  wheel    8613 15 Mar  2018 AppKit.h
> -rw-r--r--  1 root  wheel    1920 15 Mar  2018 AppKitDefines.h
> […]
> 
> All headers here are dated 15 Mars 2018, and are obviously 10.13 versions.
> 
> I have Xcode 10.1 installed, and:
> 
> Air > xcode-select --install
> xcode-select: error: command line tools are already installed, use "Software Update" to install updates
> 
> Weird, no?


Weird indeed, but I can confirm it on the Mojave buildbot worker running 10.14 (which never had the Mojave beta installed) and on my 10.14.1 system (which started out with the public betas). The system headers do not mention NSAppearanceNameDarkAqua but the headers in the 10.14 SDK do.

I don't know why Apple is doing this to us. This contradicts what we previously knew about how SDKs were meant to function. The SDKs are supposed to be the same as the system headers of a particular version. We may want to file a bug report with Apple about this. Maybe then they will fix it in a future version of Mojave.

In its current design, as I recall, MacPorts assumes that if you ask for the 10.X SDK, and you are running on 10.X, then using the SDK would be the same as using the system headers, and therefore MacPorts uses the system headers instead of the SDK.

However, 10.14 does not have the /usr/include portion of the system headers anymore. If MacPorts sees that /usr/include isn't there, then it should always supply the flags that tell it to use the SDK. If we're doing that, then you should not have seen this problem, assuming the build system uses the SDK flags correctly. Looks like this port is using using cmake, which should know how to deal with SDK flags.

Unless you do have /usr/include on your system. Do you? For users who have installed /usr/include using the hidden installer package, you might need to have the port set configure.sdkroot to the path of the SDK, even when MacPorts wouldn't otherwise have done so.