submission: port:qt5-kde

[RJVB (René Bertin)]

Marko Käning and I discussed the benefits of having a dedicated Qt5 ports on which future KF5 ports could depend in the past, and the idea became much more appealing just before summer after mcalhoun updated his long-neglected port:qt5-mac discarding my own months of work on this port almost completely.

In short, this proposed port:qt5-kde :

• currently provides Qt 5.5.0

• is coinstallable with Qt4 (but not other Qt5 port(s) of course)

• incorporates a set of patches based on those for Qt4 that improve the user experience with KF5 apps (formerly provided as the +KDE variant)

• uses the install layout based on the tried-and-true layout of the non-coinstallable port:qt4-mac; version-specific executables and libraries/frameworks are installed under ${prefix}/libexec/qt5, headerfiles under ${prefix}/include/qt5 and the rest under ${prefix}/share/qt5 and ${prefix}/share/doc/qt5 (which is how port:qt4-mac installed these items). I am convinced that this layout to be preferred when using Qt-based applications that adhere to Freedesktop conventions and are supposed to be able to interact and share resources with other Freedesktop applications (GTk/Gnome).

• includes a patch that will allow (KF5) applications to find shared resources in the standard XDG-style locations (${prefix}/share, etc) rather than in OS X style locations (~/Library/Application Support, etc). This patch needs to be activated so doesn't affect (pure Qt) applications that were built without the activator.

• provides a legacy variant that builds Qt 5.3.2; this is automatic on OS X 10.6 where that Qt version is the latest that can be built (requires port:clang-3.4 or port:clang-3.5).

I believe the above feature set justifies having an additional, alternative Qt5 port. In order for dependent ports to function with both ports, I split up the Qt5 Portgroup in a qt5-mac and a qt5-kde Portgroup; the new Qt5 Portgroup contains a selection mechanism to force select either the one or the other but will also load the appropriate Portgroup as a function of whether port:qt5-mac or port:qt5-kde is installed. The default/fallback is to install port:qt5-mac ; the changes to the Qt5 Portgroup should be transparent (and are indeed according to my testing).

Binary builds against port:qt5-mac will of course not function with port:qt5-kde. Therefore, the qt5-kde Portgroup defines a (default) variant (qt5kde) that should only be known to the build bots for ports that require port:qt5-kde specifically. A user having port:qt5-kde installed and requesting the install/upgrade of a generic Qt5 port (say, port:qt5-creator) will in fact request port:qt5-creator+qt5kde, which is not available in binary version. This mechanism is of course not tested exhaustively, and I am open to ways to improve it.

As a bonus feature, this port also builds on Linux. ;)

