#44193: qt: allow side by side installation of qt4-mac and qt5-mac -------------------------------+------------------------ Reporter: mojca@… | Owner: mcalhoun@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: qt4-mac, qt5-mac | -------------------------------+------------------------ Comment (by rjvbertin@…): Thank you Mojca (I guess :)) I've been typing this reaction over the course of breakfast (and "helped" by a couple of cats in need of attention :)) so it may not be as well structured as it could. First off, existing users can be warned not to upgrade to 10.11, but I guess you also have newcomers in mind (who'd have to be told to wait until compatibility issues are fixed). port:qt5-mac has already been made concurrent, so it would only require a patch if the commit Michael has mentioned has not made it to any released version. It would certainly surprise me if it hadn't made it into 5.5.0 (released not more than a few weeks ago), and that version is already available in the port:qt5-kde I submitted. Now to debunk a few misconceptions: the *-mac and proposed *-kde versions are not co-installable, so there is no *extra* disk space or processor time required. One advantage in my packaging: I don't build all of Qt5 in the main port, but moved the biggest hog (QtWebEngine, a new component in 5.4 and still little used) to a subport. And a hog it is. There aren't many qt5 dependent ports ATM, but those I tried build and work just fine against port:qt5-kde . Sadly the *-mac and *-kde versions are not binary drop-in replacements but require a rebuild of all dependent packages. * I could however add a variant like the "transitional" variant in my qt4-mac proposals, which puts up symlinks so that existing dependents continue to find the stuff they need under libexec/qt5-mac. I won't have much time for that this weekend, and would need someone to help testing in any case. About the install layout/directory structure: I've seen it argued that just putting everything into a single directory is how Digia do it with their own installers, on OS X. True, but the use case they envision is developers who build standalone app bundles that can be submitted to the App Store. That's not the reason for which MacPorts contains Qt, I think. There are Qt ports so there can be any number of other ports to depend on the appropriate Qt version. Most of those dependents probably come from other Unix desktops where Qt does not install in a single directory. In short, even if it's the easiest way to achieve Qt concurrency on the short term, it is IMHO *NOT* the appropriate way for something like MacPorts. And in fact (and again, IMHO) it is just as easy to change only the locations that require changing, esp. since just about all configurable install locations are already specified through dedicated variables in the PortGroup. Not everyone may know this but yes, Qt's `configure` script has options for a whole slew of installation locations, and I think we use about all of them. Final note: with the install layout I use I get: {{{

qmake-qt5 -query INCLUDEPATH:/opt/local/include INCPATH:/opt/local/include --> QMAKE_LIBDIR:/opt/local/lib QT_SYSROOT: --> QT_INSTALL_PREFIX:/opt/local QT_INSTALL_ARCHDATA:/opt/local/libexec/qt5 QT_INSTALL_DATA:/opt/local/share/qt5 QT_INSTALL_DOCS:/opt/local/share/doc/qt5 QT_INSTALL_HEADERS:/opt/local/include/qt5 QT_INSTALL_LIBS:/opt/local/libexec/qt5/Library/Frameworks QT_INSTALL_LIBEXECS:/opt/local/libexec/qt5/libexec QT_INSTALL_BINS:/opt/local/libexec/qt5/bin QT_INSTALL_TESTS:/opt/local/share/qt5/tests QT_INSTALL_PLUGINS:/opt/local/share/qt5/plugins QT_INSTALL_IMPORTS:/opt/local/share/qt5/imports QT_INSTALL_QML:/opt/local/share/qt5/qml QT_INSTALL_TRANSLATIONS:/opt/local/share/qt5/translations QT_INSTALL_CONFIGURATION:/opt/local/etc/qt5 QT_INSTALL_EXAMPLES:/Applications/MacPorts/Qt5/examples QT_INSTALL_DEMOS:/Applications/MacPorts/Qt5/examples --> QT_HOST_PREFIX:/opt/local QT_HOST_DATA:/opt/local/share/qt5 QT_HOST_BINS:/opt/local/libexec/qt5/bin QT_HOST_LIBS:/opt/local/libexec/qt5/Library/Frameworks QMAKE_SPEC:macx-clang QMAKE_XSPEC:macx-clang QMAKE_VERSION:3.0 QT_VERSION:5.5.0 }}}

