[MacPorts] #53778: Qt5/qt5-kde PortGroup

[MacPorts]

#53778: Qt5/qt5-kde PortGroup
-------------------------+----------------------
  Reporter:  RJVB        |      Owner:
      Type:  submission  |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:  haspatch
      Port:  qt5         |
-------------------------+----------------------

Comment (by RJVB):

 I have now a working prototype for the changes I would make to the qt5 1.0
 PG. In order:

 1. Move the `qt5.using_kde` declaration downwards, until *after* the
 potential control transfer to qt5-kde-1.0.tcl . This means the qt5-kde PG
 can continue to assume `qt5.using_kde` is never defined when it is loaded
 for the 1st time (and also means it can continue to use a standard Tcl
 variable). I realise it means that the variable won't be set when
 `just_want_qt5_version_info` is true, but I think there is little need for
 that anyway (correct me if I'm wrong).
 2. the control transfer logic itself, with what I hope are sufficient
 comments to explain what it does and why. In particular I think it's
 easier to distinguish between active `port:qt5-qtbase` and `port:qt5-kde`
 variants from installed files rather than from the registry for 2 reasons:
   a. there are now 3 qt5-qtbase ports ({qt5,qt55,qt56}-qtbase) with
 possibly more to come
   b. qt5-kde may also have a matching qt56-kde port, and also has a qt5
 -kde-devel variant that may be committed as well as another devel variant
 that will remain private to KF5 port maintainers and testers.

 All those different Qt5 ports install the same files, with certain
 differences between qt5*-qtbase and qt5*-kde* that are independent of Qt
 version; the depspecs provided by `qt5.depends_component` are based on
 this fact too.

 (And as argued a while back on the ML: a single check for the existence of
 a given file *must* require less operations than doing a pattern-match on
 the result of a registry lookup, and is thus almost certainly faster at
 least in theory.)

 You may notice the references to OS X 10.6 . Port:qt5-kde contains the
 rather blackish magic I concocted quite a while ago now to build Qt 5.3.2
 on that legacy OS version. It worked fine (even a universal build, IIRC)
 but I haven't tested it in a long time. In itself this support has nothing
 to do with KDE (much of KF5 now requires more recent Qt versions anyway)
 so I'm open to discussion about separating it, for instance in favour of a
 port:qt53 .

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