I'm uploading a tarchive that contains everything needed; uploading diffs wouldn't make a lot of sense (they wouldn't be easier to peruse than studying the Portfile, patches and portgroup files, IMHO). The evolution of this port can also be followed on my repo, github.com/RJVB/macstrop .

[RJVB (René Bertin)]

FWIW, I'm currently testing a version where qt5-kde provides and depends on a qt5-kde-base subport, that provides the QtBase component (including qmake and the platform plugins). It should be possible to build very simple Qt applications against only that minimal subset. The main idea however is to be able to build QtBase with different (compiler) options than the higher level components, for instance to make debugging easier. (NB: LTO builds appear to lose all debugger info.)

EDIT: put off for later. It turns out that "building all in a single go" requires QtBase to be built as well. Alternatively, one installs each component individually, after installing QtBase, and in a specific order dictated by inter-component dependencies.

[RJVB (René Bertin)]

Added a patch for building on 10.11, following ​https://trac.macports.org/ticket/48252#comment:21 . The patch is tested, but not the build.

[RJVB (René Bertin)]

I'm in the process of building qt5-kde for Qt 5.5.1 and will update the full port bundle once I'm confident there are no issues with it (on 10.9).

Pending that update, I'm already attaching the modified PortGroup files which take into account the latest changes to the mainstream/default port, which is now port:qt5 .

• It still works through a "header" PortGroup, which takes the place of the current PortGroup, and which includes either the main PortGroup or my qt5-kde-1.0.tcl PortGroup

• 1 for now, I continue to rename the default (mcalhoun's) PortGroup to qt5-mac-1.0.tcl
• 2 the qt5.prefer_mac variable used by the header PortGroup is now called qt5.prefer_default
• 3 presence of port:qt5 is detected through the install location of ${qt_plugins_dir}, which contains the QPA Cocoa platform plugin and is thus always present.
• 4 port:qt5 now installs to ${prefix}/libexec/qt5, like my port:qt5-kde. There should thus no longer be compatibility issues with binary packages or exchanging the ports. The +qt5kde default variant set in the qt5-kde PortGroup should thus no longer be required; I'm keeping it for now.

Re. (1): I am not really happy with having a PortGroup called "mac" selected through a variable called "default", but I don't really like "qt5-default-1.0.tcl" either. I considered using qt5-1.1.tcl, but if anything it is the header PortGroup that should see a version increase.

[RJVB (René Bertin)]

stock PortGroup (from 20151113)

[RJVB (René Bertin)]

Portfile for port:qt5-mysql-plugins

[RJVB (René Bertin)]

As promised, I've attached the updated port directory for port:qt5-kde, and thrown in a Portfile for port:qt5-mysql-plugins.

[RJVB (René Bertin)]

I've updated the QSP patch so it also provides a Freedesktop/XDG-compliant XDG::RuntimeLocation path. For now I've set this to $TMPDIR/runtime-$USER because that's what the generic Unix code used to determine the path returns. If MacPorts considers that this location should resolve to ~/.cache than that's fine with me too, in principle.

[mojca (Mojca Miklavec)]

Cc Me!

[RJVB (René Bertin)]

Here's an updated version that introduces a few major KDE-related changes

• It is now possible again to have Qt applications use a different theme. The feature is much more restricted than how it used to be with Qt4: it is in fact intended only for use with KDE themes/styles. It requires installing port:kf5-frameworkintegration and then setting the env.variable KDE_SESSION_VERSION to 4 or higher. Do this in your .[t]cshrc/.bashrc/.profile as well as via launchctl setenv KDE_SESSION_VERSION n.
  People who have KDE4 installed (esp. port:kde4-workspace may want to set the version to 4 instead of 5.
  Note that the QtCurve-qt5 theme is configurable via port:QtCurve (the KDE4 version) regardless of the KDE_SESSION_VERSION value.
  Set your theme to "macintosh" to use the native theme combined with KDE's fonts, colour palette and icon settings .

• A complementary patch enables support in the native platform theme for XDG/Freedesktop icon themes from ${prefix}/share/icons in applications that run with QStandardPaths in XDG-compliant mode (the default for KF5 applications). This provides access to the icon themes even when using the native ("macintosh") theme without kf5-frameworkintegration installed/active.
  Note that this will give icons in dialog buttons in certain applications! I am testing a patch for QtCurve that will make it respect the KDE setting to hide icons in push buttons.

• An upstream patch that will be incorporated in a future Qt version disables plugin unloading at exit, which prevents crashing instead of exitting cleanly.

• port:qt5-kde now installs symlinks in ${prefix}/libexec/qt5 that allow it to emulate the port:qt5-* ports, and should thus make it binary compatible with (i.e. a drop-in replacement for) the mainstream Qt5 ports. This still requires testing.

[RJVB (René Bertin)]

New version:

• fixes permissions on certain patchfiles
• suppresses the unused +debug variant (see below)
• merges the qmake5 PortGroup with mcalhoun's mainstream version
• adds a patch to improve behaviour when using the AA_DontSwapCtrlAndMeta attribute
• adds a check to verify if the auto-requested SDK is present (I recommend building Qt using the SDK that corresponds to the OS version).

port:qt5-kde builds with debug information included, which provides line and function call information in backtraces and allows for basic debugging. For more advanced debugging (= work *on* rather than *with* Qt), build using configure.optflags="-O0 -g" and use port de/activate to select the debug or the regular variant of the port. This works much better than Qt's contrived way of bundling debug and normal builds in a single framework.

[RJVB (René Bertin)]

It seems that out-of-source builds require specifying an SDK explicitly; this adds the logic to configure for the host's default SDK if the preferred SDK isn't available (preferred = the SDK matching the OS version).

Thanks to Marko for his patience in helping to figure this out remotely.

[RJVB (René Bertin)]

Fixed a very annoying error in the Qt5 "header" PortGroup, which hardwired ports using the qmake5 PortGroup to the mainstream port:qt5 ...

[RJVB (René Bertin)]

Fixes a rare side-effect of not treating configure.optflags as a list in the +LTO handling in qt5-kde-1.0.tcl .

[RJVB (René Bertin)]

New version that modifies the cmake script post-processing to make it more robust and flexible.

[mkae (Marko Käning)]

Hi René,

the update went seamlessly through here on my end! Thanks for taking care of all this! I saw there was a message now at install time hinting out the theme handling to the user. Neat!!!

Looks like we should go forward and commit this port with its dependencies to MacPorts eventually...

Greets, Marko

[RJVB (René Bertin)]

't wasn't much of an update, but well, good to know it went smooth anyway :)

Committing this would be great of course. We could do with some more testing of just how compatible this port is with binary packages built against the current mainstream Qt5 ports (I'll refer to them as port:qt5-mac in this comment). As I told you in an email I have been able to install the binary package for Qt5 Creator against my qt5-kde install. That should be a good indication (I presume Qt Creator uses=tests many if not most of Qt's features) but it is still only a single sample, maybe not even an unbiased one. It'd be nice if someone could also test what happens when you deactivate port:qt5-mac and activate/install port:qt5-kde to see if I install the right mix of stub directories and symlinks that provide the runtime/binary compatibility.

There is also the question of the reproducible build principle and the +qt5kde variant. That variant was introduced as a protection against installing binary packages built for port:qt5-mac while still allowing binary packages for qt5-kde specific ports (the variant is set default_variant when it is detected that the user has port:qt5-kde installed). It seems that protection is no longer necessary, but there is still the reproducible build principle. Building, say, port:qt5-creator from source when you have port:qt5-kde installed will give a result that is not entirely identical to the result of a build against port:qt5-mac . Of course that is the same kind of difference you can get when you build against the alternative of any other port that provides "drop-in alternatives", say ffmpeg-devel instead of ffmpeg.

And then finally there is the question of the PortGroup. I've done my best to ensure that the logic that gets invoked when a Portfile does PortGroup qt5 1.0 does the right thing. By default, it will still get the mainstream Qt5 PortGroup, of course; the qt5-kde PortGroup (qt5-kde-1.0.tcl) will only be used when either 1) port:qt5-kde is detected or 2) port:qt5-kde is preferred by the port in question and no Qt5 port is yet installed. The only "issue" at this level: I'd want this to be transparent (= ports shouldn't have to change the PortGroup qt5 1.0 statement). I also think that it is best if each (group of) Qt5 port maintainer(s) has/have his/their own "simple" PortGroup file to maintain. That means I renamed the current Qt PortGroup to qt5-mac-1.0.tcl and replaced it with a "header" that takes care of including the required PortGroup file using the aforementioned logic (and only that logic). Other names are of course possible for the "standard" PortGroup, and other solutions can be discussed as well. I'll be updating the attached PortGroup files.

[RJVB (René Bertin)]

the Qt5 "header" PortGroup

[RJVB (René Bertin)]

the current "mainstream"/"official" Qt5 PortGroup

[RJVB (René Bertin)]

the PortGroup for port:qt5-kde which is used either when port:qt5-kde is installed or when a port prefers qt5-kde and no port:qt5* is installed yet.

[RJVB (René Bertin)]

My port:qt5-kde now provides Qt 5.6.0, which I find significantly snappier.

[RJVB (René Bertin)]

Qt 5.6 no longer installs the pkg-config (.pc) files; this version restores them.

[RJVB (René Bertin)]

fixes a crash in QNSView and building the qt5-kde-qtwebkit stub port

[RJVB (René Bertin)]

New version that includes the upstream patches for a crash-at-exit and to remove DBus dependencies from the platformsupport component (which only affects some features of the X11 subport).

[RJVB (René Bertin)]

Final Qt 5.6.0 version

[mkae (Marko Käning)]

BTW, Qt 5.7 is out as of today...

[RJVB (René Bertin)]

unholy sh* :-/

I was afraid this would happen, I knew 5.7 was very closely behind 5.6 .

From what I hear I'll have to refactor my QSP patch, but I really hope it will require less effort otherwise; I still remember how much time it took to upgrade to 5.6!

[RJVB (René Bertin)]

A bit later than planned, here's port:qt5-kde 5.6.1 .

Also contains my proposed solution for ​https://trac.macports.org/ticket/51643 . The qt5 header/wrapper PortGroup sets universal_variant no. The Qt5 PortFile can include the muniversal PortGroup itself to support building as a universal binary. Similary, ports wishing to support universal builds can either reset universal_variant yes or include the muniversal PortGroup. I propose to set universal_variant no by default and to require explicit action from Qt5 dependents because standard universal builds are not officially supported (= tested) on OS X even if they probably work for not-too-complex builds.

[RJVB (René Bertin)]

I started running into an issue where infinite symlink loops were being created. Not sure why this didn't lead to errors before; should be fixed now.

[RJVB (René Bertin)]

Simplified version of the QSP/XDG patch, which clears the way for making this patch relevant in more contexts (including MS Windows). All external use of the XDG term is dropped in favour of ALT (alternative). Nothing changes for dependent software; no rebuilds are required.

[RJVB (René Bertin)]

This release introduces some more tweaks to the simplified QSP/ALT patch, notably to allow finding the user's qtlogging.ini file in either the standard or the alternative (XDG-compliant) GenericConfigLocation (~/Library/Preferences/QtProject vs. ~/.config/QtProject).

[RJVB (René Bertin)]

This version fixes several configure and build issues and should work with Xcode 8+

[RJVB (René Bertin)]

This release moves QtWebKit to its own, "real" subport, and removes the automatic dependency generation for this subport.

Port that need to depend on QtWebKit can do 2 things:

• Use the provided variable to generate a dependency on qt5-kde-qtwebkit (also accepts qt5-kde-devel-qtwebkit):

  depends_libs-append  ${qt5webkit_dependency}
  

• Use the provided declarative syntax (which again will accept qt5-kde-devel-qtwebkit as well):

  qt.depends_component qtwebkit
  

All other components except for QtWebEngine are still provided by port:qt5-kde. The 2 component subports correspond to big and expensive-to-build components which are rarely used (as yet; QtWebEngine) or officially obsolete (and supposedly being phased out by dependents; QtWebKit).

NB: port:qt5-kde-qtwebkit provides the QtWebKit version corresponding to QtBase (currently 5.6.1), not v5.5.1 as provided by port:qt5-qtwebkit .

[mkae (Marko Käning)]

René, before I do anything with qt5-kde stuff (pulled from your macstrop repo) I always (have to) copy those group files:

~/WC/GIT/macstrop/_resources/port1.0/group/qt5-1.0.tcl 
~/WC/GIT/macstrop/_resources/port1.0/group/qt5-mac-1.0.tcl 
~/WC/GIT/macstrop/_resources/port1.0/group/qmake5-1.0.tcl 
~/WC/GIT/macstrop/_resources/port1.0/group/cmake-1.0.tcl 
~/WC/GIT/macstrop/_resources/port1.0/group/qt5-kde-1.0.tcl 
~/WC/GIT/macstrop/_resources/port1.0/group/macports_clang_selection-1.0.tcl 
~/WC/GIT/macstrop/_resources/port1.0/group/locale_select-1.0.tcl 

into my MacPorts installation.

If we're proceeding with introducing the qt5-kde(-devel) ports to MacPorts (unless we find a way to merge it with mcalhoun's port qt5) we'd need to also introduce/change these group files!

I think this would have to be announced/discussed on the MacPorts-devel ML to ensure a smooth transition... Perhaps it would be good to create tickets with patches for every group file, so that everything is kept in 3 separate places (one for qt5 stuff, one for clang and one for the locale_select) for clarity?!

What do you think?

[RJVB (René Bertin)]

I think I have already tried to do something like this on several occasions... without much success. But you're right. Or ... we could just see what happens when we push the modifications ;) I say that as a joke, but I do feel that certain other port devs have been ignoring my attempts at a constructive dialog a bit too much for a bit too long. There's this common wisdom that silence signals agreement ;)

Have you ever (recently) tried to see what happens when you don't use my cmake-1.0 PortGroup? That one could theoretically get a version bump to avoid issues with Michael. Since I'm not proposing a different cmake port that works users can install in place of the other there is no real need to replace the current cmake portgroup. As long as the KF5 portgroup includes the right one we get all the benefits I introduced there were it counts.

The qmake5 PortGroup has a dual mode, "mine" for qt5-kde, and "his" for use with port:qt5. Funnily the situation is the opposite as with cmake here: in qt5-kde mode it is less complex than in port:qt5 mode. We could test what of "my mode" is really required.

I've just made the locale_select and clang_selection portgroups optional. They'll be used if they're found in the same directory, otherwise the features they introduce are simply skipped. That shouldn't cause any issues, so I invite you NOT to copy these files in the future.

[RJVB (René Bertin)]

This release fixes a build error in port:qt5-kde-qtwebkit and makes the locale_select and macports_clang_selection portgroups optional.

[mkae (Marko Käning)]

Build error for qt5-kde-qtwebkit? I didn't run in any when installing it on Mavericks and El Capitan just now...

OK, so locale_select and macports_clang_selection aren't really needed then?

[RJVB (René Bertin)]

That was the error you found yesterday. I hadn't yet published the fix in the tarball; I was waiting for your confirmation that it was indeed the correct and complete fix :)

OK, so locale_select and macports_clang_selection aren't really needed then?

No. The former allows (me) to cut down on the number of installed translations, and the latter makes automatic clang-mp-x.y selection work in a bit more intuitive fashion (prefer newer over older versions). I don't think that's required even for the legacy mode that builds 5.3.2 on OS X 10.6 .

[mkae (Marko Käning)]

OK, so we skip those two for now.

We're still left with 5 changed port group files then, but do we still need qt5-mac in there?

[mkae (Marko Käning)]

With KF5 in focus we have again two more port group files to copy:

• kf5-frameworks-1.0.tcl
• kf5-1.1.tcl

Right? :-)

