[KDE/Mac] KF5 and the QSP patch in qt5-kde - best approach/practices

[René J.V. Bertin]

Hello,

I'd like to request some feedback, once again. I've tried to be concise, and probably failed. Once again...

Until now I have been setting up my KF5 ports as follows:

- preferred dependency on port:qt5-kde which has the patch that allows QStandardPaths (QSP) to return either native locations (default) or XDG-compliant locations, under control of a mode switch that can be toggled via an activator module
- if the KF5 Frameworks meta-port detects the existence of the QSP/XDG activator module, a default variant is set (+qspXDG)
- that +qspXDG variant adds patchfiles and a few reinplace expressions to the KF5 frameworks subports; the result is that the QSP/XDG activator module is linked to all KF5 frameworks.

This way, KF5 applications all use QStandardPaths in XDG-compliant mode, and find shared resources like icon themes, plugins, DBus services etc. where they are installed by default (= under ${prefix}/share). Regular, "pure" Qt applications continue to use "native" locations like "Application Support".
Indicating a preference for port:qt5-kde and setting +qspXDG default when that port is installed means that the build bots will always install port:qt5-kde (instead of port:qt5) if and when that port becomes available, and thus that the binary builds will always build for XDG-compliant QSP locations; no reproducible build rules are violated as far as I can see.

This comes at a non-negligible maintenance cost (there are about 60 KF5 frameworks which are updated regularly, in principle all at the same time) and there can be side-effects when a "pure Qt" application starts to use even a single KF5 framework or KF5-based plugin.
As a side-note: supporting non-XDG QSP locations will require considerably more patching and maintenance effort of *all* KF5 ports (not just the frameworks). This is because the KF5 build system does not to my knowledge determine the install locations of shared resources based on QStandardPaths queries. That's the likely reason why KF5 applications in HomeBrew are crippled (I had another confirmation of that today).

The QSP patch has thus continued to evolve in hope of converging towards a form that is acceptable for incorporation into Qt. In its latest form it still has the activator module but also a way to hardcode the intended QSP mode via 1 or 2 preprocessor tokens (2 required for imposing XDG-compliant mode; I won't go into the underlying implementation here). This will allow to avoid the application-wide effect of the activator (link) module, but it also means that all KF5 software needs to be built with the same preprocessor tokens defined (or not defined). This can be handled via the KF5 PortGroup, but since cmake is used the implementation is a bit delicate.

Questions:

1)
What is currently the best way to be sure that all code is compiled with `-DQT_USE_EXTSTANDARDPATHS -DQT_EXTSTANDARDPATHS_XDG_DEFAULT` when it has be built with those options? Can these be added via configure.cppflags-append, IOW are the ${configure.cppflags} picked up *reliably* by cmake?
I have proposed changes to the CMake PortGroup that make this as reliable as I think it can be (https://trac.macports.org/ticket/49108) but that ticket hasn't seen much activity that wasn't my own.

2)
Use of preprocessor tokens means extra care managing the qspXDG variant. I think XDG mode should be the default for a distribution system like MacPorts, so I think that I will combine this approach with a +nativeXDG variant for those users who want to force KF5 software to build to use native locations. That variant could be set in variants.conf, but would also be set if the *absence* of my QSP patch is detected by the KF5 PortGroup.

Does that sound right?

The approach with -DQT_USE_EXTSTANDARDPATHS has a drawback that is relevant to mention here. With the activator link module, the build will fail if a user requests +qspXDG manually when port:qt5-kde is not installed. With -DQT_USE_EXTSTANDARDPATHS, the build will succeed but will evidently not be any different from the +nativeXDG variant - IIRC -nativeXDG on the commandline override the effect of `default_variants +nativeXDG` in a Portfile or PortGroup, correct?
Evidently there will be dyld failures for both QSP patch types when using mismatched Qt5/KF5 builds.

3)
The approach using preprocessor tokens is simpler (only Qt needs to be patched). However, given the point above should I pursue this approach or favour the current implementation using the activator link module?



Thanks,
René