#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 mojca@…): Replying to [comment:60 rjvbertin@…]:
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).
When I talked about upgrading, I meant upgrading packages on MacPorts. I'm almost sure that once we move Qt4 away from the default location there will be just a zillion of ports broken (disclaimer: that might not be the case with that "transitional" solution perhaps). Some might be fixed automagically be revbumping them, but I would expect that a lot of other ports would have to be fixed to continue working with the new Qt4 structure. A single Qt4/5 maintainer simply cannot fix all the ports, no matter what. (When I change the packaging of wxWidgets, it probably took me 2 weeks almost full time to sort everything out. And even then I managed to hurt some maintainers who thought that I simply made too heavy changes to their ports when I tried to make them compatible with 3.0.) So I expect a large number of ports to be broken after Qt4 gets updated. But developers won't fix their ports until a new version of qt4-mac comes out, ideally one that comes as a binary package. (Not upgrading to 10.11 is not the answer for everyone. And people who do upgrade right away need to be aware of potential problems with a bunch of software. That has always been the case with early adopters.) Btw: if we are moving the complete structure anyway, what about renaming the new port simply to `qt4`? Now that x11 is hardly support (and probably not needed), there is no way to keep calling that port `"mac"`. That way we could keep the old `qt4-mac` in place for a while (and ports that won't be upgraded yet might conditionally keep working), while urging everyone to switch to the new `qt4` asap and update the ports to use qt4 instead of qt4-mac?
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.
Which is even worse. Because then I have no option to link, say, gnuplot against qt5-kde if I happen to like the kde structure more. Becasue that will make gnuplot conflict with just about every other Qt-based package in MacPorts.
There aren't many qt5 dependent ports ATM
I maintain a bunch of Qt-based ports that all work with Qt5, but I cannot afford to keep and test compatibility against Qt5 or get rid of Qt4 completely as long as qt5-mac is conflicting with qt4-mac.
* 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.
May I perhaps suggest you to put your files to a place like GitHub or any other public service, so that it becomes slightly easier to track your changes for those who might be interested? Uploading zips to trac starts getting cumbersome at some point, particularly with the amount of changes that you need to make.
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.
Quick question: do I understand it properly that some of your ports (mostly those based on KDE) do not even work if one installs the complete Qt into a single directory like libexec? If that is the case, we might have a strong argument to try to keep the directories spread out at their usual location. Or do both configurations (either a single directory or different directories) work with most ports?
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.
So if I understand properly, installing both ports (your new qt[45]-mac) as well as the transitional subport will make sure that all the ports that haven't been fixed and/or rebuilt yet will happily keep working? And the transitional subport will only be a problem when building other ports against qt5? If that is so, the transition might be a lot less painful than what I imagined.
* 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]]
Potentially the qt4-mac-devel could be called qt4? -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:62> MacPorts <https://www.macports.org/> Ports system for OS X