[MacPorts] #50966: Qt5 PortGroup files; preparing for port:qt5-kde and the KF5 port family

[MacPorts]

#50966: Qt5 PortGroup files; preparing for port:qt5-kde and the KF5 port family
-------------------------+--------------------------------
 Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
     Type:  update       |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:  2.3.4
 Keywords:               |       Port:  qt5, qt5-kde
-------------------------+--------------------------------
 I'm submitting my proposed changes to the Qt5 PortGroup inn another
 attempt to gain some attention for and traction on the subject of the KF5
 port family which have a strong (*) dependency on a Qt5 version with
 dedicated patches. This family and the corresponding `port:qt5-kde` are
 currently in extended testing and ought to be committed in a hopefully
 not-too-far future.

 The changes are relatively straightforward and aim to maximise the extent
 to which users will be able to install either of the Qt5 ports as an
 alternative, much like this is currently possible with `-devel` ports.

 - A Qt5 KDE PortGroup (qt5-kde-1.0.tcl) is introduced that provides the
 configuration details for `port:qt5-kde`. It also defines and sets the
 variant `+qt5kde`.
 - The current qt5-1.0.tcl single-file PortGroup is renamed to
 qt5-mac-1.0.tcl (and can be renamed to anything else deemed more
 appropriate)
 - The Qt5 1.0 PortGroup (qt5-1.0.tcl) is replaced with a "header
 PortGroup", i.e. it includes one of the 2 PortGroup alternatives.

 The Qt5 KDE PortGroup is included if and only if
 1) a port includes it explicitly; `PortGroup qt5-kde 1.0` (making it
 incompatible with a set-up where `port:qt5` is installed and active).
 2) `port:qt5-kde` has been installed by the user. This is the only
 scenario in which a regular port will use qt5-kde "by default".
 3) No Qt5 port has been installed when the user installs a Qt5-dependent
 that indicates a preference to qt5-kde, i.e.:
 {{{
 set qt5.prefer_kde yes
 PortGroup qt5 1.0
 }}}

 In all other cases, the current Qt5 PortGroup and `port:qt5` are used.

 The `+qt5kde` variant ensures that binary builds of Qt5-dependent port can
 be distinguished as a function of what Qt5 port they are built against.
 Ports built against `port:qt5` appear to work fine against `port:qt5-kde`,
 but the reverse is less likely to be true, esp. for KF5 ports that were
 built against `port:qt5-kde`.
 It would be possible to declare the `qt5kde` variant in the "header"
 PortGroup, and use it instead of or in addition to `qt5.prefer_kde`. I
 have no objection against that but think that it may give a bit too much
 control to users which either doesn't make much sense (telling a port to
 use "the other Qt5 port", = the one not installed) or is redundant or even
 counter productive.

 The Qt5 "header" PortGroup also introduces a procedure to facilitate
 declaring dependencies on specific Qt5 components, e.g.

 {{{
     qt5.depends_component qtbase qtsvg qt3d
 }}}

 this expands to the appropriate subports dependencies (i.e. on
 `qt5-qtbase, qt5-qtsvg, qt5-qt3d` or `qt5-kde-qtbase, qt5-kde-qtsvg, qt5
 -kde-qt3d`). The procedure has initial support for an optional table of
 dependency patterns that can be declared in the specific PortGroup
 (cf. `qt5_component_lib` in qt5-kde-1.0.tcl ; there is an expansion issue
 with the use of variables in the elements of that table that I haven't
 been able to figure out yet).
 Note that `port:qt5-kde` only provides a true subport for QtWebEngine; the
 remaining component subports are stubs that depend on `port:qt5-kde`.

 *) The KF5 dependency on `port:qt5-kde` is strong but obligatory only in
 the sense that using a "stock" Qt5 breaks a lot of functionality and would
 require significant patching that just doesn't make sense for something
 like MacPorts of almost all KF5 ports.

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