#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