Opened 4 years ago

Closed 9 months ago

#46536 closed submission (wontfix)

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

Reported by: RJVB (René Bertin) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), mojca (Mojca Miklavec), springermac (Jonathan Springer), mistersheik@…, ctreleaven (Craig Treleaven), jrjsmrtn
Port: qt5-mac-devel

Description

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).

Attachments (32)

qt5.4-patches.diff (93.2 KB) - added by RJVB (René Bertin) 4 years ago.
all-inclusive patch, created using kdesvn
qmake5-2.0.tcl (2.5 KB) - added by RJVB (René Bertin) 4 years ago.
patch-qmacstyle_mac.diff (876 bytes) - added by RJVB (René Bertin) 4 years ago.
Add-workaround-for-GL-on-Android-emulator.patch (1.5 KB) - added by RJVB (René Bertin) 4 years ago.
Break-after-handling-the-read-write.patch (1.2 KB) - added by RJVB (René Bertin) 4 years ago.
deactivate-menurole-heuristics.patch (2.3 KB) - added by RJVB (René Bertin) 4 years ago.
debug-negative-qtimerint.patch (432 bytes) - added by RJVB (René Bertin) 4 years ago.
disable-generic-plugin-when-others-available.patch (316 bytes) - added by RJVB (René Bertin) 4 years ago.
load_testability_from_env_var.patch (593 bytes) - added by RJVB (René Bertin) 4 years ago.
patch-machtest.diff (847 bytes) - added by RJVB (René Bertin) 4 years ago.
patch-tst_benchlibcallgrind.diff (577 bytes) - added by RJVB (René Bertin) 4 years ago.
patch-tst_qaccessibilitymac_helpers.diff (645 bytes) - added by RJVB (René Bertin) 4 years ago.
patch-tst_qarraydata.diff (524 bytes) - added by RJVB (René Bertin) 4 years ago.
patch-tst_qpluginloader.diff (672 bytes) - added by RJVB (René Bertin) 4 years ago.
qprocess-nozombies.patch (756 bytes) - added by RJVB (René Bertin) 4 years ago.
QtBearer-networkmanager-make-sure-to-set-flag-Active.patch (22.6 KB) - added by RJVB (René Bertin) 4 years ago.
remove_google_adsense.patch (2.0 KB) - added by RJVB (René Bertin) 4 years ago.
remove_icon_from_example.patch (888 bytes) - added by RJVB (René Bertin) 4 years ago.
patch-shared.diff (549 bytes) - added by RJVB (René Bertin) 4 years ago.
fix-qstandardpaths.patch (3.1 KB) - added by RJVB (René Bertin) 4 years ago.
always_include_private_headers.diff (981 bytes) - added by RJVB (René Bertin) 4 years ago.
debug-menuItem-already-in-menu.patch (1.1 KB) - added by RJVB (René Bertin) 4 years ago.
a new patch that makes Qt5.4 print out more useful info when warning about a menu item already added to a menu
qt5-1.0.tcl (12.3 KB) - added by RJVB (René Bertin) 4 years ago.
qt5-2.0.tcl (10.9 KB) - added by RJVB (René Bertin) 4 years ago.
patch-to-build-xcb.diff (2.4 KB) - added by RJVB (René Bertin) 4 years ago.
dont-warn-missing-fallback-fonts.patch (774 bytes) - added by RJVB (René Bertin) 4 years ago.
all-examples.pro (529 bytes) - added by RJVB (René Bertin) 4 years ago.
Portfile (515 bytes) - added by RJVB (René Bertin) 4 years ago.
Qt54-Assistant-cocoa-vs-xcb.png (371.0 KB) - added by RJVB (René Bertin) 4 years ago.
For show: Qt's Assistant via X11 and Cocoa side-by-side
patch-qcompilerdetection_h.diff (1.3 KB) - added by RJVB (René Bertin) 4 years ago.
Portfile.qt5 (32.1 KB) - added by RJVB (René Bertin) 4 years ago.
port=qt5-mac-devel.tar.bz2 (61.9 KB) - added by RJVB (René Bertin) 4 years ago.
provides Qt 5.4.1

Download all attachments as: .zip

Change History (67)

Changed 4 years ago by RJVB (René Bertin)

Attachment: qt5.4-patches.diff added

