[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