qt5-mac-devel submission: provides Qt 5.4.x

[RJVB (René Bertin)]

I've created a "devel" port that provides Qt 5.4.0, Qt's current "latest and greatest" release version.

In line with my work on qt4-mac and qt5-mac this port can be co-installed with qt4-mac (but not qt5-mac, of course).

The port has a +KDE variant that caters to people working on KF5 but won't bite regular users; in fact, it will build Qt in "release with debug info" mode, allowing crash reports with useful information into the Qt libraries.

I carried over the patches from 5.3.2 that still applied cleanly, included the fix to the standard directories from the KDE-Mac group (currently under review for inclusion in Qt), and 2 patches to the build system. One makes up for incomplete cmake files created when doing an out-of-tree build, the other enables qt5-mac-devel to compile when qt5-mac is installed and active. This particular patch *may* not be 100% reliable but the 1 time it failed for me it did do its job when I repeated the port build command. The bug has been signalled and should be under investigation.

This port uses a new version of the qt5 and qmake5 PortGroups; those could go away when qt5-mac-devel becomes qt5-mac, or they could remain as the PortGroups for qt5-mac devel version.

NB: the generation of debug info does mean the port takes quite a bit longer to build, and you need approx. 28Gb for the build directory (installed, the port will take about 400Mb).

[RJVB (René Bertin)]

all-inclusive patch, created using kdesvn

[RJVB (René Bertin)]

a new patch that makes Qt5.4 print out more useful info when warning about a menu item already added to a menu

[mkae (Marko Käning)]

Cc Me!

[RJVB (René Bertin)]

