portindex fails due to portfile parsing

classic Classic list List threaded Threaded
11 messages Options
db
Reply | Threaded
Open this post in threaded view
|

portindex fails due to portfile parsing

db
Today I tried syncing and it failed, see log below. It succeeded when I moved the portfile away. Base is from source.


$ sudo port -v sync
--->  Updating the ports tree
Synchronizing local ports tree from file:///opt/local/myports
Creating port index in /opt/local/myports

Total number of ports parsed: 0
Ports successfully parsed: 0
Ports failed: 0
Up-to-date ports skipped: 80

Synchronizing local ports tree from file:///opt/local/var/macports/sources/github.com/macports/macports-ports/
Current branch master is up to date.
Creating port index in /opt/local/var/macports/sources/github.com/macports/macports-ports
Error: Unable to determine location of a macOS SDK.
Failed to parse file editors/textmate2/Portfile: can't read "configure.sdkroot": Unable to determine location of a macOS SDK.

Total number of ports parsed: 1
Ports successfully parsed: 0
Ports failed: 1
Up-to-date ports skipped: 19396

Command failed: /opt/local/bin/portindex /opt/local/var/macports/sources/github.com/macports/macports-ports
Exit code: 1
Error: updating PortIndex for file:///opt/local/var/macports/sources/github.com/macports/macports-ports/ failed
Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

Ryan Schmidt-24

On Mar 19, 2018, at 10:00, db wrote:

> Today I tried syncing and it failed, see log below. It succeeded when I moved the portfile away. Base is from source.
>
>
> $ sudo port -v sync
> --->  Updating the ports tree
> Synchronizing local ports tree from file:///opt/local/myports
> Creating port index in /opt/local/myports
>
> Total number of ports parsed: 0
> Ports successfully parsed: 0
> Ports failed: 0
> Up-to-date ports skipped: 80
>
> Synchronizing local ports tree from file:///opt/local/var/macports/sources/github.com/macports/macports-ports/
> Current branch master is up to date.
> Creating port index in /opt/local/var/macports/sources/github.com/macports/macports-ports
> Error: Unable to determine location of a macOS SDK.
> Failed to parse file editors/textmate2/Portfile: can't read "configure.sdkroot": Unable to determine location of a macOS SDK.
>
> Total number of ports parsed: 1
> Ports successfully parsed: 0
> Ports failed: 1
> Up-to-date ports skipped: 19396
>
> Command failed: /opt/local/bin/portindex /opt/local/var/macports/sources/github.com/macports/macports-ports
> Exit code: 1
> Error: updating PortIndex for file:///opt/local/var/macports/sources/github.com/macports/macports-ports/ failed

Probably an unintended consequence of one of my changes last month.
What version of macOS and what version of Xcode are you using?

db
Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

db
On 19 Mar 2018, at 16:56, Ryan Schmidt <[hidden email]> wrote:
> Probably an unintended consequence of one of my changes last month.
> What version of macOS and what version of Xcode are you using?

OS X 10.8.5, Xcode 5.1.1.
Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

Ryan Schmidt-24

On Mar 19, 2018, at 11:21, db wrote:

> On 19 Mar 2018, at 16:56, Ryan Schmidt wrote:
>> Probably an unintended consequence of one of my changes last month.
>> What version of macOS and what version of Xcode are you using?
>
> OS X 10.8.5, Xcode 5.1.1.

Hmm. I can't reproduce the problem on OS X 10.8.5 with Xcode 5.1.1 or on any other OS version.

The "Unable to determine location of a macOS SDK" message shouldn't happen, unless you don't have Xcode installed and selected. Is Xcode selected properly? What's the output of:

xcode-select -p

db
Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

db
On 19 Mar 2018, at 17:39, Ryan Schmidt <[hidden email]> wrote:
> xcode-select -p

$ xcode-select --print-path
/Applications/Xcode.app/Contents/Developer

Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

Ryan Schmidt-24
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.

db
Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

db
On 20 Mar 2018, at 00:34, Ryan Schmidt <[hidden email]> wrote:
> Error: Unable to determine location of a macOS SDK.

Could it instead be a warning?

Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

Jeremy Huddleston Sequoia
In reply to this post by Ryan Schmidt-24


> On Mar 19, 2018, at 4:34 PM, Ryan Schmidt <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

Ryan Schmidt-24

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.


Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

Ryan Schmidt-24
In reply to this post by db

On Mar 20, 2018, at 08:29, db wrote:

> On 20 Mar 2018, at 00:34, Ryan Schmidt wrote:
>> Error: Unable to determine location of a macOS SDK.
>
> Could it instead be a warning?

If a port specifies that it requires an SDK, and the SDK does not exist, it is proper for MacPorts to exit with an error at install time. What we need to figure out is how best to prevent MacPorts from exiting with an error at non-install times.
Reply | Threaded
Open this post in threaded view
|

Re: portindex fails due to portfile parsing

Ken Cunningham
In reply to this post by Jeremy Huddleston Sequoia

On 2018-03-20, at 4:22 PM, Jeremy Huddleston Sequoia wrote:
>
>  I cringe at trying to get an older Xcode's toolchain to work with a newer SDK.
>
>

Perhaps I shouldn't even say it, but here's what I do:

symlink into the Xcode SDK the following toolchain bits from current MacPorts installs:

clang
clang++
ld64
strings
nm

set the compiler to clang 1.0 and the standard lib to libc++.

And a tremendous amount of things then build on 10.6.8.

Now I will duck before someone punches me.

Ken