portindex fails due to portfile parsing

[Jeremy Huddleston Sequoia]

> On Mar 19, 2018, at 4:34 PM, Ryan Schmidt <ryandesign at macports.org> 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.

> 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?

> 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.