On Mar 20, 2018, at 17:22, Jeremy Huddleston Sequoia wrote:
> On Mar 19, 2018, at 4:34 PM, Ryan Schmidt wrote:
>
>> Ok, I've figured out that the reason why I'm not seeing the "Unable to
>> determine location of a macOS SDK" message is that I was running MacPorts
>> 2.4.2 and the message is new for MacPorts 2.5. MacPorts 2.5 considers it an
>> error when it can't find an SDK. MacPorts 2.4.x and earlier just returned
>> the empty string. So you must be running the unreleased MacPorts 2.5.
>>
>> Jeremy added this error message and the change in configure.sdk_root
>> behavior. Jeremy, what should we do about this?
>
> We definitely want to err out if we cannot find an SDK, so we should figure
> out a way to support a better pattern that addresses the problems below.
>
>> For background: the textmate2 port requires the 10.11 SDK or later, so if
>> configure.sdk_version is less than 10.11, it sets it to 10.11. It then tests
>> if configure.sdkroot is nonempty, and if so, uses it. I've used this idiom
>> in a handful of other ports.
>
> Eek. We should figure out a nicer way to describe that. Perhaps we should
> add support for SDK version requirements.
Yes we should have a way to specify a requirement on a range of SDK versions. I
mentioned it in another thread. I proposed a syntax similar to the one used for
compiler blacklist versions.
>> This user is on 10.8, which doesn't have the 10.11 SDK. So with MacPorts
>> 2.4.2, configure.sdkroot is empty, the port tries to build without an SDK,
>> and fails. Fine; we know about that and it's on my to-do list to fix it. But
>> MacPorts 2.5 changes it so that configure.sdkroot is undefined, and the port
>> thus fails to be usable at all, preventing even "port info" and "portindex"
>> from working:
>>
>> Error: Unable to determine location of a macOS SDK.
>> Can't map the URL 'file://.' to a port description file ("can't read
>> "configure.sdkroot": Unable to determine location of a macOS SDK.").
>> Please verify that the directory and portfile syntax are correct.
>> To use the current port, you must be in a port's directory.
>
> For now, can you maybe do the shenanigans with configure.sdk_version in
> pre-configure?
Possibly, but it's crappier to have to do that.
>> One possible solution: I've been working on a project to make all SDKs
>> available on all macOS versions, via a set of new ports. (I'm sure we're not
>> allowed to distribute the SDKs, so these new ports work by requiring the
>> user to download a specific version of Xcode from Apple, and it extracts the
>> SDK from there.) My intention is that if a port requires an SDK that does
>> not exist in the installed version of Xcode, it will add a dependency on the
>> corresponding macOS SDK port and use that. If that behavior were in base,
>> then that should eliminate the situations (other than user error) where
>> configure.sdk_root would return an error.
>
> This starts getting complicated because SDKs are very tied to the toolchains.
> It's hard enough trying to get the OSS toolchains to work with all of the
> SDKs we support. I cringe at trying to get an older Xcode's toolchain to
> work with a newer SDK.
I'm not concerned about that at all. The ports will simply blacklist
unacceptable compiler versions, as they would for any other reason.
