portindex fails due to portfile parsing

Ryan Schmidt ryandesign at macports.org
Mon Mar 19 23:34:55 UTC 2018


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?

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.

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.

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.



More information about the macports-users mailing list