Re: OS X 10.11.1, non-existing SDK after latest El Capitan update, x11/modular-xorg-xquartz

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Sun, 25 Oct 2015 11:15:23 +0100
Andreas Kusalananda Kähäri <andreas.kahari%icm.uu.se@localhost> wrote:

> Hi,
> 
> There was recently an update to both El Capitan and to Xcode. El Capitan
> is now at version 10.11.1, but Xcode does not currently, as far as I can
> see, provide an 10.11.1 SDK.
> 
> This results in:
> 
> $ cd pkgsrc/x11/modular-xorg-xquartz
> $ bmake update
> xcodebuild: error: SDK "macosx10.11.1" cannot be located.
> xcodebuild: error: SDK "macosx10.11.1" cannot be located.
> xcrun: error: unable to lookup item 'Path' in SDK 'macosx10.11.1'
> bmake: "/Users/kk/pkgsrc/x11/modular-xorg-xquartz/Makefile" line 85:
> warning: "/usr/bin/xcrun --sdk macosx10.11.1 --show-sdk-path" returned
> non-zero status
> [...]
> 
> The Makefile uses "sw_vers -productVersion" to fetch the string
> "10.11.1" and then tries to find the path to the SDK using "xcrun --sdk
> macosx10.11.1 --show-sdk-path", however, there is only the "macosx10.11"
> SDK available. This SDK is found if the "--sdk" switch is removed.
> 
> I'm not sure if "xcrun --show-sdk-path" will always return the most
> recent/correct SDK path, but it certainly does on my two Macintoshes (I
> haven't tinkered with anything in my Xcode installations ever, only done
> ordinary updates through the "App Store"). I'm unfamiliar with the Xcode
> tools...

Replicating the sdk path logic to these packages was a stopgap measure
(they need it to find objc frameworks). I think we need to:

1) fix the logic in mk/platform/Darwin.mk so it knows about 10.11.1.
2) make it unconditionally expose the correct value for packages to use.

Also I wonder if the fact that it prefers /usr/include to what xcrun
tell you should be considered a bug!

But I would like to hear opinions from others before I make any changes.

-Tobias