[MacPorts] #53230: preparing port:qt5-kde step 2 : the qt5 PortGroup(s)

[MacPorts]

#53230: preparing port:qt5-kde step 2 : the qt5 PortGroup(s)
----------------------+-----------------
  Reporter:  RJVB     |      Owner:
      Type:  request  |     Status:  new
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:
Resolution:           |   Keywords:
      Port:  qt5-kde  |
----------------------+-----------------

Comment (by RJVB):

 As said, the main topic at hand is making port:qt5 and port:qt5-kde as
 much exchangeable as possible. As a bonus, we also get exchangeability of
 port:qt5, port:qt55, a potential future port:qt56, etc. (with the
 difference that a priori the choice among those ports depends on the OS
 version and not on user discretion).

 For this to work, a port depending on Qt5 that currently does

 {{{
 PortGroup qt5 1.0
 }}}

 must continue to do so, and must build and install regardless of which Qt5
 port is installed. The same applies to KF5 ports: I do not intend to
 support using them with port:qt5, but they should build (for the most part
 at least) and run (to some extent). So KF5 ports will express only a
 preference on port:qt5-kde, not a hard dependency (see below for what that
 means).

 The main difficulty here was the breaking up of port:qt5 into Qt5
 component subports. With port:qt5-kde I split off only the huge
 QtWebEngine and kept the rest bundled like port:qt4-mac is; port:qt5 was
 later converted to provide each component in subports. This has been
 solved by the introduction of a `qt5.depends_component` procedure that
 ports can use to declare dependencies on those subports, and which will
 translate into "adaptive depspecs".

 My initial solution was to have a common "header" PG that would contain
 the logic to decide which actual implementation PortGroup needs to be
 loaded, as well as some common code like `qt5.depends_component`. For that
 reason I kept that procedure relatively simple. The nice aspect as I see
 it is that this would allow both Marcus and me to maintain our PG files as
 we see fit, relying on the fact that "our" code would always be run when
 appropriate thanks to that header PG. And evidently port:qt5 would be the
 default so that in essence nothing would change for Marcus nor anyone not
 interested in KF5 (nothing except the name of the PG file containing the
 actual implementation).

 In short: port:qt5 and its (renamed) PG would be used, unless
 - port:qt5-kde was already installed
 - no Qt5 port was installed and we were installing a port indicating a
 *preference* on port:qt5-kde . Using port:qt5-kde meant that the
 qt5-kde-1.0.tcl PG would be loaded.

 Dependency preference is a novel thing, but nothing seems to forbid it in
 the guidelines (as long as it's done right and the idea of adaptive
 depspecs isn't itself in violation of some written rule). It's just an
 extension of principles already used by regular vs. -devel ports, and as
 discussed on the ML, could well be used also to formalise the user choice
 for LibreSSL or OpenSSL.

 This solution is still being maintained in my personal macstrop repo:
 https://github.com/RJVB/macstrop/tree/master/_resources/port1.0/group

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