I highlighted some that will point to ${prefix}/libexec/${qt_dir} when using an approach as used by the current port:qt5-mac . It seems evident that the values above are to be preferred in a context like MacPorts'. Qt4 qmake is less expressive, and it looks like I'll want to double-check QT_INSTALL_PREFIX: {{{

qmake-qt4 -query QT_INSTALL_PREFIX:/opt/local/libexec/qt4 QT_INSTALL_DATA:/opt/local/share/qt4 QT_INSTALL_DOCS:/opt/local/share/doc/qt4 QT_INSTALL_HEADERS:/opt/local/include/qt4 QT_INSTALL_LIBS:/opt/local/libexec/qt4/lib QT_INSTALL_FRAMEWORKS:/opt/local/libexec/qt4/Library/Frameworks QT_INSTALL_BINS:/opt/local/libexec/qt4/bin QT_INSTALL_PLUGINS:/opt/local/share/qt4/plugins QT_INSTALL_IMPORTS:/opt/local/share/qt4/imports QT_INSTALL_TRANSLATIONS:/opt/local/share/qt4/translations QT_INSTALL_CONFIGURATION:/opt/local/etc/qt4 QT_INSTALL_EXAMPLES:/Applications/MacPorts/Qt4/examples QT_INSTALL_DEMOS:/Applications/MacPorts/Qt4/demos QMAKE_MKSPECS:/opt/local/share/qt4/mkspecs QMAKE_VERSION:2.01a QT_VERSION:4.8.7 }}}

Side-note: I've submitted a few scripts the other day that I find very useful when doing incremental (re)builds of ports. As to Qt4 : here the issue is much simpler really, partly also because building Qt4 is incomparable to Qt5. On my 4yo 2.7Ghz i7 (2*2 cores) with 12Gb and a HDD, I'd say it takes about 2h (using a stiff nice value) when I'm doing other light stuff. More with LTO of course, but still fully acceptable. And of course, clever use of -n, -o and -k helps speed up rebuilds tremendously. Once again, the Qt4 port I attached here is set up so it can serve as a drop-in replacement for the current, "exclusive" port:qt4-mac. Full drop- in compatibility requires installing the transitional subport which caters to existing, non-rebuilt dependents. It's a little bit tricky to install when automatic rev-upgrade is allowed to rebuild ports, but once in place, anyone can do all the testing s/he requires. Rebuilding dependents one by one and of course including modifying the Portfile and rebuilding the port.[[BR]] NB: rebuilding a dependent even *with* the transitional subport in place removes the need for the subport for the rebuilt dependent (because the linker stores resolved paths in the rpath, not the symlinks). And of course if you prefer to bite the bullet: there's no obligation to use the transitional subport. * I cannot imagine an "easier" way to approach the problem at hand (surely there's a reason it's been put off for so long). If there weren't the fact that the offered solution has been tested since January (using KDE4 and pure Qt dependents) even I might think I'd prefer to just do it myself (when in Michael's shoes). But with that testing, and given the minimal changes to the tried-and-true install layout I'd realise soon enough that I'd be foolish to want to reinvent the wheel without as much as trying the proposed solution (esp. since I surely left the port `openmaintainer` because I never intended to be the sole Qt saviour in the MacPorts universe ;)). We all realise there are ''lots'' of Qt4 dependents. The KDE4 ports have already been handled through some minor changes to the KDE4 PortGroup (but even I cannot claim I've test-built all of them). But that still leaves plenty of candidates that might not be well-educated (declare their Qt4 dependency throught the Qt4 PortGroup, and use its variables instead of hard-coded paths). I have tackled those I came across. I am 90% certain that I filed tickets for those, and maybe I'll get around to checking some more this weekend (all I need to do is deactivate the transitional subport to see which ports require rebuilding). * But there must be more. I don't think they're going to be a challenge, just monks' work to get right. * In fact, I'd see this as an argument just to commit qt4-mac-devel. It won't be installed automatically on any user machines, but devs like us can chose it deliberately over qt4-mac . Thanks to rev-upgrade a rebuild will be triggered of all installed dependents if the transitional variant is not installed. With a few devs doing this the problem ports will be identified soon enough. [[BR]] Whatever happens after that period of getting kinks out of cables is something that can be decided without time pressure (and who knows, maybe you'll get me to admit I was wrong here or there `O:^)` ). -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:60> MacPorts <https://www.macports.org/> Ports system for OS X