[MacPorts] #48967: submission: port:qt5-kde

[MacPorts]

#48967: submission: port:qt5-kde
--------------------------+----------------------
  Reporter:  rjvbertin@…  |      Owner:  mk@…
      Type:  submission   |     Status:  assigned
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:  2.3.3
Resolution:               |   Keywords:
      Port:  qt5-kde      |
--------------------------+----------------------

Comment (by rjvbertin@…):

 't wasn't much of an update, but well, good to know it went smooth anyway
 :)

 Committing this would be great of course. We could do with some more
 testing of just how compatible this port is with binary packages built
 against the current mainstream Qt5 ports (I'll refer to them as
 port:qt5-mac in this comment). As I told you in an email I have been able
 to install the binary package for Qt5 Creator against my qt5-kde install.
 That should be a good indication (I presume Qt Creator uses=tests many if
 not most of Qt's features) but it is still only a single sample, maybe not
 even an unbiased one.
 It'd be nice if someone could also test what happens when you deactivate
 port:qt5-mac and activate/install port:qt5-kde to see if I install the
 right mix of stub directories and symlinks that provide the runtime/binary
 compatibility.

 There is also the question of the reproducible build principle and the
 +qt5kde variant. That variant was introduced as a protection against
 installing binary packages built for port:qt5-mac while still allowing
 binary packages for qt5-kde specific ports (the variant is set
 default_variant when it is detected that the user has port:qt5-kde
 installed). It seems that protection is no longer necessary, but there is
 still the reproducible build principle. Building, say, port:qt5-creator
 from source when you have port:qt5-kde installed will give a result that
 is not entirely identical to the result of a build against port:qt5-mac .
 Of course that is the same kind of difference you can get when you build
 against the alternative of any other port that provides "drop-in
 alternatives", say ffmpeg-devel instead of ffmpeg.

 And then finally there is the question of the PortGroup. I've done my best
 to ensure that the logic that gets invoked when a Portfile does `PortGroup
 qt5 1.0` does the right thing. By default, it will still get the
 mainstream Qt5 PortGroup, of course; the qt5-kde PortGroup
 (qt5-kde-1.0.tcl) will only be used when either 1) port:qt5-kde is
 detected or 2) port:qt5-kde is preferred by the port in question and no
 Qt5 port is yet installed. The only "issue" at this level: I'd want this
 to be transparent (= ports shouldn't have to change the `PortGroup qt5
 1.0` statement). I also think that it is best if each (group of) Qt5 port
 maintainer(s) has/have his/their own "simple" PortGroup file to maintain.
 That means I renamed the current Qt PortGroup to `qt5-mac-1.0.tcl` and
 replaced it with a "header" that takes care of including the required
 PortGroup file using the aforementioned logic (and only that logic). Other
 names are of course possible for the "standard" PortGroup, and other
 solutions can be discussed as well.
 I'll be updating the attached PortGroup files.

-- 
Ticket URL: <https://trac.macports.org/ticket/48967#comment:16>
MacPorts <https://www.macports.org/>
Ports system for OS X