Qt5 PortGroup files; preparing for port:qt5-kde and the KF5 port family

[RJVB (René Bertin)]

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.

[RJVB (René Bertin)]

I forgot: my qt5-kde port uses a slightly different qmake5 PortGroup too; in this case it's easy enough to provide both flavours in a single file.

Note also the conditional use of ${configure.cxx_stdlib} (IOW, don't use it if empty).

[RJVB (René Bertin)]

Bump. Slightly updated files now that port:qt5 has finally attained Qt 5.6.0 too .

[mkae (Marko Käning)]

René, what is the current status of this ticket considering Marcus updated the official qt5 port lately?

[RJVB (René Bertin)]

The qt5.depends_component proposal has been addressed, the other points remain open. Qt5-kde will still require its own portgroups, and a mechanism for ports to indicate that they prefer this port.

Given how things have worked out I now lean towards a solution where we have only 2 Qt5 PGs but also 2 qmake5 PGs, each of which transfers control to the other when that should be done. IOW, qt5-1.0 and qmake5-1.0 transfer control to qt5-kde-1.0 or qmake5-kde-1.0 if it turns out that port:qt5-kde is installed, and vice-versa (when port:qt5 is installed). This implementation means we're really independent in the internal implementation details, and only need to ensure that the control transfer happens reliably and at an appropriate point in the file. It would also mean that ports can indicate their preference simply by including the qt5-kde PG directly and will have to take additional action if they need to depend on qt5-kde only for some reason. You probably saw the sample implementation I posted elsewhere (qmake5-kde-1.0.tcl and the 4 lines (7, with the comments) added to qmake5-1.0.tcl). It's working nicely.

You know I have tried to discuss the approach I've followed with the preference mechanism (after Marcus mentioned he thought it was in violation of certain principles), and as usual didn't get very far:

• Clemens officially doesn't care because the explanation is too long (that's my interpretation of his reaction but he hasn't disagreed with it ;))
• Larry hasn't disagreed with anything, yet
• Mojca seems support it, or at least an approach that is so similar I haven't seen any differences with what I do.

[mkae (Marko Käning)]

It seems like keeping things as separate as possible is the way to proceed then. This doesn't close the door to both ports adopting bits band pieces from one another - hopefully leading to a merger of the two at some time in the future.

[RJVB (René Bertin)]

Well, I am more or less obliged to "adopt" bits and pieces from Marcus's port and PG, in order to keep things compatible, and from time to time I also borrow one of his patches. He's welcome to do the same of course.

But from there to a merged port ... have you seen how complex the files are?

The only sane and safe way I see to merge 2 such complex ports with such a different internal organisation is one that just hides the fact there are actually 2 ports, i.e. with a Portfile that does something like

if {[variant_exists kde] && [variant_isset kde]} {
   source Portfile.qt5kde
} else {
   source Portfile.qt5
}

but that will lead to warnings every time the port has to be run from the registry because the "subPortfiles" won't be copied into the registry.

I'm also not so sure anymore that I see the advantage. Sure, if there were only a single other Qt5 port we'd get only a single Qt5 port by merging qt5-kde. But now there's also Qt55, and if port:qt5-kde were some kind of exotic variant of port:qt5 you'd expect a port:qt55+kde too. And that's not something I'm looking forward to maintain because there's already too much in KF5 that requires Qt 5.6. In the future a similar situation would almost certainly arise with Qt 5.6 .

There would also be the practical issue of activating or deactivating the +kde variant. Normally one would expect to be able to do

sudo port activate qt5

and then select the +kde variant or another variant. That just won't work given how port:qt5 is a meta-port for port:qt5-qtbase etc. and port:qt5-kde-qtbase etc. are stubports provided by a mostly monolithic port:qt5-kde. Running port activate qt5-qtbase and selecting the +kde variant would have almost the same effect as running port deactivate qt5-qtbase.

The only way around that would be to overhaul port:qt5-kde so that it too builds and installs all Qt components as subports, and I'm *really* not inspired to do that. Not beyond the occasional new component that represents a significant increase in build time and size of the main port and that by definition isn't required by any existing port.

[mkae (Marko Käning)]

So, how should we proceed for now?

[RJVB (René Bertin)]

I guess we'll wait a bit more, also because Qt 5.8.0 is bound to be release "anytime now".

I don't know what Marcus's plans are with port:qt5, but it seems that 5.8 will still support OS X 10.9 which was already the oldest OS versions supported officially by Qt 5.6 if I understand correctly. IOW updating shouldn't cause any significant problem; my own tests with the more common Qt components support that hypothesis. Of course there's always the possibility to introduce a port:qt56 if/when necessary.

From a KF5 viewpoint it would already be problematic to support 10.8 and earlier (possibly unless converted to libc++ but I cannot test such set-ups myself). That means that I'd just as well introduce port:qt5-kde at version 5.8.0 because that will be justified soon enough by KF5 dependencies (I already have 1 port that requires components that don't exist in Qt 5.6)

Evidently a port:qt5-kde@5.8.0 will undo much of the argument of binary compatibility with port:qt5 as long as that port remains on 5.6.2 ; in any case it will make it formally impossible to go back to port:qt5 once dependent ports have been built against the newer Qt5 version.

[mkae (Marko Käning)]

Okay, then go for 5.8. KF5 on MacPorts will be bleeding edge then. :-)

[mascguy (Christopher Nielsen)]

Add keyword portgroup, to pg-related tickets