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

 Replying to [comment:12 MarcusCalhoun-Lopez]:
 > Attached is a proposal for {{{qt5-1.0.tcl}}}.

 That has become a huge function!

 A couple of points, I hope I'm concise enough:

 - port:qt5 currently installs the pkg-config files to
 `${qt_libs_dir}/pkgconfig`. Is that to be changed?

 - I don't really like the "-append" suffix, if not only because it
 suggests there are also "-prepend", "-replace" etc. modifiers.

 - qt5.using_kde isn't always defined, I don't know if `[tbool
 qt5.using_kde]` catches all possible situations(?) Evidently the variable
 could be defined by the shared PortGroup.
 I am VERY much in favour of maintaining the PortGroup approach implemented
 in
 https://github.com/RJVB/macstrop/blob/master/_resources/port1.0/group/qt5-1.0.tcl
 which allows us to keep separated the things that are best kept separated,
 like install locations and possibly variants. In that approach,
 `qt5-1.0.tcl` only contains the logic that decides which Qt5 port is (or
 is to be) installed and thus which dedicated PortGroup to load, as well as
 common functions like `qt5.depends_component`.
 This file could be called qt5-1.1.tcl as far as I'm concerned, but in that
 case we will have to do a forced upgrade of all PortGroup expressions in
 all dependent ports.
 Either way, with dedicated portgroups containing the port-specific logic
 the big switch in Marcus's proposal could be replaced with a lookup in a
 table that's defined in the dedicated portgroup. My own proposal already
 carries a prototype implementation of that. The advantage is that it keeps
 the shared PortGroup as lean as possible, AND let's each of us handle the
 depspecs details as best fits the port's main purpose.

 - My own function above uses the `is_qt5kde` local variable to avoid
 adding dependencies on stub ports.
 The qt5-kde stub ports are mostly there to be able to satisfy dependency
 requirements when someone moves from port:qt5 to port:qt5-kde . A user who
 installs port:qt5-kde from the start shouldn't be obliged to need them.
 The attached new proposal has a different effect: from what I can see it
 will add another (and different!) depspec on `qt5-kde` for each required
 component which is provided by `port:qt5kde`. That isn't very elegant and
 I don't know how "base" will handle the different path-style dependencies
 on a single port.
 A priori I think that this can be avoided by returning early from the
 default case (line 305 in the attachment); the qt5-kde PortGroup already
 adds a dependency.

 > qt5X-component depends on qt5X-qtbase (not a path dependency)

 I suppose that's something that is handled in `port:qt5` and `port:qt55`?
 The qt5-kde stubports evidently have a dependency on the `port:qt5-kde`.

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