Dear Qt folks,
regarding René's post from March (see below) I believe it would be good to
give a _short_ update on the qt5-kde port status.
Currently the situation for port qt5-kde is as follows:
- Qt at version 5.6.1
- tested building on Mavericks and El Capitan VMs
- René also managed to get qt5-kde-qtwebkit into a separate subport
- allows to build almost all of the KF5 ports @ version 5.24 successfully
- 5 port groups would have to be updated (see comments 30-34 in [1])
We are very interested in feedback from other Qt maintainers concerning our
chosen path to offer an alternative port for Qt5, which is dedicated to a
better user experience for KDE specifically.
Can we
a) find a way to merge qt5 and qt5-kde(-devel) somehow
b) or should we live with offering a dedicated Qt for KDE ??
What’s your opinion regarding this?
If you’re FOR b), I’d soonish like to commit this port because automated CI
is simply a must now. Us two doing all the build tests is tedious and error
prone.
Also we’d like to introduce the long-planned introduction of KF5 after all,
since KDE4 apps aren’t really maintained anymore.
Greets,
Marko
P.S.: I could also test it locally on a macOS "10.12.1 Beta” VM before
committing anything... although I’d prefer to delegate this job
to our macOS buildbot instead. ;-)
[1] https://trac.macports.org/ticket/48967#comment:30
On 17 Mar 2016, at 12:37 , René J.V. Bertin <[email protected]> wrote:
> 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
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
