#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