[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 rjvbertin@…):

 Replying to [comment:68 michaelld@…]:

 > * When we get QtChooser and/or qt*-kde implemented, we'll need some of
 these in place; until then, I think we can leave them alone.

 "These" being what, here?

 > * Moving sqlite3 back to the main qt4-mac makes sense too, because
 otherwise Assistant fails to execute; either that or moving Assistant to a
 separate port that depends on the sqlite3 plugin; much easier to do the
 former.

 Indeed; much easier, and a *lot* faster.

 > * I don't know enough about "-no-exceptions" to comment. Can you provide
 a link that shows that this is the default for Qt-provided binaries? I'm
 happy to go that way with a variant if it's the usual. At least on Qt4,
 when I do "./configure --help" I see that "-exceptions" is the default;
 that's why it is enabled by default.

 No, I never said it's the default for Qt-provided binaries. With the
 change I propose Qt4 builds as Qt5 does, without using exceptions
 internally (except for a few ... exceptions like QtConcurrent) and without
 support for exceptions enabled in the compiler. That is in fact what we're
 talking about. As I said in my previous comment, Qt's configure `-no-
 exceptions` has effect also on how dependent software is built, but my
 implementation removes that. With some luck I'll be able to trace the
 exchange with Thiago in the archives of the interest Qt ML, but that's
 going to be the only link I can provide.
 I myself used a variant (first optional, then default) before finally
 realising that everything just works, and making the `-exceptions` build
 under control of a variant.

 > * No matter the proper way to do a parallel build, MP's way works, yes?
 If so, I'll leave that as is.

 What do you call the MP way, by setting build.jobs? That does NOT work,
 which is the reason for setting MAKEFLAGS. If you look at the `configure`
 script, qmake is built by invoking `make` without any options at all. I
 initially patched the configure script, but after asking on the interest
 ML I was told that "you just have to use `MAKEFLAGS=-jn` ...

 > * I think setting "qt_name qt4" is fine. Reads nicely in directory
 listings too. That's what I use for my internal testing, too.

 Yes, much as I think that we should simply maintain the qt4-mac port name,
 I would hate to see that in the directory structure. Too big, and there is
 an additional argument against it in the case of Qt5 which I won't repeat
 here ;)

 > * my worry about moving data, plugins, and other stuff into
 ${prefix}/share/qt4 is if/when there is qt4-kde or qt4-x11 that provides
 its own versions of these.

 No, I don't think so. I'm not 100% certain about the plugins of a qt4-x11
 build, but qt4-kde will install the exact same things in the shared
 resource directories as qt4-mac does.

 > A well-written project will use the specified QMAKE to glean the
 location of these, so they really don't matter.

 The issues I had were not with building. They were runtime issues that
 IIRC would have required patching the affected dependent ports.

 Of course, if you have no objections against a qt4-kde port then all we
 need to agree upon is how to set up the PortGroup(s) so that users can
 decide to install either the qt4-mac or qt4-kde flavour (but not both,
 IMHO) and at most be obliged to support installing from source those ports
 that do not specifically request the installed Qt4 flavour. You may have
 seen that I have a draft implementation for Qt5 (converting the Qt5
 PortGroup into a "header" that loads either the Qt5-mac or the Qt5-kde
 PortGroup).

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