Contributing to MacPorts (specifically to introduce am improved concurrent qt5-mac)

[René J.V. Bertin]

On Thursday June 11 2015 10:57:15 Bradley Giesbrecht wrote:

This seems relevant for the ML, so replying through there.

>> It seems we'd actually need a buildslave set-up/clone for what you're proposing.
>
>It is a build slave for kde ci already. If it takes a week to chew through a build I can live with that if it lays the foundation for an acceptable patch.

I suppose that the KDE CI requires no intervention as long as no errors are encountered, and I presume the same is true for the MacPorts buildbots. It is not true for the macports VM, to my knowledge. At least until now I have simply been using it as a remote account on a machine where I build individual ports (and their dependencies).


>Are you saying you have a minimal patch that qt{4,5}-mac that does not add subports or variants? I have not seen it. 

No, you cannot, because I did those tests before getting access to your VM. And the qt4-mac port has always had an additional subport that is meant to ease transition by "unbreaking" every existing dependent after upgrading to a concurrent Qt4 install.

I'd have to add that I personally have zero interest in getting port versions accepted that do not include the subports I judged useful.
What I could do tomorrow is create versions without the additional subports (or variants) (but *with* the Qt 5.3.2 support for 10.6 for the qt5 port), and generate diffs of those versions against the current mainstream ports, as well as against the full-fledged versions.
But I'd really hate to see my suspicions confirmed that I'll have to keep maintaining my own branches if I want to stick to the subports.

>What I want to do is deconflict qt4/5 and revbump every qt4/5 dependent port on macports.pixilla.com and then do a massive build of and produce a report so the maintainers of qt4/5 dependent ports can know what to expect and to get constructive feedback form the community.

So basically you'd want to build every Qt4 port first in its current form against the existing port, and then do a revbump somehow, and rebuild everything? I wonder if Michael has ever done something that wild when updating Qt (except by letting the buildbots handle it), and I'm not even sure I agree it's up to us to do the work for all maintainers of all dependents. They too stand something to gain from a concurrent Qt4/Qt5 installability, presuming they'd want to update and follow upstream when those move to Qt5.
I'll say it once more: properly written dependent ports use variables from the PortGroup if they have any business with where Qt is installed at all, and as long as they do they build. I've rebuilt a large and representative enough sample of Qt4 dependents to be confident that well-behaved ports will simply build.

BR,
R.