Qt5 PortGroup : wrong use of qt5.using_kde and +qt5kde

[RJVB (René Bertin)]

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, theqt5.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.

[RJVB (René Bertin)]

possible patch

[Marcus Calhoun-Lopez <marcuscalhounlopez@…>]

In b55e21164126d3144b8e9a405f61c822c101b5c9/macports-ports:

qt5 PG: change name qt5.using_kde->qt5.kde_variant

See #53777

[RJVB (René Bertin)]

And how does this address my comments above?!

Why the F* does this have to be so difficult, is it really your intention to make it impossible for me to ensure that port:qt5-kde can act as a drop-in replacement for the regular Qt5 ports?!

SEVEN months have passed since I raised the above issues which were themselves due already to not following my propositions without any form of discussion. In the meantime Marko seems to have gone MIA along the way (so it looks my KF5 ports will have to remain just that, mine).

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Replying to RJVB:

Why the F••• does this have to be so difficult, is it really your intention to make it impossible for me to ensure that port:qt5-kde can act as a drop-in replacement for the regular Qt5 ports?!

After taking some time to better understand ​qt5-kde and ​qt5-kde PG, I believe you perceive difficulty because there is a fundamental difference of opinion of what constitutes a ​drop-in replacement.
Just as a simple example, qt5-kde and qt5-qtbase install their header files in ​different ​locations.
Perhaps KDE requires this design choice, but it means that qt5-kde is not a drop-in replacement.

Is qt5-kde to be drop-in replacement in the strict sense (same library names, same header names, same layout, etc.)?
If so, then we already have the infrastructure to proceed.
If not, then there is no reason to jump through so many hoops trying to convince Portfiles that it is.
Confusion on this fundamental question has led to countless delays and, apparently, a fair bit of frustration.

[RJVB (René Bertin)]

No, I've made it perfectly clear that the layout isn't identical. The binaries that have to be in the same location are (those loaded by dyld.so and not at runtime). Evidently the names of the headers are the same too.

so many hoops?

Yeah, you have been introducing unnecessary complications in your PortGroup(s), and splitting port:qt5 up in port:qt5-qtbase etc. hasn't exactly made things easier either. I have been thinking A LOT about how to make this "almost perfect drop-in replacement" thing work transparently. It's not very difficult, but it *is* a bit delicate and not something to second-guess without understanding the entire context as well as I do. I don't have commit access, otherwise I would have made the modifications myself.

We've already tackled the qt5.depends_component macro. The remaining magic to be put in the PortGroups is all thought out on my end and as far are you PGs are concerned it consists only of transferring control to mine when that's necessary. That transfer should be as early in the file as possible. 7 months is long ago enough that I don't remember the exact details of my reasoning. Without diving into those details anew I'd say that there should be no need for you to declare the qt5kde variant or the corresponding variable and use it. Simply because the corresponding parts of your PortGroups ought never be executed when qt5-kde is (to be) installed. A simple check just after the transfer should be enough to catch any unforeseen situations.

trying to convince Portfiles that it is.

That's indeed a possible point of confusion. There are 2 aspects

1. binary compatibility
2. build compatibility

Point 1 takes place mostly in port file qt5-kde with support code in the PGs like qt5.depends_component and the +qt5kde variant. The function does most of the work (ensuring the correct depspecs are used), the variant is mostly there so that a port:foo-qt5 built against port:qt5-kde is not identical to the same port built against port:qt5-qtbase according to the reproducible build rules. It records the fact that we're dealing with a build variant.

Point 2 is completely handled in the PGs, and is based on qt5.depends_component and the fact that dedicated PGs are used. That latter part is hidden from dependent ports, evidently, they can continue to do PortGroup qt5 1.0 as always.

My initial idea had been to make qt5-1.0.tcl a simple entry point which includes either your PG or mine and contains some shared code like qt5.depends_component. That's undoubtedly why even my version of that function still checks qt5.using_kde. Putting the shared code in there is optional of course but even without this approach would still oblige you to change your habits (use a different PG name). Hence my current idea of providing you with a patch that triggers the transfer to qt5-kde-1.0.tcl when needed (idem for the qmake5 PG), code that you shouldn't need to touch once it has been put in place.

What makes this more complicated is the fact that we use the same PG for building Qt and for building dependent ports. We have to ensure that users can still build port:qt5-qtbase when port:qt5-kde is installed and active, for instance. But I don't really see how to get around that without ending up with lots more PortGroup files.

[mascguy (Christopher Nielsen)]

Add keyword portgroup, to pg-related tickets