#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@…): Replying to [comment:62 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).

I would expect that a lot of other ports would have to be fixed to continue working with the new Qt4 structure.

The vast majority of the ones I've installed simply rebuild because 1) they use the Qt4 portgroup and 2) my layout changes are so minimal.

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?

Something I proposed for the Qt5 port and that got no traction at all. Besides, if ever we do end up with qt*-kde ports there'd actually be a reason for the -mac suffix ...

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.

No. I've taken care that installing qt5-kde does not get you into conflict with binary packages built against qt5-mac. The other way around is less sure, but can be protected the same way. If you prefer the kde structure, you'll just end up using that structure for all Qt dependents, and I think it'll be possible to get binary packages for at least some of those (the ones conceived to be used with the kde structure in any case).

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.

Which still boils down to the same thing, at least if I understand correctly that those ports do not yet have (published) Qt5 variants/subports.

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.

Has been the case for months: https://github.com/RJVB/macstrop/tree/master/aqua ...

...

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?

I do not have time to answer that in detail right now. The quick answer is that I initially used an all-encompassing prefix for Qt4 too when I set out to make qt4-mac concurrent. I remember running into issues, didn't record exactly what, but in retrospect those issues were evidently related to the prefix approach. Basically I consider that MacPorts contains many ports that were conceived for a Freedesktop/XDG environment (including all KDE4 ports), and that as a result we'd do better to stick to something as close to that kind of layout as possible. Which was the case for the "exclusive" qt4-mac layout. Gotta run... -- Ticket URL: <https://trac.macports.org/ticket/44193#comment:63> MacPorts <https://www.macports.org/> Ports system for OS X