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