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

MacPorts noreply at macports.org
Sat Oct 3 04:56:05 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@…):

 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


More information about the macports-tickets mailing list