[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 mati865@…):

 Replying to [comment:25 mk@…]:
 > Replying to [comment:24 mati865@…]:
 > > On second though I'll create modified Qt like you did.
 >
 > Hi mati865, how are things going for you on MSYS2 wrt a KF5'ish qt5
 patch and all the KF5 frameworks? Can you post a status update for your
 endeavor here from time to time?

 I was waiting with reply until I finish the patch. It took so long because
 recompilation of Qt with Core 2 Duo CPU takes it's time (well, a lot of
 it) but now the patch is almost done. While it's current state prevents it
 from getting merged into Qt it can still be used as starting point:
 https://github.com/Alexpux/MINGW-packages/pull/1640


 Replying to [comment:26 rjvbertin@…]:
 > I've been following this from a distance while on holidays.
 >
 > Sadly I've never really looked at how the MSWin QStandardPaths (QSP)
 class is implemented and what kind of paths it returns compared to what it
 "should" return for MSYS2. I've never really used MSYS2 but from what I
 remember it aims to do similar things as Cygwin but without or with much
 less overhead (and without a dedicated runtime DLL) (?).
 >
 > That said, yes, I do think your best bet would be to patch Qt like we
 did. I must admit that my first reaction was that our patches will be so
 different that there's little to "collaborate" on. On second thought there
 might be a reason. It is my intention to try and get our patch into Qt.
 The chances to that should increase if other platforms can also benefit
 from a modified/extended QSP class that 1) allows applications to be build
 such that they use appropriate paths instead of the "native" ones while 2)
 the default way of building code still yields the default, "native" paths.
 >
 > I should add that someone submitted a patch for Qt review that allows
 something like this for the writable paths, using the `qt.conf` file. If
 that sounds interesting but not familiar, please don't hesitate to remind
 me in a couple of days so I can dig up the link.

 qstandardpaths_win.cpp compared to qstandardpaths_unix.cpp is a unreadable
 because of Win API usage. Since MSYS2 use Linux like paths it was easy to
 implement new functions on top of qstandardpaths_unix.cpp with added
 "Msys" at the end. Then sed replaces all occurrences of QSP with those new
 functions.
 You are partially right about MSYS2. While Cygwin does everything inside
 emulated POSIX, MSYS2 only use emulation for "/usr". Additionally there
 are "/mingw32" and "/mingw64" paths where native software is placed
 https://sourceforge.net/p/msys2/wiki/MSYS2%20introduction/

 Windows platform is a bit different and MSYS2 paths must be listed before
 Windows native paths. Implementing new functions with proper returns was
 an easy solution.

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