[MacPorts] #51619: qt5.depends_component procedure

[MacPorts]

#51619: qt5.depends_component procedure
---------------------------+----------------------
  Reporter:  RJVB          |      Owner:  mkae
      Type:  enhancement   |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:
      Port:  qt5, qt5-kde  |
---------------------------+----------------------

Comment (by RJVB):

 A few more things, inspired by upgrading to 5.7.1 :

 - qtenginio was deprecated in 5.6 and is removed from 5.7 . I doubt it was
 ever used but I am keeping its stubport (which will now raise an
 obsoletion error)

 - A few new components were added in 5.7: QtCharts QtDatavis3D QtGamepad
 QtPurchasing QtScxml (no idea yet what the latter does). They're all small
 when built and only depend on other components in `qt5-kde`, so I am
 including it in the main port, with stubs.

 - QtScript is deprecated but still available.

 KF5 evolves rather quickly and is in a sense a development platform and
 showcase for new, "Kool" things. I think the only reason why it doesn't
 yet require Qt 5.7 across the board is because of Qt 5.6's LTS status. I
 know that many KDE devs are already using preview versions of Qt 5.8, and
 at least 1 port already requires 5.7. (Not to mention QtWebEngine which
 works better in 5.7+ than it does in 5.6 .)
 All this is in line with KDE's history of being a source of APIs that end
 up being integrated into Qt.
 This observation is actually an additional argument NOT to integrate the
 KDE patches with the main `port:qt5` but to keep a dedicated Qt5 port so
 it become easier for KF5 ports to depend on `port:qt5-kde`, and for me to
 keep up with the "recommended" minimal Qt version.

 It is also an argument for something I already hinted at before: the 2nd
 part of his `qt5.depends_component` proposal

 {{{
         switch -exact ${comp} {
                     qtquickcontrols2 {
                         depends_lib-append
 path:lib/pkgconfig/Qt5QuickControls2.pc:${qt_port_name}
                     }
                     qtbase {
                         depends_lib-append
 path:lib/pkgconfig/Qt5Core.pc:${qt_port_name}
                     }
                     # ...
         }
 }}}

 should go into the port-specific PortGroup files, OR do a lookup in tables
 provided by those PortGroups.

 Yes, I realise this degrades the ABI compatibility argument. But as
 explained above:
 1 Qt guarantees that you can upgrade Qt from 5.x to 5.y without having to
 rebuild (except if certain private APIs are used)
 2 the autodefault +qt5kde variant prevents getting mismatched binary
 builds from the bots.

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