[MacPorts] #49925: KF5 : PortGroup and initial ports (frameworks)

[MacPorts]

#49925: KF5 : PortGroup and initial ports (frameworks)
--------------------------+------------------
  Reporter:  rjvbertin@…  |      Owner:  mk@…
      Type:  submission   |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+------------------

Comment (by rjvbertin@…):

 A heads-up:

 I'm in the process of updating to KF5 5.20.0, which will contain the 1st
 step in a transition to a different QSP/XDG approach.

 Let me recapitulate.

 Qt5 introduced a special class to obtain the standard locations for
 various resources, QStandardPaths (QSP). On OS X, it will return locations
 like `Library/Application Support` where on other Unices it will return
 XDG-compliant paths like `share` or `local/share` instead.

 KF5 code uses that class, among others to find resources like icon themes
 but also DBus services (at least to register them). If KF5 applications
 are to function and interact with other XDG/FreeDesktop applications (that
 are not Qt5-based) as expected, QSP must be patched so it can return XDG-
 compliant locations.

 My `port:qt5-kde` contains a patch that allows to toggle QSP into an XDG-
 compliant mode, and this is where a transition is taking place. The patch
 provides both an XDG activator via a linker module (.framework) and via a
 subclass (QExtStandardPaths; QESP) that can replace QSP via a preprocessor
 macro.

 In the previous approach, I used a simple shortcut which defines "KF5
 application" as an application that uses even a single KF5 framework. Each
 KF5 framework was linked with the activator module, causing QSP to be
 switched to XDG-compliant mode when the framework was loaded. That works
 fine, but can have side-effects for instance when loading a KF5 plugin
 into Qt's Designer.

 I'm thus transitioning to the QESP-based approach, where code will use
 QExtStandardPaths instead of QStandardPaths when a preprocessor token is
 defined; QESP overrides the QSP functions so that they use either native
 or XDG-compliant locations depending on the value of another preprocessor
 token.
 These preprocessor tokens are set in the KF5 PortGroup, and thus the
 definition for "KF5 application" becomes "application that is built using
 [= part of] the KF5 PortGroup". Ditto for KF5 libraries and frameworks:
 they will use XDG-compliant locations internally (or native locations if
 the `+nativeQSP` variant is used), without altering the behaviour of "pure
 Qt" applications that use them.

 During the transition period I will actually be using both approaches in
 order to be sure everything works as planned. Code will be built using
 QESP configured for XDG-compliant locations, but the KF5 frameworks will
 still be linked with the QSP/XDG activator module. That activator can be
 disabled via an env. variable, which allows to compare behaviour with and
 without, without need for relinking.

 FWIW, I asked for feedback on this choice several weeks ago. I got none,
 so I'm now doing what I think best (and easiest to maintain).

-- 
Ticket URL: <https://trac.macports.org/ticket/49925#comment:17>
MacPorts <https://www.macports.org/>
Ports system for OS X