[MacPorts] #51643: qt5 portgroup overwrites supported_archs, defines universal variant when one is not desired
#51643: qt5 portgroup overwrites supported_archs, defines universal variant when one is not desired --------------------------+------------------------ Reporter: ryandesign@… | Owner: mcalhoun@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: qt5 --------------------------+------------------------ I'm trying to update my QupZilla port to version 2. It now requires qt5 instead of qt4. It also now requires an x86_64 processor. Without using any portgroup, setting `supported_archs x86_64` in a portfile causes the universal variant to be disabled. That's what I want. But something different happens when using the qt5 portgroup: * If I set `supported_archs x86_64` before including the qmake5 portgroup, the qmake5 portgroup includes the qt5 portgroup which overwrites my `supported_archs` choice. * If I set `supported_archs x86_64` after including the qmake5 portgroup, the qmake5 portgroup includes the qt5 portgroup which includes the muniversal portgroup which defines a universal variant. It looks like the only way to make a working portfile with the way the qt5 portgroup is written today is to set `universal_variant no` before including the qmake5 portgroup and to set `supported_archs x86_64` after including the qmake5 portgroup. That's inelegant. It would be simple enough to modify the portgroup to set a ''default'' for `supported_archs` but not overwrite a value if the port already set one. Ideally, the portfile author should be able to specify `supported_archs` or `universal_variant no` later in the portfile, as is customary, but I'm not sure how the portgroup would then be able to set up the universal variant correctly for those ports that need it. The app portgroup handles a similar situation (whether or not to add the makeicns dependency) using variable traces. That's a bit messy, but I can't think of another way to handle it. -- Ticket URL: <https://trac.macports.org/ticket/51643> MacPorts <https://www.macports.org/> Ports system for OS X
#51643: qt5 portgroup overwrites supported_archs, defines universal variant when one is not desired ---------------------------+------------------------ Reporter: ryandesign@… | Owner: mcalhoun@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: qt5 | ---------------------------+------------------------ Changes (by mcalhoun@…): * status: new => assigned Comment: I have not tested this thoroughly, but how about something like this:[[BR]] In qt5-1.0.tcl, replace {{{ # no universal binary support in Qt 5 # see http://lists.qt- project.org/pipermail/interest/2012-December/005038.html # and https://bugreports.qt.io/browse/QTBUG-24952 supported_archs i386 x86_64 if { ![exists universal_variant] || [option universal_variant] } { PortGroup muniversal 1.0 universal_archs_supported i386 x86_64 } }}} with {{{ # no universal binary support in Qt 5 # see http://lists.qt- project.org/pipermail/interest/2012-December/005038.html # and https://bugreports.qt.io/browse/QTBUG-24952 default supported_archs {"i386 x86_64"} # override universal_setup found in portutil.tcl so it uses muniversal PortGroup # see #51643 proc universal_setup {args} { if {[variant_exists universal]} { ui_debug "universal variant already exists, so not adding the default one" } elseif {[exists universal_variant] && ![option universal_variant]} { ui_debug "universal_variant is false, so not adding the default universal variant" } elseif {[exists use_xmkmf] && [option use_xmkmf]} { ui_debug "using xmkmf, so not adding the default universal variant" } elseif {![exists os.universal_supported] || ![option os.universal_supported]} { ui_debug "OS doesn't support universal builds, so not adding the default universal variant" } elseif {[llength [option supported_archs]] == 1} { ui_debug "only one arch supported, so not adding the default universal variant" } else { ui_debug "adding universal variant via PortGroup muniversal" uplevel "PortGroup muniversal 1.0" uplevel "default universal_archs_supported {\"i386 x86_64\"}" } } }}} -- Ticket URL: <https://trac.macports.org/ticket/51643#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X
#51643: qt5 portgroup overwrites supported_archs, defines universal variant when one is not desired ---------------------------+------------------------ Reporter: ryandesign@… | Owner: mcalhoun@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: qt5 | ---------------------------+------------------------ Comment (by rjvbertin@…): Has anyone tested the muniversal build lately, or a 32bit build? Last time I did was with Qt 5.4.1 . Is there a point in checking the xmkmf option? That's an (old) make file generator for X11 applications, I doubt we'll encounter it with Qt5 software... -- Ticket URL: <https://trac.macports.org/ticket/51643#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X
#51643: qt5 portgroup overwrites supported_archs, defines universal variant when one is not desired ---------------------------+------------------------ Reporter: ryandesign@… | Owner: mcalhoun@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: qt5 | ---------------------------+------------------------ Comment (by rjvbertin@…):
qt5 portgroup which includes the muniversal portgroup which defines a universal variant.
This is always the case because a universal Qt5 build can only be generated that way. Should one avoid loading it multiple times? Regardless of that, wouldn't it be simpler just to check `supported_archs` for the presence of archs other than i386 or x86_64 and raise an error in that case? -- Ticket URL: <https://trac.macports.org/ticket/51643#comment:4> MacPorts <https://www.macports.org/> Ports system for OS X
#51643: qt5 portgroup overwrites supported_archs, defines universal variant when one is not desired ---------------------------+------------------------ Reporter: ryandesign@… | Owner: mcalhoun@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: qt5 | ---------------------------+------------------------ Comment (by ryandesign@…): Replying to [comment:4 rjvbertin@…]:
qt5 portgroup which includes the muniversal portgroup which defines a universal variant.
This is always the case because a universal Qt5 build can only be generated that way.
I understand that. The problem is when the qt5 portgroup includes the muniversal portgroup and thus defines a universal variant for a port like qupzilla 2 which only builds for a single architecture -- x86_64 -- and thus should not have a universal variant. It's customary to include portgroups at the top of the portfile, right after the portsystem line. supported_archs, if set at all, would typically be set later. But this is a problem for the qt5 portgroup which wants to include the muniversal portgroup if a universal build is going to happen. How can the qt5 portgroup know, at the time that it has been included, whether the portfile will later set supported_archs to a single value, or set universal_variant to no? And therefore how can the qt5 portgroup know whether or not it should include the muniversal portgroup? I don't know.
Regardless of that, wouldn't it be simpler just to check `supported_archs` for the presence of archs other than i386 or x86_64 and raise an error in that case?
I think that's an orthogonal issue, unrelated to this ticket. -- Ticket URL: <https://trac.macports.org/ticket/51643#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X
#51643: qt5 portgroup overwrites supported_archs, defines universal variant when one is not desired ---------------------------+------------------------ Reporter: ryandesign@… | Owner: mcalhoun@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: qt5 | ---------------------------+------------------------ Comment (by rjvbertin@…): Replying to [comment:5 ryandesign@…]:
The problem is when the qt5 portgroup includes the muniversal portgroup and thus defines a universal variant for a port like qupzilla 2 which only builds for a single architecture -- x86_64 -- and thus should not have a universal variant. And therefore how can the qt5 portgroup know whether or not it should include the muniversal portgroup? I don't know.
I guess there's only one way to come up with an answer to that: determine if Qt *applications* require the muniversal PG for them to be built. A quick test with qmake and cmake shows that once you manage to get `-arch i386 -arch x8_64` into the C(XX)FLAGS straightforward universal binary builds work. That is, I get the expected universal binary .o files, and errors from the linker when it finds out that my Qt frameworks aren't universal. If this is confirmed for more than the very simple applications I tested the `muniversal` inclusion can go into the Qt Portfile itself. Even if it isn't confirmed, is there a way for the Qt PortGroup to oblige Portfiles to include `muniversal` if they want to support binary builds? I.e. can the Qt5 PortGroup remove the universal variant? It seems that the universal variant is available normally when one sets `universal_variant no` in the PortGroup, and then includes `muniversal` in a Portfile that wants to provide universal variants. If you can confirm that is how things are supposed to work then it seems the best solution yet. It would avoid the question how well the cmake PortGroup handles +universal, and even less more you'd get qmake to do universal builds.
check `supported_archs` for the presence of archs other than i386 or
x86_64 and raise an error in that case?
I think that's an orthogonal issue, unrelated to this ticket.
Probably, knowing now that your use case is x86_64 only. -- Ticket URL: <https://trac.macports.org/ticket/51643#comment:6> MacPorts <https://www.macports.org/> Ports system for OS X
#51643: qt5 portgroup overwrites supported_archs, defines universal variant when one is not desired ---------------------------+------------------------ Reporter: ryandesign@… | Owner: mcalhoun@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: qt5 | ---------------------------+------------------------ Comment (by rjvbertin@…): I asked about "automatic universal builds" on the Qt ML, got this reply from Thiago Macieira:
We had deprecated that feature but brought it back with the iOS support and for the other Apple OSes (simulators, etc.).
So it probably works, if you lipo the Qt frameworks first.
So I'd propose the simple solution. Don't include `muniversal` and possibly set `universal_variant no` in the Qt5 PortGroup but in the Qt5 Portfile. Ports depending on Qt5 can include muniversal if they need +universal and the standard variant doesn't work for them. -- Ticket URL: <https://trac.macports.org/ticket/51643#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts