"concurrent" qt4-mac: request feedback & testing for current port phase in Portfile?

Ryan Schmidt ryandesign at macports.org
Thu Dec 11 05:53:09 PST 2014


On Dec 10, 2014, at 1:27 PM, René J.V. Bertin wrote:

> On Wednesday December 10 2014 12:20:58 Ryan Schmidt wrote:
> 
>>> The thing is, if ever we want to allow Qt4 and Qt5 to be present at the same time, the installation location will *have* to change, and dependent ports will have to comply with that.
>> 
>> Yes, but not by using variants. MacPorts doesn't have the capability to declare a dependency on a variant (ticket #126) and I'm still not convinced that that should ever change.
> 
> There is no need to depend on the changes I'm making, whether as a variant or something else (but what?). It would help if a Portfile (or PortGroup file) could check what variant of a port is installed, but even without that my variant is detected reliably. Qt provides pkgconfig files, qmake, and other Qt ports provide cmake files that all allow to find things where they're installed.

What happens if you install qt4-mac with this variant, then install some ports that use qt4-mac, then install qt4-mac without this variant? Answer: the ports that depend on qt4-mac are now broken.

What happens with regard to the buildbot if this variant is used? Answer: the buildbot does not test non-default variants.

What happens with regard to pre-built binaries if this variant is used? Answer: pre-built binaries would not be available since they would have to have been produced by the buildbot.

There are but a few of the problems with attempting to use a variant as something that can be depended upon, which is why I don't like doing it.


> There's also the possibility to provide a qt4-mac-config script (and qt5-mac-config) that returns the various locations, should there be a need.
> 
> Finally, I wouldn't mind at all if the variant I'm working on becomes the de-facto standard - I've repeated often enough that we should never have been in this situation of mutual exclusivity in the first place, but sadly the 2 Qt port maintainers seem to be absent or of a completely different opinion. That's why I'm providing a second variant that puts up symlinks that allow existing Qt4 clients to function, as far as that's possible. A priori (not 100% tested yet) those symlinks will become redundant when clients are rebuilt.

The correct solution is to modify qt4-mac and qt5-mac so that they install files to non-conflicting locations (always, not selectable via a variant), and in the same commit, modify the qt4-1.0 and qt5-1.0 portgroups as needed and increase the revision of every port that uses those portgroups or otherwise depends on qt4-mac or qt5-mac so that they are rebuilt against the new locations. Each port should ideally have been tested and found to work with this new configuration before committing. This understandably takes some time and effort which is why it hasn't been done.


> BTW: one could also tell users who need qt4-mac and qt5-mac that they just have to install 2 MacPort trees ... would you prefer that? :P

No, I would not.




More information about the macports-users mailing list