This new version corrects a few small issues (including the "misplaced" libQt5UiTools.a library and warnings printed for missing fonts from Apple's fallback selection if the user deleted any from that set). It also introduces two new subports:

• qt5-mac-devel-x11: provides the xcb platform plugin that allows Qt applications to use a (remote) X11 server for displaying. This feature works surprisingly well; the main missing functionality are menu shortcuts (accelerators).
• qt5-mac-devel-examples: builds a selection of the examples included with the Qt 5.4 sources. These are installed in /Applications/MacPorts/Qt5/examples .

[RJVB (René Bertin)]

For show: Qt's Assistant via X11 and Cocoa side-by-side

[RJVB (René Bertin)]

Addresses the issue in #44204

[mojca (Mojca Miklavec)]

Cc Me!

[RJVB (René Bertin)]

Added missing build dependency on port:ninja (used by QtWebEngine) and fixed the extraction-using-hfsCompression attempt.

[RJVB (René Bertin)]

Checks if the QtWebEngine.ninja build files exist before doing a reinplace in them, and only in the prebuild. I had not realised they are created only later on, during the build step and not at once during the configure step.

[RJVB (René Bertin)]

Backports a fix to re-enable building on OS X 10.7 . See ​https://bugreports.qt.io/browse/QTBUG-43279

[RJVB (René Bertin)]

Update, bumping Qt to 5.4.1 which came out recently, and various improvements made possible by Bradley's VM to which he kindly gave me access (and which is halfway across the globe from me :)) as well as by Ian's patience building the 5.4.0 version on OS X 10.7 .

• the +KDE variant was moved to a subport, qt5-mac(-devel)-kde under the assumption that future KF5 ports might want to to something like depends_lib-append path:${qt_bins_dir_rel}/qmake:qt5-mac-kde (i.e. install qt5-mac-kde unless another Qt 5 port already provides qmake).
• the QStandardPaths patch is still in draft and likely to change
• the qt5-mac(-devel)-mysql56-plugin subport was moved to port:qt5-mac-mysql-plugins, a metaport I submitted earlier today
• the QtWebEngine component was moved to its own subport. This one takes about as long to build as the other Qt components, and wasn't part of earlier versions so it seems to make sense to alleviate the main port.
• the qt5-mac(-devel)-docs subport has been renamed to qt5-mac(-devel)-zz-docs, simply so that it's the last subport to be upgraded during a Qt update. It only depends on the main port, but fails to build properly when earlier versions of other components are installed. This subport would be a prime candidate for a "require trace mode" feature.

I have only tested building on OS X 10.9, and only in 64bit release mode; it Qt 5.4.1 didn't introduce any regressions this same "flavour" should also build on 10.7 (and presumably 10.8 and 10.10).

It is not at all unlikely that I introduced unintended regressions in the universal build, so that ought to be tested, as well as a pure 32bit version.

The debug version could also use testing, though I should point out that I have selected the configure options that build the release version with sufficient debug info to obtain useful backtraces into Qt code. I *think* that ought to be sufficient for most of us.

[RJVB (René Bertin)]

A minor change: the Qt5 PortGroup file now defines a variable, qt5_dependency for reference by client ports like translations which do not directly depend on Qt and now can do

depends_lib-delete ${qt5_dependency}

to signal that fact.

[springermac (Jonathan Springer)]

Cc Me!

[RJVB (René Bertin)]

Another update:

• The qt5-mac-(devel-)sqlite3-plugin has been rolled back into the main port. Rationale: the plugin is required by Assistant.app, which is part of the main port.

• The +universal build has been tested; so far the main port builds and functions correctly (mostly) in UB mode. There may be an issue building other Qt components in universal mode, this is still under investigation

• I've included a new version of the QStandardPaths patch, based on the approach described here (​https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=275639) but targeting only code used on OS X. No change has been made yet to the build system, but the idea is that qmake and/or cmake will provide a switch that leads to the incorporation of an additional module at link time which switches the QStandardPaths class to XDG mode. Without that module, the class returns the usual locations expected on OS X.

NB: help with this patch will be greatly appreciated, esp. with modifying the build systems!

[springermac (Jonathan Springer)]

Trying to install qt5-mac-devel without universal gives this error "Error: org.macports.extract for port qt5-mac-devel returned: can't read "universal_archs_to_use": no such variable".

[springermac (Jonathan Springer)]

Running "port info py-pyqt5" with the pyqt5 portfile modified to depend on qt5-mac-devel gives this error

DEBUG: can't read "name": no such variable
    while executing
"return -code error "\n\nERROR:\n Qt5 appears to be installed in the old, exclusive mode,
and this port, ${name}, ought to use PortGroup qt5 1.0\n""
    invoked from within
"if {![info exists qt5_is_concurrent]} {
    if {![info exists building_qt5]} {
                return -code error "\n\nERROR:\n\
Qt5 appears to be ins..."
    (file "/Users/jonathanspringer/projects/ports/trunk/dports/_resources/port1.0/group/qt5-1.0.tcl" line 129)

[RJVB (René Bertin)]

Replying to springermac@…:

Trying to install qt5-mac-devel without universal gives this error "Error: org.macports.extract for port qt5-mac-devel returned: can't read "universal_archs_to_use": no such variable".

Stupid regression, fixed now.

[RJVB (René Bertin)]

Replying to springermac@…:

Running "port info py-pyqt5" with the pyqt5 portfile modified to depend on qt5-mac-devel gives this error

Heh, that was an error in what was supposed to be an error message that has become obsolete in itself (it came from a Qt5-2.0 portgroup I used initially). Thanks for tripping over this; should be fixed now.

That said, ports are not really supposed to depend on -devel alternatives. The idea is that port:foo-devel can be installed as an alternative to port:foo, and that there is for instance a portgroup that declares the dependency on foo such that foo-devel is accepted too. Evidently that only works when foo-devel is actually installed, so what happened here is that the portgroup detected you had a legacy/exclusive Qt5 install (and still thought it had to instruct you to use the legacy Qt5 portgroup).

[RJVB (René Bertin)]

Further testing of the universal builds (qt5-mac-devel-x11).

[NeilGirdhar (Neil)]

Cc Me!

[RJVB (René Bertin)]

This version introduces a functional build of Qt 5 on OS X 10.6.8 Snow Leopard.

I haven't tried to provide Qt 5.4 on that OS version. I was under the impression that building Qt 5.3.2 was still supported on 10.6, but that turned out to be wrong and it was cumbersome enough to come up with a working build.

So, port:qt5-mac-devel provides Qt 5.3.2 on OS X 10.6, with an additional dependency on port:clang-3.4 or newer. The port also requires that a selection be made using port select (or through manual symlinks ${prefix}/bin/clang and ${prefix}/bin/clang++. This is 1) to avoid a hard dependency on a specific clang version and 2) because Qt imposes the exact compiler choice to all applications built against it, through qmake. NB: I haven't yet checked if port:qt5-creator builds against this Qt version.

This qt5-mac-devel version also fixes a series of missing-NSAutoreleasePool leaks during startup, through a backported patch from Qt 5.5

[RJVB (René Bertin)]

provides Qt 5.4.1

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

The port also requires that a selection be made using port select (or through manual symlinks ${prefix}/bin/clang and ${prefix}/bin/clang++.

The select mechanism is meant for end-user convenience; ports cannot require its use. You’re going to have to find a better solution to the problem you’re trying to fix.

[RJVB (René Bertin)]

Did you read the Portfile to see what kind of requirement we're talking about? This *is* about end user convenience (INCLUDING the fact that I already spent a lot of time figuring out how to support 10.6.8 users). The Portfile guides users on 10.6 to set up their environment in such a way that 1) the compiler version is not going to be baked in and 2) the port can actually build without having to jump through all kinds of hoops and loops to ensure that the installed clang is used.

The "requirement" takes the form of instructing the user to use port select if there is no clang++ in ${prefix}/bin . If you know of a better way to check for and "require" the presence of clang and clang++ (so not clang*-mp-*) in the path that are NOT the ones from Xcode 3 or Xcode 4.2 I'm all ears.

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

This *is* about end user convenience

The select mechanism is only meant for use outside of MacPorts (e.g., as a convenience to users who compile their own code). A user who only compiles via MacPorts should never have to use port select for anything.

The Portfile guides users on 10.6 to set up their environment in such a way that 1) the compiler version is not going to be baked in and 2) the port can actually build without having to jump through all kinds of hoops and loops to ensure that the installed clang is used.

