[MacPorts] #51619: qt5.depends_component procedure

[MacPorts]

#51619: qt5.depends_component procedure
---------------------------+----------------------
  Reporter:  RJVB          |      Owner:  mkae
      Type:  enhancement   |     Status:  assigned
  Priority:  Normal        |  Milestone:
 Component:  ports         |    Version:
Resolution:                |   Keywords:
      Port:  qt5, qt5-kde  |
---------------------------+----------------------

Comment (by RJVB):

 > Do I understand correctly that qt5-kde is currently more or less qt5 + a
 bunch of modifications needed to run KDE apps

 More or less, indeed. There is at least 1 crucial patch (for getting
 "Linuxy" locations), there are a few patches which improve the experience
 like by allowing a different platform theme to be loaded automatically.
 There are also patches being developed upstream that address issues which
 are more likely to occur in KDE apps (related to using DBus, for
 instance), plus a number of patches for general little things that either
 were already in the old qt5-mac port when I started working on it or that
 come from Debian, and which still apply.

 There is 1 other big difference, which may or may not be crucial: the
 installation layout. I've documented this extensively last year. In short,
 my approach follows Qt's implicit guidelines for installing different
 versions in parallel as system libraries in the same prefix. The old qtN-
 mac ports put the shared resources (plugins, mkspecs, etc) under a Linuxy
 location, /opt/local/share/qtN, and I remember running into issues with
 KDE4 when I tried to change that. So basically I kept all those old
 locations which never conflicted between the Qt4 and Qt5 ports, and that
 includes the CMake modules (as you already found out).
 I lack the resources to figure out if indeed this difference is crucial
 and to what extent. The point to keep in mind here is that KDE
 applications come from the FreeDesktop environment and are designed to
 interact with others from that same environment. That includes KDE4 and
 GTk/Gnome apps. Those all use /opt/local/share, so much hunch is that
 Qt5/KF5 applications best do the same in order to reach their full
 potential.
 It can of course be absorbed by using symlinks just as Marcus currently
 does with the pkgconfig files.

 As a side-note: that kind of solution to make files appear in the location
 where they should be just increases filesystem clutter. It's an approach
 that can make sense if you're installing stuff without registry and you
 want to keep track of who installs what so you can uninstall/deactivate it
 with a few simple commands. With a package manager that knows exactly who
 installs what you can just as well put the actual files in the required
 location.

 > and there would be no harm if everyone would use that patched version

 Indeed, I've always striven to ensure that the port can be used by
 everyone - I myself also use it for everything. That's one reason why the
 crucial ("QSP") patch is more complicated than it could be: just applying
 the patch itself changes nothing in Qt's behaviour. In its current
 version, software needs to be built with 1 or 2 tokens set in order to
 activate new feature the patch introduces. That's of course a sine-qua-
 none for upstreaming the patch, but just as much to me for acceptance into
 MacPorts.

 > (or even better convince the upstream Qt 5 developers to include those
 patches and then there would be just a single version remaining anyway)?

 Yes. But I am doubtful that we can achieve that. There was momentum and a
 more or less open mind for the special needs of projects like MacPorts at
 some point, but that's probably almost 2 years ago by now. That time span
 and the fact the likes of Fink and HomeBrew haven't waited don't actually
 support my arguments. Getting patches into Qt is so difficult that there
 is at least 1 company that lives off it.

 > * Users don't end up with packages that were built with a different
 version of Qt (like having 5.5 installed and then installing a binary
 package that was built against 5.6).

 Agreed. As discussed elsewhere this can be achieved by using a variant as
 a label. One or two things could be changed in "base" to streamline this,
 but it's already possible and this is actually the main thing that
 variants do in "base" (everything else depends on port-specific
 implementation).

 I think that a solution to this point will also address (prevent)
 potential violations of the reproducible build principle.

 > * Ports declare dependencies in a proper way, so that the same port will
 depend on qt55-something on one system and on qt56-something on another
 without every single port implementing "if this is 10.7, then use
 qt55-something, if this is 10.8-10.10, use qt56-something, if this is
 10.11 or later, use qt57-something".

 OOPS, before the wrong idea gets in peoples' minds: Qt 5.7 still supports
 10.9!! I'm working on upgrading to 5.7.1 as we speak! We'll see about 5.8,
 but even QtWebEngine 5.7.1 builds and runs fine (with 1 issue & patch I've
 reported upstream).

 I guess it will shock no one if `port deps foo-qt5` will return "qt55" on
 10.7?

 But just how shocking is it if that return value depended not simply on OS
 but also (or instead) on the installed Qt version? I can think of nothing
 in MacPorts dogma that forbids this explicitly. I also think it's
 certainly not illogical ("if you have qt55-base installed you should also
 depend on qt55-whatever if you need the whatever component"). It's even
 going to be necessary if qt55-* and qt5-* declare mutual conflicts, as
 they should.

 Side-note: port:qt5-kde has had support for building Qt 5.3.2 on 10.6 for
 a long time now. This could and should maybe be moved to a dedicated port
 by now since KF5 has been requiring later Qt versions for a few iterations
 now.

--
Ticket URL: <https://trac.macports.org/ticket/51619#comment:25>
MacPorts <https://www.macports.org/>
Ports system for macOS