[RJVB (René Bertin)]

Replying to mk@…:

but do we still need qt5-mac in there?

Not if you're OK with getting rid of mcalhoun's PortGroup ;)

Bad jokes aside, I propose to make the Qt5 PortGroup a 2-stage affair. The qt5-1.0.tcl file is the entry point, and depending on instructions from the port and what the user has installed, either my qt5-kde PortGroup is included, or else the standard one. Evidently I had to rename the standard PortGroup for that to work. Do you have a better suggestion how to call it instead of qt5-mac-1.0.tcl?

And yes, I split up the KF5 PortGroup. I found that better than introducing yet another control variable.

[mkae (Marko Käning)]

OK, I see, qt5-mac is mcalhoun's qt5 moved aside, of course... Sorry for the noise.

[RJVB (René Bertin)]

Quack quack quack, no problem ;)

Seriously, do you have an idea for a better name? qt5-stock?

Or should we envision what I wouldn't really like, i.e. call the entry file qt5-1.1.tcl (which then includes either qt5-1.0.tcl or qt5-kde-1.0.tcl), change all current Qt5 dependent ports to include the 1.1 version, and leave to to the maintainers of individual ports to downgrade that if they so desire?

[mkae (Marko Käning)]

No, I don't have a better name. This would have to be discussed in the ML, I guess.

