[MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac
MacPorts
noreply at macports.org
Sat Oct 3 02:00:48 PDT 2015
#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
More information about the macports-tickets
mailing list