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
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