[RJVB (René Bertin)]

quite a few small code cleanups; nothing that requires rebuilding

[RJVB (René Bertin)]

qt5-kde was missing the variants on its (stub) mysql-plugin and psql-plugin subports that port:qt5 provides. My bad. This release should fix that. Apologies to anyone doing incremental rebuilds for having to add a new variant to the build state file.

[mkae (Marko Käning)]

I believe we should start setting up a minimal set of port group files which are absolutely needed for introducing port qt5-kde officially for MacPorts! Once we have that we can coordinate the transition with qt5's maintainer mcalhoun and the other MacPorts developers interested.

As of now I was able to install this KDE-customized port with most of your KF5 ports on Mavericks, El Capitan and even Sierra.

I guess we are very close to a release, finally. :-)

[RJVB (René Bertin)]

Replying to mkae:

I believe we should start setting up a minimal set of port group files which are absolutely needed for introducing port qt5-kde officially for MacPorts!

I think I've already done that!

[mkae (Marko Käning)]

True. It's these:

macstrop/_resources/port1.0/group/qt5-1.0.tcl
macstrop/_resources/port1.0/group/qt5-mac-1.0.tcl
macstrop/_resources/port1.0/group/qmake5-1.0.tcl
macstrop/_resources/port1.0/group/qt5-kde-1.0.tcl

