[MacPorts] #44193: qt: allow side by side installation of qt4-mac and qt5-mac

[MacPorts]

#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