[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):

 I just think of an alternative for the PortGroup problem. I'm not yet sure
 whether I really like it, but it does have a certain appeal about it.

 My idea has always been to have a shared qt5-1.0 PG which includes either
 qt5-kde-1.0.tcl or the as-yet-to-be-determined new name for the actual
 qt5-1.0.tcl as a function of the installed Qt version and/or the port's
 preference, followed by a common section containing for instance
 `qt5.depends_component`.

 The alternative would be to have only 2 PGs, leaving `qt5-1.0.tcl` to
 Marcus, and qt5-kde-1.0.tcl to Marko and me. Each PG would then pass
 control over to the other when required by doing (in qt5-kde-1.0.tcl)

 {{{
 if {[something]} {
     PortGroup qt5 1.0
     return
 }
 }}}

 This control transfer would have to take place near the top of the
 PortGroup, but can be preceded by any definitions that we would like to be
 available always.

 This would probably solve the preference indication issue implicitly. A
 preference for port:qt5-kde would be indicated by requesting the qt5-kde
 PG, insofar as that PortGroup might in fact include the other PortGroup if
 this preference cannot be respected. Generic Qt5 ports can continue to
 include the qt5 PG and still end up using qt5-kde if that port is
 installed.
 The appeal is that we will each have more leeway in the choice of the
 exact implementation like for instance `qt5.depends_component` which means
 it wouldn't have to implement "adaptive depspecs".

 The crucial condition here is of course that we must both agree to
 transfer control to the other PG when that is dictated by the installed
 Qt5 port or user preference indicated in some other way. I have no problem
 with that (it's what I'm aiming at already) but I would have preferred to
 shoulder that responsibility (through a shared PG) and not burden others
 with it because unhappy changes could cause considerable breakage in KF5
 functionality.

 We might do something similar for the qmake5 PG too.

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