all-inclusive patch, created using kdesvn

Changed 4 years ago by RJVB (René Bertin)

Attachment: qmake5-2.0.tcl added

Changed 4 years ago by RJVB (René Bertin)

Attachment: patch-qmacstyle_mac.diff added

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Attachment: patch-machtest.diff added

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Attachment: patch-tst_qarraydata.diff added

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Attachment: qprocess-nozombies.patch added

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Attachment: remove_google_adsense.patch added

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Attachment: patch-shared.diff added

Changed 4 years ago by RJVB (René Bertin)

Attachment: fix-qstandardpaths.patch added

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by 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

comment:1 Changed 4 years ago by mkae (Marko Käning)

Cc: mk@… added

Cc Me!

Changed 4 years ago by RJVB (René Bertin)

Attachment: qt5-1.0.tcl added

Changed 4 years ago by RJVB (René Bertin)

Attachment: qt5-2.0.tcl added

Changed 4 years ago by RJVB (René Bertin)

Attachment: patch-to-build-xcb.diff added

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Attachment: all-examples.pro added

Changed 4 years ago by RJVB (René Bertin)

Attachment: Portfile added

comment:2 Changed 4 years ago by 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 .

comment:3 Changed 4 years ago by mf2k (Frank Schima)

Keywords: haspatch submission removed

Changed 4 years ago by RJVB (René Bertin)

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

comment:4 Changed 4 years ago by RJVB (René Bertin)

Addresses the issue in #44204

Last edited 4 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:5 Changed 4 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:6 Changed 4 years ago by RJVB (René Bertin)

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

comment:7 Changed 4 years ago by 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.

Changed 4 years ago by RJVB (René Bertin)

Changed 4 years ago by RJVB (René Bertin)

Attachment: Portfile.qt5 added

comment:8 Changed 4 years ago by RJVB (René Bertin)

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

Last edited 4 years ago by RJVB (René Bertin) (previous) (diff)

comment:9 Changed 4 years ago by 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.

comment:10 Changed 4 years ago by mkae (Marko Käning)

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

comment:11 Changed 4 years ago by 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.

Last edited 4 years ago by RJVB (René Bertin) (previous) (diff)

comment:12 Changed 4 years ago by springermac (Jonathan Springer)

Cc: springermac@… added

Cc Me!

comment:13 Changed 4 years ago by 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!

comment:14 Changed 4 years ago by 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".

comment:15 Changed 4 years ago by 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)

comment:16 in reply to:  14 Changed 4 years ago by 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.

comment:17 in reply to:  15 Changed 4 years ago by 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).

comment:18 Changed 4 years ago by RJVB (René Bertin)

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

comment:19 Changed 4 years ago by mistersheik@…

Cc: mistersheik@… added

Cc Me!

comment:20 Changed 4 years ago by 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

Changed 4 years ago by RJVB (René Bertin)

Attachment: port=qt5-mac-devel.tar.bz2 added

provides Qt 5.4.1

comment:21 in reply to:  20 Changed 4 years ago by 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.

comment:22 Changed 4 years ago by 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.

comment:23 in reply to:  22 ; Changed 4 years ago by 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?

comment:24 in reply to:  23 ; Changed 4 years ago by 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.

comment:25 in reply to:  24 ; Changed 4 years ago by 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?

comment:26 in reply to:  25 Changed 4 years ago by 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.

comment:27 Changed 4 years ago by 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.

comment:28 Changed 4 years ago by ctreleaven (Craig Treleaven)

Cc: ctreleaven@… added

Cc Me!

comment:29 in reply to:  27 Changed 4 years ago by 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.

comment:30 Changed 4 years ago by jrjsmrtn

Cc: jrjsmrtn@… added

Cc Me!

comment:31 Changed 2 years ago by mkae (Marko Käning)

Cc: mkae removed
Owner: changed from macports-tickets@… to mkae
Status: newassigned

comment:32 Changed 12 months ago by mf2k (Frank Schima)

Owner: mkae deleted

comment:33 Changed 9 months ago by 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?

comment:34 Changed 9 months ago by 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.

comment:35 Changed 9 months ago by kencu (Ken)

Resolution: wontfix
Status: assignedclosed
Note: See TracTickets for help on using tickets.