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é
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
