#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 mcalhoun@…): Just off the top of my head, there would seem to be four options: 1. Put both the Qts in their own private directories (as mentioned in comment:86:ticket:37331) * This is the default behavior (put everything in /usr/local/Qt-5.3.1 or /usr/local/Trolltech/Qt-4.8.6). * The binaries, cmake files, pkg-config files, and frameworks would be harder for scripts to find. * I believe qt4-mac used to do this prior to r72571. 1. Put one of the Qts in its own private directory for anyone who might need it and "bless!'' the other as the "official" supported version by putting it in ${prefix}. 1. Try to figure out a way to get both installed in ${prefix}. 1. Keep things the way they are and force users to choose. Options 1, 2, and 4 would be fairly easy to implement (4 would be the easiest).[[BR]] Personally, I only need one version, so I have no strong feelings one way or the other.[[BR]] Does anyone else have any thoughts? -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X

#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@…):

I'm sure that a lot of software doesn't work properly with Qt 5 yet.

There's also software that's Qt5 only (like the current QtCreator versions). It's not like Qt5 is just out and still looking for adopters ... Is there a reason why MacPorts wouldn't adopt the way Ubuntu (Debian) do things? They store Qt versions in their own prefix, but add qtchooser and qtN-default packages. The latter allows you to set up the symlinks needed to make a particular version the default, the latter links stuff through a chooser which has both a default and options to override that. For example: {{{ 390071 1 lrwxrwxrwx 1 root root 9 May 3 12:56 /usr/bin/qmake -> qtchooser* }}} I don't know how many Qt-related pkg-config scripts there are, but anything that goes through qmake will be able to find (and be found) automagically wherever Qt is installed. And nothing forbids ports from specifying a specific qmake command like qmake-qt4 (if `qmake -qt=4` is infeasible). -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X

#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 iandw.au@…): Just for information and not wishing to put on pressure, the KDE developers have started to ship KDE Frameworks 5, the new KDE libraries, which depend on Qt 5 (https://techbase.kde.org/Schedules/Frameworks). In December they are planning to release a mixed batch of KDE apps (i.e. no libraries), which has been dubbed KDE 14.12 (yes, year.month). Some of these apps will have been ported to use Frameworks and Qt 5 and some (perhaps most) will still be using KDE 4 libraries and Qt 4. The releases of KDE apps will be named by year and month from then on. No doubt the proportion of ported apps will grow over time, as it did with the KDE 3 to KDE 4 transition. Whatever happens, MacPorts will need to provide a mix of KDE 4, Qt 4, Frameworks 5 and Qt 5 for some time to come, with KDE apps building onto one dependency path or the other. The good news is that this change does not seem to be as "radical" as the KDE 3/4 change was, from the point of view of applications and API, but it will be quite a lot different in its build characteristics - hopefully a lot simpler once the changeover has been made. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:11> MacPorts <http://www.macports.org/> Ports system for OS X

#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 mk@…): Replying to [comment:13 rjvbertin@…]:

Wouldn't it actually be harder to get Qt5 to build for 10.6?

I see that you're able to build current KDE versions on 10.6 using gcc 4.8... Perhaps this offers the opportunity to also get qt5-mac build for 10.6? -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:14> MacPorts <http://www.macports.org/> Ports system for OS X

#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@…): I just discovered another potential option. When I tried to install Qt's own 5.3 binaries through their installer, this failed on the step that adapts the "rpath" information to the chosen install path (the shipped binaries have a very long ___PADDING___ string in their path, for that purpose. However, they depend on libstdc++, so I could install to the intended location on my 10.9 VM, and then copy that tree to the 10.6 host. Works a charm. Evidently I could have picked a location in /opt/local. I still haven't grasped what the QStandardPath issue is that Marko is working on, or if there are (other) modifications to the Qt source code to cater for use by MacPorts. But barring those, it seems MacPorts could host a binary package created on 10.7 or newer of an install to /opt/local/<whatever>/qt/5, with symlinks to the usual locations (and qtchooser to help have both 4 and 5 installed in parallel). -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:16> MacPorts <http://www.macports.org/> Ports system for OS X

#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 michaelld@…): The actual changes to make this happen should be pretty small: edit the qt portfiles and change the qtdir to something else that is unique to each Qt. That said: I think the greatest challenge in this ticket's implementation is the sheer number of ports that depend on Qt (4 or 5) that will have to be worked over to make sure they are doing the right thing. Once the qtdir has been committed, there will be lots of ports that work correctly "out of the box". But, there will also be -lots- of ports that misbehave: some will not use qtdir / QMAKE correctly & have to be told specifically what to do; others will need to be patched to get them working since they hard- wire were QMAKE is located (or, something like that). I think to do diligence on this, we need 2 or 3 of us devs willing to commit a week's time to fix issues once the primary commit is made, pretty much -just- fixing Qt issues. The next week, we can drop down to 2, then down to 1, and so forth. All in my opinion, of course; I'd love to be proven wrong! I'm all for having side-by-side Qt installations; I just don't have the time right now to put in to make it so. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:18> MacPorts <http://www.macports.org/> Ports system for OS X

#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 mk@…): Replying to [comment:19 rjvbertin@…]:

what's to keep us from having configuration files under ${prefix}/etc/xdg(/qtchooser/*.conf) ? There seem to be a few xdg/freedesktop related ports already, after all ...

Nothing really. It's perhaps just more platform-compliant to have all those configs in ~/Library/Application Support/ like KDE currently saves stuff in ~/Library/Application Support/KDE/ . For the OSX/CI system I am currently trying to avoid this still and stick to the XDG stuff, because that's what the CI scripts give me at the moment - although this is NOT recommended by David Faure in the mentioned K-F-D thread. W.r.t to standard paths check out [https://community.kde.org/Frameworks/Epics/StandardPathsMigration the KDE frameworks migration epics page]. -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:20> MacPorts <http://www.macports.org/> Ports system for OS X