[MacPorts] #53777: Qt5 PortGroup : wrong use of qt5.using_kde and +qt5kde

[MacPorts]

#53777: Qt5 PortGroup : wrong use of qt5.using_kde and +qt5kde
---------------------+-----------------
  Reporter:  RJVB    |      Owner:
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:  qt5     |
---------------------+-----------------

Comment (by RJVB):

 No, I've made it perfectly clear that the layout isn't identical. The
 binaries that have to be in the same location are (those loaded by dyld.so
 and not at runtime). Evidently the names of the headers are the same too.

 > so many hoops?

 Yeah, you have been introducing unnecessary complications in your
 PortGroup(s), and splitting port:qt5 up in port:qt5-qtbase etc. hasn't
 exactly made things easier either. I have been thinking A LOT about how to
 make this "almost perfect drop-in replacement" thing work transparently.
 It's not very difficult, but it *is* a bit delicate and not something to
 second-guess without understanding the entire context as well as I do. I
 don't have commit access, otherwise I would have made the modifications
 myself.

 We've already tackled the `qt5.depends_component` macro. The remaining
 magic to be put in the PortGroups is all thought out on my end and as far
 are you PGs are concerned it consists only of transferring control to mine
 when that's necessary. That transfer should be as early in the file as
 possible.
 7 months is long ago enough that I don't remember the exact details of my
 reasoning. Without diving into those details anew I'd say that there
 should be no need for you to declare the qt5kde variant or the
 corresponding variable and use it. Simply because the corresponding parts
 of your PortGroups ought never be executed when qt5-kde is (to be)
 installed. A simple check just after the transfer should be enough to
 catch any unforeseen situations.

 > trying to convince Portfiles that it is.

 That's indeed a possible point of confusion. There are 2 aspects
 1. binary compatibility
 2. build compatibility

 Point 1 takes place mostly in `port file qt5-kde` with support code in the
 PGs like `qt5.depends_component` and the +qt5kde variant. The function
 does most of the work (ensuring the correct depspecs are used), the
 variant is mostly there so that a `port:foo-qt5` built against
 `port:qt5-kde` is not identical to the same port built against
 `port:qt5-qtbase` according to the reproducible build rules. It records
 the fact that we're dealing with a build variant.

 Point 2 is completely handled in the PGs, and is based on
 `qt5.depends_component` and the fact that dedicated PGs are used. That
 latter part is hidden from dependent ports, evidently, they can continue
 to do `PortGroup qt5 1.0` as always.

 My initial idea had been to make `qt5-1.0.tcl` a simple entry point which
 includes either your PG or mine and contains some shared code like
 `qt5.depends_component`. That's undoubtedly why even my version of that
 function still checks `qt5.using_kde`. Putting the shared code in there is
 optional of course but even without this approach would still oblige you
 to change your habits (use a different PG name). Hence my current idea of
 providing you with a patch that triggers the transfer to `qt5-kde-1.0.tcl`
 when needed (idem for the qmake5 PG), code that you shouldn't need to
 touch once it has been put in place.

 What makes this more complicated is the fact that we use the same PG for
 building Qt and for building dependent ports. We have to ensure that users
 can still build port:qt5-qtbase when port:qt5-kde is installed and active,
 for instance. But I don't really see how to get around that without ending
 up with lots more PortGroup files.

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