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

[MacPorts]

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

Old description:

> Here's an initial implementation of a PortGroup and the basic ports
> required to deploy KF5 through MacPorts, thanks in large part to lots of
> preliminary heavy lifting behind the scenes by Marko Känig. Without him
> this would have been much more work.
>
> This initial submission contains the PortGroup, the Frameworks, and a few
> tightly related ports.
> As always, further development can be followed via
> https://github.com/RJVB/macstrop/tree/master/kf5 .
>
> KDE5 is not a straightforward thing to deploy (package), in some ways
> even less so than KDE4, but in other ways "things" have improved
> sufficiently that a lot can be abstracted and automatised (more so than
> with KDE4).
>
> Most of that is done in the PortGroup, which contains the basic logic
> that makes declaring a port for a given KF5 application relatively easy.
> It also contains version definitions, because despite being individual
> packages, KF5 components are released in synchronised fashion, and won't
> build against older components.
> The PortGroup is also responsible for including the Qt5 PortGroup, and
> does so by indicating a preference for `port:qt5-kde`.
>
> The frameworks themselves, the building blocks on which KF5 applications
> are based (and "interesting/useful extensions to Qt5") are a bit
> different. I have chosen to bundle all frameworks as subports in a single
> (huge) portfile, in order to increase sharing of patches and reinplace
> statements (something the benefits of which I hope I won't have to
> explain). The meta-port is almost complete; it lacks only a number of
> "porting aid" frameworks which I plan to add when needed (or "in due
> time").
>
> That meta-port, KF5-Frameworks, also contains the variant that I consider
> crucial for MacPorts, the one that activates the XDG-compliant mode of
> Qt's QStandardPaths. In a nutshell, this is the mode in which makes Qt5
> (and KF5) code look for shared resources under ${prefix}/share, and use
> ~/.config, ~/.local and ~/.cache instead of the OS X-ish equivalents.
> Individual applications (pure Qt5 or KF5) may be adapted or even
> conceived to use the Apple-equivalents of these locations, but KF5
> applications as a whole are designed primarily to function in a
> Freedesktop (XDG) universe, and cohabit/interact with other XDG-compliant
> applications that are *not* based on Qt5 (e.g. KDE4!). I consider this
> something MacPorts cannot ignore or not support.
> I'd even go so far as to remove the possibility to build KF5 otherwise,
> but as long as the QSP patch is only shipped with `port:qt5-kde` I see no
> other way than to provide a variant that becomes a default variant if the
> QSP/XDG activator is detected at build time. The KF5 PortGroup indicates
> a preference for `port:qt5-kde` and therefore it is that port which will
> be installed during a fresh install or on a build bot. I am aware this is
> a potential violation of the repeatable build principle, but only for/by
> users who go against a recommended dependency (and these users will be
> obliged to install all KF5 ports from source).
>
> NB: The XDG activator is an additional link module that I bundle with my
> `port:qt5-kde`; linking it with all KF5 frameworks means that any KF5
> application will use QStandardPaths in XDG-compliant mode; this blunt
> approach is required since there is no single KF5 component with which
> all dependents are obliged to link. Making the compliancy mode optional
> (and inactive by default) means that "pure Qt5" applications function
> with native OS X QStandardPaths, and will thus behave exactly as their
> counterparts if installed from an official installer other external
> source.
> I consider that of equal importance as the repeatable build principle.
>
> Also note that there are a number of tweaks that allow me to use the same
> build and packaging logic on Linux, for testing and comparison; those
> tend to relax dependencies so they are obtained from the host. I'm not
> adamant on "getting these in" of course, but as long as I'm principle
> maintainer on these files I'm also not very keen on removing them .

New description:

 Here's an initial implementation of a PortGroup and the basic ports
 required to deploy KF5 through MacPorts, thanks in large part to lots of
 preliminary heavy lifting behind the scenes by Marko Käning. Without him
 this would have been much more work.

 This initial submission contains the PortGroup, the Frameworks, and a few
 tightly related ports.
 As always, further development can be followed via
 https://github.com/RJVB/macstrop/tree/master/kf5 .

 KDE5 is not a straightforward thing to deploy (package), in some ways even
 less so than KDE4, but in other ways "things" have improved sufficiently
 that a lot can be abstracted and automatised (more so than with KDE4).

 Most of that is done in the PortGroup, which contains the basic logic that
 makes declaring a port for a given KF5 application relatively easy. It
 also contains version definitions, because despite being individual
 packages, KF5 components are released in synchronised fashion, and won't
 build against older components.
 The PortGroup is also responsible for including the Qt5 PortGroup, and
 does so by indicating a preference for `port:qt5-kde`.

 The frameworks themselves, the building blocks on which KF5 applications
 are based (and "interesting/useful extensions to Qt5") are a bit
 different. I have chosen to bundle all frameworks as subports in a single
 (huge) portfile, in order to increase sharing of patches and reinplace
 statements (something the benefits of which I hope I won't have to
 explain). The meta-port is almost complete; it lacks only a number of
 "porting aid" frameworks which I plan to add when needed (or "in due
 time").

 That meta-port, KF5-Frameworks, also contains the variant that I consider
 crucial for MacPorts, the one that activates the XDG-compliant mode of
 Qt's QStandardPaths. In a nutshell, this is the mode in which makes Qt5
 (and KF5) code look for shared resources under ${prefix}/share, and use
 ~/.config, ~/.local and ~/.cache instead of the OS X-ish equivalents.
 Individual applications (pure Qt5 or KF5) may be adapted or even conceived
 to use the Apple-equivalents of these locations, but KF5 applications as a
 whole are designed primarily to function in a Freedesktop (XDG) universe,
 and cohabit/interact with other XDG-compliant applications that are *not*
 based on Qt5 (e.g. KDE4!). I consider this something MacPorts cannot
 ignore or not support.
 I'd even go so far as to remove the possibility to build KF5 otherwise,
 but as long as the QSP patch is only shipped with `port:qt5-kde` I see no
 other way than to provide a variant that becomes a default variant if the
 QSP/XDG activator is detected at build time. The KF5 PortGroup indicates a
 preference for `port:qt5-kde` and therefore it is that port which will be
 installed during a fresh install or on a build bot. I am aware this is a
 potential violation of the repeatable build principle, but only for/by
 users who go against a recommended dependency (and these users will be
 obliged to install all KF5 ports from source).

 NB: The XDG activator is an additional link module that I bundle with my
 `port:qt5-kde`; linking it with all KF5 frameworks means that any KF5
 application will use QStandardPaths in XDG-compliant mode; this blunt
 approach is required since there is no single KF5 component with which all
 dependents are obliged to link. Making the compliancy mode optional (and
 inactive by default) means that "pure Qt5" applications function with
 native OS X QStandardPaths, and will thus behave exactly as their
 counterparts if installed from an official installer other external
 source.
 I consider that of equal importance as the repeatable build principle.

 Also note that there are a number of tweaks that allow me to use the same
 build and packaging logic on Linux, for testing and comparison; those tend
 to relax dependencies so they are obtained from the host. I'm not adamant
 on "getting these in" of course, but as long as I'm principle maintainer
 on these files I'm also not very keen on removing them .

--

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