Opened 8 years ago
Last modified 2 years ago
#53777 new defect
Qt5 PortGroup : wrong use of qt5.using_kde and +qt5kde
Reported by: | RJVB (René Bertin) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | portgroup | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), mkae (Marko Käning), mojca (Mojca Miklavec) |
Port: | qt5 |
Description
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:
- They can set
qt5.prefer_kde
BEFORE they include the standard PortGroup; in that case they getport:qt5-kde
if and only no Qt5 port is installed yet. - 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 standardport: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.
Attachments (1)
Change History (6)
Changed 8 years ago by RJVB (René Bertin)
Attachment: | qt5-1.0.diff added |
---|
comment:1 Changed 7 years ago by Marcus Calhoun-Lopez <marcuscalhounlopez@…>
comment:2 follow-up: 3 Changed 7 years ago by 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).
comment:3 Changed 7 years ago by 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.
comment:4 Changed 7 years ago by 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
- binary compatibility
- 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.
comment:5 Changed 2 years ago by mascguy (Christopher Nielsen)
Keywords: | portgroup added |
---|
Add keyword portgroup, to pg-related tickets
possible patch