gpsbabel suddenly based on qt5-mac thus leaving qt4-mac-based port qlandkartegt in limbo

[René J.V. Bertin]

On Wednesday June 10 2015 13:31:11 Ryan Schmidt wrote:

> 
> I don't think Marko is saying that. He's saying he wants to be able to upgrade his ports and have them still work. That's reasonable.

And between the lines I read that he'd like them to continue to use Qt4 because that's what he has installed, no automagic switching to Qt5. I also don't think it's his style to impose everyone else to continue to provide Qt4 dependent ports by default ...
A lot of "upstreams" will already use Qt5 if it's available, and it will become increasingly less trivial to override that. There are currently very little Qt5 ports in the repository, but that's by no means representative of the real world outside MacPOrts.

> You are correct, we don't want ports building themselves differently based
> on what other ports are installed.

I think one could and probably should allow for global settings (like port select, or using qtchooser in case of a user's Qt "version preference") that control building behaviour, as a compromise. I'm aware that may not be as trivial as it sounds.
(Ultimately, ports *do* build differently when a user doesn't have the latest version of all dependencies installed, be it by choice or because the host OS doesn't allow it.)

> I don't think we should be recommending maintaining a local ports repository
> as a solution for users.

This is the devel ML (and Marko not your average user), right?

> Seems the first step in providing any smooth migration from qt4 to qt5 (for those ports that support that, while still allowing those that don't to remain on qt4) is to make qt4 and qt5 simultaneously installable:

That's what I have been saying maybe even before Mojca opened the ticket, and I have spent about 6 months or so making this possible. I've even implemented a subport that allows to update qt4-mac to a co-installable version without requiring an immediate rebuild of all the dependents, and have tested about all aspects of that. As a result, port maintainers can upgrade Qt and then rebuild their ports one by one to adapt them to the new system - as far as that's even necessary; well-written ports (= using variables from the portgroup instead of hard-coding paths) will just rebuild and be happy.

> Seems some action has happened on that ticket lately, though I see you're already aware of that ticket.

I have the impression you're not even kidding me... Yes, I've been aware of that ticket and the whole issue for at least 10 months.

I was *not* aware that the even older ticket requesting a Qt5 port actually had a proposition to call that port simply qt5 (with michaelld's support), a conclusion I only came to this week. 

I'll say it once more: I'd been thinking last week that it was high time I rekindle the qt4/qt5 situation. Qt 5.4.2 has just been released, and 5.5.0 is in RC so soon I'll have to move qt5-devel to that version. It is unlikely to build completely on 10.7, so what I feared is going to be reality: 10.6 will only support Qt 5.3.2, 10.7 only up to 5.4.x incl., 10.8 probably up to 5.5.x incl, etc. My current Qt5 port (the one I linked to) provides 5.3.2 on 10.6 and 5.4.2 on all other OS X versions; the question is going to be whether this principle is going to be developed further, and how. The alternative would be to provide qt53, qt54 etc. ports on all platforms, which will be opening other cans of worms.
I personally don't see a good reason to do this, but there might be demand for it. And if it's a supported use case to use MacPorts on, say, OS X 10 to build software that targets say OS X 10.6 (maybe even has to be distributed in binary form), then that kind of demand will have to be studied at least.

I think that if older Qt5 versions are to be provided, I'd chose to install those in a single prefix (${prefix}/libexec/qt5x) while maintaining the more distributed install schema for the current Qt version that builds on the most if not all officially supported OS X versions.

R