[MacPorts] #48088: proposed improvements to port:qt5-mac

[MacPorts]

#48088: proposed improvements to port:qt5-mac
--------------------------+--------------------------------
  Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
      Type:  enhancement  |     Status:  new
  Priority:  Normal       |  Milestone:
 Component:  ports        |    Version:
Resolution:               |   Keywords:
      Port:  qt5-mac      |
--------------------------+--------------------------------

Comment (by rjvbertin@…):

 Replying to [comment:3 mcalhoun@…]:

 > = Easy Fixes and Changes (if necessary) =
 > Whitespace changes, rewording comments, and changing code order for
 !''better readability!'':[[BR]]
 > We can probably worry about these later. Right now, they just makes
 finding important changes harder.

 Yes we can and should - I've just left them in because they evolved over
 time, in large part because of other changes that I have not yet discussed
 here (but that are visible on the repo I linked to).

 > Renaming port to qt5:[[BR]]
 > The name qt5-mac may not have been the optimal choice, but is it really
 a problem?[[BR]]
 > What is wrong with
 > {{{ support qt5-x11 {...} }}}
 > in the Portfile if one so desires?[[BR]]
 > Like the whitespace changes, I am trying to discern high priority
 problems from low priority.

 I think I more or less said the same thing. I'm not even sure I find it
 extremely necessary myself.

 > "[T]he docs subport should be renamed such that it comes last during an
 `upgrade outdated`":[[BR]]
 > Is this a personal preference, or is there a problem?

 No, it's not a preference, because it makes the port name less obvious. I
 just noticed an issue if you don't do this when you have multiple Qt5
 subports installed, with the generated docs picking up parts of the
 previous version. That sounds weird and I'm not sure anymore that I
 understood the situation correctly, but I think that the doc generation
 picks up things from the install locations rather than using only the work
 source/build directories.

 > "use the code below ">>>..." instead of this block, which fails to
 populate qt_includes_dir completely.":[[BR]]
 > Which header code is not properly installed?

 When I looked in the include directory after doing a destroot of the
 current published qt5-mac port (v. 5.4.1), I saw only a subset of what I
 find in my include directory. I didn't write down the exact list, but
 here's what I have in ${prefix}/include/qt5:

 {{{
 %> lc /opt/local/include/qt5
 total 320
 0 ./                    8 QtDesignerComponents@ 8 QtOpenGL@             8
 QtQuickWidgets@       8 QtWebKit@
 0 ../                   8 QtGui@                0 QtOpenGLExtensions/   8
 QtScript@             8 QtWebKitWidgets@
 8 Enginio@              8 QtHelp@               0 QtPlatformHeaders/    8
 QtScriptTools@        8 QtWebSockets@
 8 QtBluetooth@          8 QtLocation@           0 QtPlatformSupport/    8
 QtSensors@            8 QtWidgets@
 8 QtCLucene@            8 QtMacExtras@          8 QtPositioning@        8
 QtSerialPort@         8 QtXml@
 8 QtConcurrent@         8 QtMultimedia@         8 QtPrintSupport@       8
 QtSql@                8 QtXmlPatterns@
 8 QtCore@               8 QtMultimediaQuick_p@  8 QtQml@                8
 QtSvg@
 8 QtDBus@               8 QtMultimediaWidgets@  8 QtQuick@              8
 QtTest@
 8 QtDeclarative@        8 QtNetwork@            8 QtQuickParticles@     0
 QtUiTools/
 8 QtDesigner@           8 QtNfc@                8 QtQuickTest@          8
 QtWebChannel@
 }}}

 >
 > "what's the point in not optimising qmake?":[[BR]]
 > {{{-no-optimized-qmake}}} is the default behavior.[[BR]]
 True, and I never understood that; qmake is not an application users are
 likely to need to debug for instance. I remember from my PPC machines that
 qmake was slow as molasses unless built with optimisation (C++ tends to
 behave like that).

 > Changing {{{qt-project.org }}} to {{{qt.io}}} should definitely be
 done.[[BR]]
 > Putting {{{reinplace ...}}} into a {{{post-patch}}} should be done
 (definitely a bug, although not one that has surfaced yet).

 It probably wasn't triggered by your choices for the install locations.

 > "[T]he sqlite3 plugin ("sqlite") should  be re-absorbed into the main
 port":[[BR]]
 > Forgive me, but I am having a little difficulty understanding the
 concern.[[BR]]
 > What is wrong with
 > {{{depends_lib-append port:qt5-mac-sqlite3-plugin}}}
 > if the plugin is necessary?[[BR]]
 > Why would "moving the applications in question to their own port" be
 required?[[BR]]

 The applications I refer to are installed by the qt5 port itself, so
 adding a dependency on `port:qt5-mac-sqlite3-plugin` would mean
 introducing a circular dependency. The most obvious example is the
 Assistant, which happens to be the 1st application I always launch to see
 if a Qt install went OK.
 On a more general note, this plugin is tiny, and is required by many
 dependents, contrary to the other related plugins. That alone is
 sufficient reason for me to include it. I've never checked, but aren't
 they all built by default as suggested by the fact they have to disabled
 in the Portfile?

 > If few people or ports need pulseaudio support, it is probably best to
 create a variant.

 Yes, and that could wait until there's demand for such a variant. Qt4 has
 been doing fine without it, apparently.

 On a related note: is there reason not to provide a way to build without
 harfbuzz support? My own port has harfbuzz in a variant.

 >     * If you download and install Qt, it all goes in one place, which
 means that it is probably better supported

 That is true for Mac and MS Windows, but the intended use on those
 platforms is quite different than the use in MacPorts. I really regret now
 that I didn't keep track of the true issues I ran into with Qt4 when I
 installed it that way, but I seem to remember that I had issues with KDE4.
 KDE is built around XDG FreeDesktop assumptions on where shared things are
 installed, and while we currently have only KDE4 in MacPorts, a number of
 KDE-Mac people are preparing KF5 (and I was planning to join that effort
 after getting my Qt5 port accepted...)
 It didn't take me long to realise (working on the qt4-mac port) that I
 sticking as closely as possible to the current scheme would make things a
 lot easier and was much less likely to lead to unforeseen issues.

 >     * Qt is a big piece of software and does not always like surprises
 (i.e. non-default behavior)

 To counter that: Qt4 isn't significantly less complex and has proved to
 work fine with the layout I'm proposing. The previous qt5-mac port (5.3.2)
 had a layout that was close to that one, and worked well enough too
 (except some issues due to omissions in the Portfile).

 >         * A simple example: without a patch, part of Qt assumes the
 library is {{{${qt_dir}/lib}}} no matter what the configure option
 {{{-libdir}}} is (see patch-shared.diff).

 Which may be one of the reasons that Michael and I populate that directory
 (${prefix}/libexec/qt5/lib in my case) with .dylibs that are symlinks to
 the actual framework binaries.

 >         * Another simple example: we have to clear the MacPorts
 variables (e.g. {{{configure.cflags}}}) to maintain consistency throughout
 the build.

 Do we? I've been removing part of those cleansings to get more
 acknowledgement of flags I pass in with configure.optflags, and I haven't
 noticed any adverse effects.
 Also, what's the relation with or relevance to the install locations?

 >         * From my own experience: Some time ago, QtCreator was regularly
 crashing. When I went back to the defaults, it worked correctly. I
 probably should have tracked down the error, but for the most part, I just
 want software installation to work smoothly so I can use it.

 Qt Creator works just fine with my port.
 One exception: I've been running into a missing symbol issue with version
 3.4.1, but that has nothing to do with the install location (and probably
 everything with the fact that the default Qt build on 10.9 somehow uses
 the 10.10 SDK).

 > * It is ''much'' easier to maintain.

 I don't agree, in part because of the things that are not found
 automatically as you mention below, but also because I expect things in
 other places, similar to where they are for Qt4 and where I find them on
 Linux. I can't speak for Michael of course, but I'd be surprised if he
 would consider making more changes than necessary to make qt4-mac co-
 installable...

 >     * Making significant changes to a port requires significant testing
 for every major (or not so major) upgrade.

 This argument would carry a lot of weight I we were discussing a layout
 significantly different than the one tried and tested with qt4-mac. On the
 other hand, moving now to a scheme where everything is in its own
 directory (and thus the INSTALL_PREFIX  and HOST_PREFIX point there rather
 than to the MacPorts prefix) is likely to lead to issues down the road
 when KF5 makes its appearance, with its expectations of where things are
 to be found. We're already having significant problems with the
 QStandardPaths defaults on OS X (and working on a patch to make it comply
 with XDG/linuxy standards); having to cope with the Qt dependencies
 installed elsewhere is going to complicate that even further.

 >         * This takes maintainer time (a precious commodity if ever there
 was one).

 As mentioned before (on the ML?), I do happen to have time for such things
 on my hands ...

 >         * This delays upgrades.
 >     * The fewer changes that are made, the fewer things can go wrong.

 As I argued above, the scheme I propose is well-tested, and is actually
 closer to what qt5-mac did not so long ago.
 As far as proof goes, I didn't run into any issue or delay because of this
 installation layout when I upgraded from 5.3.2 to 5.4.0 to 5.4.1 to 5.4.2
 (and when I downgraded back from 5.4.1 to 5.3.2 for 10.6.8 systems), also
 when installing from scratch. Nor have I had any problem reports from the
 few people who installed my version and used it.
 Can you name 1 thing that you feel would have made upgrading easier when
 installing everything in a single location (and that's not the future
 upgrade to Qt6)?

 > * It makes installing multiple versions of Qt trivial (#44193).

 That's the only argument that I agree with fully. I've tried to assess to
 what extent this is an argument that carries any weight, and I have the
 strong impression that MacPorts won't support use cases in which multiple
 Qt5 versions would be required. Qt guarantees backward compatibility
 within a major version, meaning that applications built against Qt 5.0.0
 (and not using anything "private") will work fine running against Qt
 5.4.2. Developing Qt applications using MacPorts' Qt and targeting systems
 that can only run older Qt5 versions would be a use case where someone
 might want to use that same Qt version (even if it isn't necessary), but I
 asked and the answer was unambiguously that that's not a supported use
 case .
 In any case there are other trivial solutions, should a supported need
 arise to provide multiple simultaneous versions. Just as one can install
 everything in libexec/qt54, libexec/qt53, libexec/qt52 etc, one can
 install only part in there and the shared things in share/qt54,
 share/qt53, share/qt52 . That doesn't really change anything.

 > There are, of course, a few disadvantages:
 > * pkgconfig files are not found automatically.
 > * Library and header files are not found automatically.
 > * qmake is not found automatically

 I would actually propose to provide ${prefix}/bin/qmake-qt[45] as
 symlinks, and I've also submitted a port for qtchooser.

 > * As noted earlier, it is not the same "scheme used by Linux distros."

 I cannot find that earlier note. I'm not claiming it's the exact same
 scheme, it's a similar scheme. Ubuntu uses /usr/share/qt[45] (so that's
 identical or at least equivalent):

 {{{
  ll -d /usr/share/qt[45]/*
 379052  13 drwxr-xr-x   2 root root      9 Apr 22 09:59
 /usr/share/qt4/bin/
 379053  13 drwxr-xr-x   5 root root      5 Aug  7  2014
 /usr/share/qt4/doc/
 379050   1 lrwxrwxrwx   1 root root     17 Mar 12  2014
 /usr/share/qt4/include -> ../../include/qt4/
 379054  13 drwxr-xr-x 114 root root    117 Apr 22 09:59
 /usr/share/qt4/mkspecs/
 364497  13 drwxr-xr-x   2 root root     15 Apr 22 09:39
 /usr/share/qt4/phrasebooks/
 385972   1 lrwxrwxrwx   1 root root     21 Apr 22 01:57
 /usr/share/qt4/plugins -> ../../lib/qt4/plugins
 395304 117 -rw-r--r--   1 root root 333221 Apr  7 11:26
 /usr/share/qt4/q3porting.xml
 379055  13 drwxr-xr-x   2 root root    113 Apr 22 09:59
 /usr/share/qt4/translations/
 497293  13 drwxr-xr-x  13 root root     47 Jul 10  2014
 /usr/share/qt5/doc/
 502595  13 drwxr-xr-x   2 root root     15 Jun 23  2014
 /usr/share/qt5/phrasebooks/
 }}}

 That's Ubuntu 14.04, which has only Qt 5.2 (in my case only a partial
 installation at that).

 Ubuntu installs the binaries in /usr/lib/qt[45] with an additional layer
 because it doesn't know universal binaries:

 {{{
 %> ll -d /usr/lib/*/qt[45]/*
 1620995 13 drwxr-xr-x 12 root root 12 May 14  2014 /usr/lib/i386-linux-
 gnu/qt4/plugins/
  173747 13 drwxr-xr-x  2 root root 32 Apr 22 09:59 /usr/lib/x86_64-linux-
 gnu/qt4/bin/
  173748 13 drwxr-xr-x  6 root root  6 Apr 14 17:38 /usr/lib/x86_64-linux-
 gnu/qt4/imports/
  173749 13 drwxr-xr-x 19 root root 19 Oct  8  2014 /usr/lib/x86_64-linux-
 gnu/qt4/plugins/
  496567 13 drwxr-xr-x  2 root root 30 Jun  4 12:49 /usr/lib/x86_64-linux-
 gnu/qt5/bin/
  397720 13 drwxr-xr-x 26 root root 28 Jun  4 12:51 /usr/lib/x86_64-linux-
 gnu/qt5/examples/
  602862 13 drwxr-xr-x  2 root root  3 Jul 10  2014 /usr/lib/x86_64-linux-
 gnu/qt5/imports/
  499579 13 drwxr-xr-x  2 root root  4 Jun 23  2014 /usr/lib/x86_64-linux-
 gnu/qt5/libexec/
  496569 13 drwxr-xr-x 92 root root 96 Jun  4 12:49 /usr/lib/x86_64-linux-
 gnu/qt5/mkspecs/
  498759 13 drwxr-xr-x 27 root root 27 Oct 18  2014 /usr/lib/x86_64-linux-
 gnu/qt5/plugins/
  602894 13 drwxr-xr-x 24 root root 24 Jan 21 15:51 /usr/lib/x86_64-linux-
 gnu/qt5/qml/
 }}}

 Yes, the plugins are installed in the binary dir, but that's probably
 largely because of the need to install 2 trees on multiarch systems (and
 /usr/share/qt*/plugins exists as a symlink. Yes, qt5's mkspecs files are
 installed in the libdir instead of in /usr/share/qt5, but I think those
 are only used by qmake and possibly cmake, both of which will know how to
 find them.

 > * Other problems of which I am unaware.

 I expect more unforeseen problems with a scheme that does not remain close
 to the one that's always been followed before...
 >
 > I think the advantages outweigh the disadvantages.
 >
 > = Conclusion =
 ...
 > I think Qt is a very useful piece of software, and it would be nice if
 we had a fully functioning version in MacPorts.

 It certainly is, but the reason it's nice and almost unavoidable to have
 it in MacPorts is that it's a middleware on which so many other potential
 ports depend. It's the needs of those ports that need to have priority
 over Qt's own needs IMHO. If that means more work for the Qt5
 maintainer(s), so be it...
 (Which is also the reason why I ended up testing a universal build [for
 Ryan] and going out of my way to include support for 10.6.8.)

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