On Jun 11, 2015, at 11:33 AM, René J.V. Bertin <[email protected]> wrote:
> 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.
Subports are simply ports that share Portfile info with other subports in the
same Portfile. You already have a private repo with modified Portfiles, what is
the problem with making your subports separate ports or keeping your private
repo?
My interest is in making qt4-mac and qt5-mac co-installable so developers can
work on qt5 projects without being forced to deactivate qt4.
>> 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.
I would like the supporting data from a test build. It will help answer
questions about the effect of the patch on other ports.
Regards,
Bradley Giesbrecht (pixilla)
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
