[MacPorts] #53777: Qt5 PortGroup : wrong use of qt5.using_kde and +qt5kde

[MacPorts]

#53777: Qt5 PortGroup : wrong use of qt5.using_kde and +qt5kde
--------------------+-----------------
 Reporter:  RJVB    |      Owner:
     Type:  defect  |     Status:  new
 Priority:  Normal  |  Milestone:
Component:  ports   |    Version:
 Keywords:          |       Port:  qt5
--------------------+-----------------
 I'm working on a separate ticket to enhance the Qt5 PortGroups so that we
 can continue working towards the introduction of `port:qt5-kde` .

 I found what I consider a bug : qt5-1.0.tcl uses `qt5.using_kde` as a
 mechanism to select using `port:qt5-kde` .

 That is NOT correct. As its name indicates, the`qt5.using_kde` state
 variable only informs ports what Qt5 port is being used. It is an internal
 representation of the `+qt5kde` variant, and this is also why I will not
 define it as an option variable myself.

 It is not intended to be modified by ports; the current MacPorts install
 either uses `port:qt5-kde` or it doesn't. There's nothing a port
 (Portfile) can do about that.

 Ports have 2 choices in to indicate which Qt5 port *should be used:
 1. They can set `qt5.prefer_kde` BEFORE they include the standard
 PortGroup; in that case they get `port:qt5-kde` if and only no Qt5 port is
 installed yet.
 2. They can include the `qt5-kde-1.0.tcl` PortGroup directly. This is
 intended to be a stronger preference, to be used only in ports that really
 don't work with the standard `port:qt5` family.

 All the `qt5-1.0.tcl` PortGroup should do is define and set
 `qt5.using_kde` to false (if it doesn't transfer control to
 `qt5-kde-1.0.tcl` of course, but that's the topic of the other ticket).

 I would also very much prefer if `qt5-1.0.tcl` did NOT define the `qt5kde`
 variant either. For the time being at least I'd like to have a way to
 detect certain unlikely situations from the unexpected situation
 {{{[variant_exists qt5kde] && ![variant_isset qt5kde]}}}. That could be a
 sign that `qt5-kde-1.0.tcl` is being used with a non-KDE Qt5 port, which
 shouldn't be allowed to happen.

 `qt5-1.0.tcl` can do the {{{[variant_exists qt5kde] && [variant_isset
 qt5kde]}}} check (line 358 under the "Qt is provided by" debug output),
 but shouldn't need to do any more checking. The condition should never be
 true at that point, simply.
 The {{{[variant_exists qt5kde] && [variant_isset qt5kde]}}} could
 ''optionally'' be used to decide to transfer control to `qt5-kde-1.0.tcl`
 in the PortGroup preamble IFF we decide that users should be able to
 control it. I am not convinced there's any advantage to that, and in my
 current approach this condition is supposed to be true only in and after
 including that PortGroup file completely.

 '''¡ Fixing these two issues also means you don't need to redefine the
 `eval_variants` function from "base" ! '''

 Please fix these issues ASAP so we can move on. There should be no
 incidence on any currently installed ports and it will reduce PortGroup
 complexity a little bit.

--
Ticket URL: <https://trac.macports.org/ticket/53777>
MacPorts <https://www.macports.org/>
Ports system for macOS