Force Xcode SDK instead of CLI SDK?

Aaron Madlon-Kay amake at
Fri Nov 20 14:20:12 UTC 2020

> 1. Your configuration value for developer_dir in macports.conf (I'm
>    assuming it's the default).

It's the default (commented out in macports.conf).

> 2. Whether
>    ${developer_dir}/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
>    exists on your system.

I take ${developer_dir} to be
/Applications/, in which case it does not

% ls -al /Applications/
total 0
drwxr-xr-x  5 root  wheel  160 Nov 13 13:55 .
drwxr-xr-x  6 root  wheel  192 Oct 24 11:20 ..
drwxr-xr-x  5 root  wheel  160 Oct 20 05:33 DriverKit20.0.sdk
drwxr-xr-x  7 root  wheel  224 Nov 13 13:56 MacOSX.sdk
lrwxr-xr-x  1 root  wheel   10 Nov 13 13:52 MacOSX11.0.sdk -> MacOSX.sdk

> I'm guessing your Xcode is new enough to only ship the MacOSX11.0.sdk in
> Xcode's developer dir? That would then run through the check at [1] and
> continue below, which would run
>   xcrun --sdk macosx10.15 --show-sdk-path
> which would fail when you only have the 11.0 one in Xcode.

My Xcode is 12.2 12B45b, update-installed over many previous
iterations from the app store. The invocation does indeed fail:

% xcrun --sdk macosx10.15 --show-sdk-path
xcodebuild: error: SDK "macosx10.15" cannot be located.
xcodebuild: error: SDK "macosx10.15" cannot be located.
xcrun: error: unable to lookup item 'Path' in SDK 'macosx10.15'

> That would then bring you to [2] which as a last resort tries to find
> the matching MacOSX10.15.sdk in the command line tools path before
> checking for the unversioned one (which would be a symlink to 11.0) in
> Xcode.
> Maybe we shouldn't run [2] when `use_xcode yes` is set, and rather
> prefer the unversioned SDK from Xcode than the matching SDK from the
> command line tools.

Seems reasonable to me.

Thanks for stepping through the logic for me.


More information about the macports-dev mailing list