I meant that we have to set up VMs which only add/modify these 4 port groups to their port tree.

On top of that one would have to build all the rest bit by bit.

[RJVB (René Bertin)]

I've cleaned up the code a little bit and done some tiny tweaks to the portgroup.

[mkae (Marko Käning)]

René, in your latest tar there is still the qt532 folder. Is support for this old Qt version required for MacPorts? We're here currently at 5.6.1. It just looks like legacy not to be committed to the central repo, no!?

The PortGroup folder contains 6 portgroups. How is the status with the qmake PG? Can it be considered stable now? So, you suggest bringing in PGs locale_select and macports_clang_selection as well? Perhaps those could have their individual pull requests on GitHub as they're potentially useful for other ports as well?

[RJVB (René Bertin)]

The tarball is supposed to be a complete snapshot, including optional portgroups. You know which ones are required; anything optional doesn't have to be committed.

As to the qt532 folder: it's indeed a legacy support thing, which enables 10.6 users to build a Qt5 port using Qt 5.3.2 . That's always been one of the goals of my Qt5 port, even if it's completely unrelated to KDE.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In d1509f4a/macports-ports:

qt5-1.0.tcl: begin building infrastructure to support
different versions of Qt 5

Qt can make major functionality changes between minor version changes.
see ​https://github.com/Homebrew/homebrew-versions/pull/1191

