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

 The current implementation of esp. `qt5.depends_component` makes this
 approach using 3 PGs (a header and 2 implementation files) a bit less
 logical though we can still use a header that only transfers control to
 the appropriate implementation PG as a function of *some* criterium.

 ''That criterium would preferably simply be which port is installed, using
 simple `file exists` checks rather than registry calls. I put some stress
 on simplicity because these are operations that are potentially going to
 be executed many times in the dependency graph calculations; many KF5
 ports have dependencies on many KF5 frameworks that each have multiple
 inter-dependencies. Even on my 2.7Ghz i7 I notice the cost of that.''

 The alternative I see uses only 2 PortGroups, but that means each
 PortGroup has to include some logic that makes it transfer control to the
 other PortGroup. And that means that the port:qt5-kde maintainers will
 need to have a say over a tiny section (and only that section!) in the
 port:qt5 PortGroup, and vice-versa.

 If that's something we can agree on (bindingly, much as I hate the word),
 then we can have the following implementation, equivalent to what I
 proposed above:
 - qt5-1.0.tcl transfers control to qt5-kde-1.0.tcl if
 1. port:qt5-kde is installed, or
 1. no Qt5 is installed and the *variable* `qt5.prefer_kde` exists
 - qt5-kde-1.0.tcl transfers control to qt5-1.0.tcl if
 1. port:qt5 is installed, or
 1. no Qt5 is installed and the variable `qt5.prefer_default` exists
 (something that should never happen, but who knows).

 Error conditions are to be detected and handled in the respective PG
 files, *after* the check.

 The preference variables should be regular Tcl variables so that ports can
 use the simple Tcl `set` command; there is no justification for using
 options variables here.
 This approach would however make at least the qt5.prefer_kde variable
 redundant: a simple

 {{{
 PortGroup qt5-kde 1.0
 }}}

 would already express that preference, and would still be equivalent to
 `PortGroup qt5 1.0` if port:qt5 is already installed.

 This approach does have a certain appeal: it saves 1 file, and also seems
 to give me a bit more certitude that my KF5 ports will use the qt5-kde
 PortGroup unless the user installed port:qt5 (a choice I decided to
 respect anyway).

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