So the majority of users would not be able to install qt5-mac-devel without manual fiddling?

The "requirement" takes the form of instructing the user to use port select if there is no clang++ in ${prefix}/bin . If you know of a better way to check for and "require" the presence of clang and clang++ (so not clang*-mp-*) in the path that are NOT the ones from Xcode 3 or Xcode 4.2 I'm all ears.

1. I’d frankly just require a specific version of Clang and be done with it. Yes, I know it takes extra time and space.
2. Can Qt / qmake not be told to use another compiler?

[RJVB (René Bertin)]

Replying to larryv@…:

The Portfile guides users on 10.6 to set up their environment in such a way that 1) the compiler version is not going to be baked in and 2) the port can actually build without having to jump through all kinds of hoops and loops to ensure that the installed clang is used.

A user who only compiles via MacPorts should never have to use port select for anything.

Oh ... so I could just use system port select ..... from the Portfile if it detects that the call hadn't been made? O:-)

So the majority of users would not be able to install qt5-mac-devel without manual fiddling?

Because the majority of users are on 10.6? I don't see how else you reached that conclusion?

1. Can Qt / qmake not be told to use another compiler?

With difficulty, that's what has been the greatest hurdle. On 10.6 . On later OS X versions xcrun is "clever" enough to realise it shouldn't try to find a full path in the Xcode toolchain, but the 10.6 xcrun errors out when it is handed a full path. So yes, you can tell it to do that, but either it will result in an error or else you'll still get the Xcode version.

[larryv (Lawrence Velázquez)]

Replying to rjvbertin@…:

Replying to larryv@…:

So the majority of users would not be able to install qt5-mac-devel without manual fiddling?

