port:qt5 and (proposed) port:qt5-kde cohabitation

[René J.V. Bertin]

Hi,

While working on the update to Qt 5.6.0 I realised I should try to rekindle the probably controversial issue of providing a dedicated Qt5 port that will be optional for but preferred by the KF5 ports currently under testing.

I've tried to be as succinct as possible... I hope this is all clear enough and not too long; it'd be nice to get some feedback this time.

The main specific adaptation of qt5-kde is a patch to QStandardPaths that allows that class to return XDG-compliant locations for various settings files and shared resources like icons, DBus scripts, etc. That's more or less an unavoidable modification if we want KF5 applications to build, install and behave (in MacPorts) like their KDE4 counterparts did - and interact with those (and other, e.g. GTk/Gnome apps from the Freedesktop universe). Another important difference is that the install layout follows the layout used by the original, exclusive port:qt4-mac, because it is much closer to an XDG-compliant  layout.

Having 2 different ports each providing the same middleware is of course not an ideal solution. If things had gone as I'd liked there would now be a single port with a +KDE variant. Alas, that apparently wasn't to be.

Instead, I've set up my qt5-kde port to be as compatible as possible with the main/official port:qt5. In a nutshell: port:qt5-kde installs everything the qt5 *meta*port does, except the QtWebEngine component which for now is provided as a subport because it is so costly to build (about as much as the rest). Qt5-kde also installs symlinks that provide access to various elements along the same paths as port:qt5 does (e.g. /opt/local/libexec/qt5/include -> /opt/local/include/qt5). With this I have been able to install the binary Qt5 Creator package and run the application without issues.
I have implemented a PortGroup wrapper that takes care of handling most differences between the 2 ports by including the appropriate "payload" PortGroup. As a result, users can install either Qt5 port as a mostly transparent alternative for the other without being obliged to have both installed and activate either the one or the other. A preference setting is provided whereby ports can indicate which Qt5 flavour they prefer, which is what gets installed if no Qt5 port is available yet.

With these adaptions I think there is little hard reason not to admit qt5-kde : users who don't care about KF5 ports or have reason to run port:qt5 with its fewer patches and all-encompassing install prefix are served as they are now, while users who do want to use KF5 applications in optimal form (or use port:qt5-kde for some of its other specifics, like e.g. providing Qt 5.3.2 on OS X 10.6) also get a choice. They'll still be able to use regular ports depending on Qt5 - at the moment those will be built from source when port:qt5-kde is installed instead of port:qt5 .

I'm launching this thread to discuss ways to streamline this. For there is a caveat. Originally, the Qt4 and Qt5 ports installed all Qt components, so dependent ports could simply include the respective PortGroup which would then add an appropriate (path:-style) dependency. My own QtWebEngine subport, and now mcalhoun's complete separation into a 1-subport-per-component design make this less trivial (port:qt5-kde does provide the equivalent subports as stubs, btw).
Ports that want to depend on only the components they require (or require QtWebEngine, in my case) can no longer simply include the PortGroup because all those component subports follow a "${name}-component" naming scheme.

Addressing the qt5-kde-qtwebengine dependency issue would be simple enough for ports that simply continue to depend on all Qt5. A flag (qt5.depends_qtwebengine) can be used to add the appropriate depends_libs command in the qt5-kde PortGroup.
But the only way to handle this elegantly and transparently would be to provide a dependency procedure, where ports could do something like

{{{
set qt5.selective_dependencies yes
# set qt5.prefer_kde yes
PortGroup qt5 1.0

qt5.depends_libs qtbase qtwebengine
}}}

Each "payload" PortGroup (qt5-kde-1.0.tcl and what I've called qt5-mac-1.0.tcl for lack of a better name) would add the appropriate dependency statements in its specific implementation of the qt5.depends_libs procedure, ideally using the path:- style :

For port:qt5 you'd get
depends_libs-append   path:libexec/qt5/lib/QtWebEngineCore.framework/Versions/5/QtWebEngineCore:qt5-qtwebengine

and for port:qt5-kde
depends_libs-append   path:libexec/qt5/Library/Frameworks/QtWebEngineWidgets.framework/Versions/5/QtWebEngineWidgets:qt5-kde-qtwebengine

or
depends_libs-append   path:libexec/qt5/libs/QtWebEngineWidgets.framework/Versions/5/QtWebEngineWidgets:qt5-kde-qtwebengine

because that path is valid too and ensures compatibility with port:qt5 even though if that port is installed one should never get a dependency on qt5-kde-qtwebengine .

I've used a comparable procedure in my KF5 PortGroup, and that works perfectly.

Of course this would have to be agreed upon between mcalhoun, me, and all potentially concerned port devs.

Thanks,
René