[MacPorts] #50966: Qt5 PortGroup files; preparing for port:qt5-kde and the KF5 port family

[MacPorts]

#50966: Qt5 PortGroup files; preparing for port:qt5-kde and the KF5 port family
---------------------------+----------------------
  Reporter:  RJVB          |      Owner:  mkae
      Type:  update        |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:
      Port:  qt5, qt5-kde  |
---------------------------+----------------------

Comment (by RJVB):

 Well, I am more or less obliged to "adopt" bits and pieces from Marcus's
 port and PG, in order to keep things compatible, and from time to time I
 also borrow one of his patches. He's welcome to do the same of course.

 But from there to a merged port ... have you seen how complex the files
 are?

 The only sane and safe way I see to merge 2 such complex ports with such a
 different internal organisation is one that just hides the fact there are
 actually 2 ports, i.e. with a `Portfile` that does something like

 {{{
 if {[variant_exists kde] && [variant_isset kde]} {
    source Portfile.qt5kde
 } else {
    source Portfile.qt5
 }
 }}}

 but that will lead to warnings every time the port has to be run from the
 registry because the "subPortfiles" won't be copied into the registry.

 I'm also not so sure anymore that I see the advantage. Sure, if there were
 only a single other Qt5 port we'd get only a single Qt5 port by merging
 qt5-kde. But now there's also Qt55, and if port:qt5-kde were some kind of
 exotic variant of port:qt5 you'd expect a port:qt55+kde too. And that's
 not something I'm looking forward to maintain because there's already too
 much in KF5 that requires Qt 5.6. In the future a similar situation would
 almost certainly arise with Qt 5.6 .

 There would also be the practical issue of activating or deactivating the
 +kde variant. Normally one would expect to be able to do

 {{{
 sudo port activate qt5
 }}}

 and then select the +kde variant or another variant. That just won't work
 given how `port:qt5` is a meta-port for `port:qt5-qtbase` etc. and
 `port:qt5-kde-qtbase` etc. are stubports provided by a mostly monolithic
 `port:qt5-kde`. Running `port activate qt5-qtbase` and selecting the +kde
 variant would have almost the same effect as running `port deactivate
 qt5-qtbase`.

 The only way around that would be to overhaul port:qt5-kde so that it too
 builds and installs all Qt components as subports, and I'm *really* not
 inspired to do that. Not beyond the occasional new component that
 represents a significant increase in build time and size of the main port
 and that by definition isn't required by any existing port.

--
Ticket URL: <https://trac.macports.org/ticket/50966#comment:8>
MacPorts <https://www.macports.org/>
Ports system for macOS