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

MacPorts noreply at macports.org
Sat Jun 13 14:03:38 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:37 mcalhoun@…]:

 > - Calling the directory qt5-mac might have been unnecessary. It is just

 More a matter of principle and consistency. The port itself could have
 been called `qt5`, and probably should have.

 > - The configure script uses PulseAudio if it is found (hence the
 dependency). It is possible to force the script not to look for it, but I
 tried to stay close to default behavior.

 Well, the default behaviour is not to install PA and then use it if it's
 found... The logic behind the default behaviour is undoubtedly not to
 oblige people to enable the PA support on systems where PA is used and a
 usual alternative to ALSA (i.e. Linux). The default on OS X would be that
 PA isn't found, and thus support not built in. It's only MacPorts that
 imposes to make a choice, but I continue to think the logical choice here
 would be to hard-code that effective default. For multiple reasons in
 addition to the fact that using PulseAudio doesn't make sense for
 applications and middleware that already know how to use CoreAudio :
 - PA causes a non-negligible number of dependencies to be pulled in,
 including part of gnome
 - I don't think that the PA port does anything to ensure the PA daemon is
 started on login
 - I'm not convinced at all that Qt applications will use PA even when the
 daemon is running. In fact, the only use of PA from Qt apps I've seen to
 date are through Phonon and the phonon-gstreamer backend.

 > - Similarly, qml-debug is used because it is the default behavior.

 What's the point in hard-coding default options if they don't have
 implications w.r.t. dependencies? It only increases the workload at each
 upgrade, having to check which options have changed defaults. I don't know
 how generally useful this option is, however, nor what overhead it

Ticket URL: <https://trac.macports.org/ticket/44193#comment:38>
MacPorts <https://www.macports.org/>
Ports system for OS X

More information about the macports-tickets mailing list