Because the majority of users are on 10.6? I don't see how else you reached that conclusion?

I was only thinking about Snow Leopard users while writing that, so I forgot to write out the conditional. The fact that this only affects them certainly mitigates the issue, but a solution that eliminates the manual intervention would be much better.

the 10.6 xcrun errors out when it is handed a full path

What exactly does the build do with the output of xcrun? Does it use xcrun to call the compiler, or does it store the path somewhere, or what? Could you cut xcrun out of the build system?

[RJVB (René Bertin)]

Replying to larryv@…:

What exactly does the build do with the output of xcrun? Does it use xcrun to call the compiler, or does it store the path somewhere, or what? Could you cut xcrun out of the build system?

It uses xcrun to determine the full paths to CC, CXX, AR, RANLIB and a few others, based on just their names which are given in the mkspec. Why they ever went that way is beyond me because AFAIK Xcode always installed proxies in the path. I'm now indeed trying a build with xcrun cut completely out of the path, and an automatic, Qt-specific alternative to using port select.

[RJVB (René Bertin)]

At Michael's (michaelld) suggestion I'm moving to a new way of distributing my ports: ​https://github.com/RJVB/mp-port-repository/tree/master/aqua/qt5-mac-devel ​https://github.com/RJVB/mp-port-repository/blob/master/_resources/port1.0/group/qt5-1.0.tcl ​https://github.com/RJVB/mp-port-repository/blob/master/_resources/port1.0/group/qmake5-1.0.tcl

I just made a new commit with

• improved build on OS X 10.6.8 . The user is no longer required to use port select to provide the clang compiler version of choice; the Portfile now sets up a Qt-specific/internal symlink to the latest available & compatible version (it already pulled in clang-3.5 if none were available). Testing this cost me another 7h of build time ...
• contains a not-too-minimal set for use with the port select --set qt mechanism. The companion port:qt_select will conflict with the already existing port:qtchooser which provides Qt's own more versatile/flexible mechanism to select a default Qt version.

[ctreleaven (Craig Treleaven)]

Cc Me!

[RJVB (René Bertin)]

Replying to rjvbertin@…:

At Michael's (michaelld) suggestion I'm moving to a new way of distributing my ports: ​https://github.com/RJVB/mp-port-repository/tree/master/aqua/qt5-mac-devel ​https://github.com/RJVB/mp-port-repository/blob/master/_resources/port1.0/group/qt5-1.0.tcl ​https://github.com/RJVB/mp-port-repository/blob/master/_resources/port1.0/group/qmake5-1.0.tcl

Heads-up: several smaller updates were made to my port:qt5-mac-devel. It is not my habit to touch the port revision on unpublished ports, so a manually forced upgrade will be required.

[jrjsmrtn]

Cc Me!

[kencu (Ken)]

although I would dearly love to have a qt5 version that runs on 10.6.8, I think this effort is DOA. Any objections to closing this? Any 10.6.8 afficionados out there that might take this on and make it work for us?

[RJVB (René Bertin)]

No, I don't mind closing this - I'd all but forgotten about it (and apparently I still can't do such housekeeping myself despite what looks like a trac update).

10.6.8 aficionados can try to install the equivalent port:qt53-kde from my macstrop repo (github.com/RJVB/macstrop or the stripped-down version at github.com/mkae/macstrop). I haven't built it myself for ages, and there's more and more software that requires newer Qt versions anyway.

[barracuda156]

Replying to kencu:

although I would dearly love to have a qt5 version that runs on 10.6.8, I think this effort is DOA. Any objections to closing this? Any 10.6.8 afficionados out there that might take this on and make it work for us?

Why was it never merged, given that it presumably worked on Intel?

[kencu (Ken)]

I did fix and commit a version of qt5 for 10.6.8 to use, and it does work for some software. I’m using it now.

[barracuda156]

Replying to kencu:

I did fix and commit a version of qt5 for 10.6.8 to use, and it does work for some software. I’m using it now.

You mean qt53 in master? Good to know, thank you.