Qt 5.6 is a long term support release which means MacPorts may

want to keep it around for a while.

see ​https://blog.qt.io/blog/2015/12/18/introducing-long-term-support/

If possible, we want to support as many versions of macOS as we can.
This sometimes means installing an older version of Qt.
see #51801

Finally, Qt requires substantial patches to KDE Frameworks 5, which

necessitates a separate port.

see #48967

[mkae (Marko Käning)]

Hi Marcus, great to see these improvements coming!

Let's see whether there's some overlap of your latest changes to qt5, which also qt5-kde (-devel) could profit from,@RJVB...

[RJVB (René Bertin)]

Thanks for the heads-up Marcus, if that's what it was.

I have a vague impression that maybe you're considering making a single Qt5 portgroup. In a way that would be the preferred solution but I'm not sure it's the most practical and feasible because we'd surely end up with something that has 2 sections. And that'd be the more cumbersome version of what I'm doing now and what has been tested by several people: 1 file per section and an "interface" or header PortGroup that decides which section to include.

As to 5.6LTS: I've brought up the idea of keeping it around in MacPorts and the reception was luke-warm, which I can imagine. It'll depend on how minimum OS version requirements evolve with 5.7.x and upwards, and what advantages updates to 5.6 have over the latest 5.7+ version that supports OS X 10.7 .

I do think I'll wait for 5.7.1 before I upgrade, though. Shouldn't be too long now, and it saves including upstream patches.

@Marko: I synced my version of the qmake5 PG with the upstream changes, as well as qt5-mac-1.0.tcl . I haven't seen anything in the other changes that is directly (immediately) useful for my own port. I'm monitoring though. The intention of my port is not to break anything.

I personally try to make a distinction between variables that are relevant for every port and those that are only relevant for the main port (Qt or KF5). Those that aren't relevant in dependent ports are put in a true namespace (qt5:: or kf5::). If we both did this that would make it a bit easier to see which ones are important to copy, or that could be moved to the header PortGroup when the time comes.

[RJVB (René Bertin)]

Oh, and I see I have my work cut out for me this week ... Qt 5.6.2 . Great ...

[RJVB (René Bertin)]

Qt's Assistant (the documentation browser from the QtTools component) has seen some (apparent) regressions in recent versions, causing degraded rendering of most if not all documentation. This turned out to be because of the QtWebKit deprecation, and our new approach of building QtWebKit as a separate component.

I've solved this by building the qt5-kde main port (which includes QtTools) without building the Assistant, and shipping the Assistant in a small subport of its own. This makes it possible to provide a +qtwebkit variant.

[RJVB (René Bertin)]

Continuing this ongoing saga in a fresh new ticket for this new spring: #53886 .