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