[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:17 MarcusCalhoun-Lopez]:
 > Replying to [comment:14 RJVB]:

 > > - port:qt5 currently installs the pkg-config files to
 `${qt_libs_dir}/pkgconfig`. Is that to be changed?
 > Links to the .pc files are currently put into `${prefix}/lib/pkgconfig`
 (see [https://trac.macports.org/changeset/142505/trunk/dports here]).

 OK. I put those files into lib/pkgconfig directly.

 > > 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
 qt5-1.0.tcl]

 > I believe there would be **strong** objections from the other developers
 to having dependencies influenced by {{{[file exists
 ${prefix}/include/qt5/QtCore/QtCore]}}}.[[BR]]
 > At the very least, it would run contrary to ReproducibleBuilds.[[BR]]

 No, because of the variant I include. Build with a different Qt5 port
 installed and your port will be labelled with a variant, which makes it
 officially different from what the build bots give.
 KF5 ports set `qt5.prefer_kde 1` before including the PortGroup. On the
 build bots and on virgin systems that means that `port:qt5-kde` will be
 installed, and the resulting build will have `+qt5kde` set. This will be
 exactly the same build on the bots, on a user system when installed from
 scratch, and on a user system where `port:qt5-kde` was already installed.

 > `port deps libQGLViewer` would give different answers from one day to
 the next depending on which Qt is installed.

 All this is not so different from what you get with regular vs. -devel
 ports. Yes, `port deps foo-qt5` will give a different answer depending on
 what Qt5 port is installed, but it's an answer that reflects the local
 context.

 I don't see a way around this if we want minimal disruption of ports that
 use Qt5. Once a choice for Qt5 ports has been made, all Qt5 dependencies
 should be taken from that same choice: you shouldn't end up mixing
 qt5-qtbase and qt55-qtdeclarative for instance, nor qt5-kde with
 qt5-qttools to name just 2 examples.

 We could probably make a more complex use variants and for the KF5 ports
 that could logic could be hidden (made automatic) in the KF5 PortGroup.
 But would we want to oblige users to specify a variant to "force"
 libQGLViewer or any other "pure Qt5" port to install when port:qt5-kde is
 installed? Or a variant to make it use port:qt55 on 10.7 if indeed that's
 the only way to get a proper Qt5 experience on that OS version?

 > I may have misunderstood how qt5-kde stubports are used, but I humbly
 suggest this is resolved after consensus is reached on general strategy.

 Possibly, but in this case the fix is easy; the early return I mentioned
 above (i.e. don't add any dependencies for a component provided by qt5-kde
 it it's known we're using qt5-kde). That doesn't really depend on the kind
 of consensus we can reach.

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