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.
