CADSWES Qt5 Port Status / November 2015
Phil Weinstein, 11-13-2015
We did achieve a runnable build of RiverWare with 5.5.1 on 64-bit Windows, and we're probably pretty close on 32-bit. The 64-bit build succeeded on both the machine on which Qt 5.5.1 itself was built (Phil's development machine), and also intermittently on another 64-bit machine (spurwink). (We'll take a closer look at that intermittent behavior when another 64-bit machine becomes available).
The ported RiverWare code base which builds with Qt 5.5.1 can also be built with Qt 4.8.5. This is put aside on these two branches:
Note: Both of these, but especially the latter, have been, and will probably again be "re-based" in GIT. So, it may be necessary to dump and re-check-out these branches in any local GIT repository on any of our development machines.
The required ancillary libraries needed for building "Qt5" RiverWare have also been built for both 64-bit and 32-bit, and can be installed on a development machine with this command:
"buildsQt5" is a new win-config "area" including the following Tar-GZipped packages. Note that the package name is also the name of the installation directory on development machines under C:\RiverWare\tools\.
| Package | Description | Notes |
| Qt-551 | Qt 5.5.1, VS10 | |
| Qwt-612_Qt-551 | Qwt 6.1.2, Qt 5.5.1, VS10 | |
| RdfToExcel_Qt-551 | RdfToExcel, Qt 5.5.1, VS10 | [1]* |
| Quazip-0.7.1_Qt-551 | QuaZIP 0.7.1, Qt 5.5.1, VS10 | |
| QsLog-2.0b3_Qt-551 | QsLog, Qt 5.5.1, VS10 | [2]* |
| icu-55.1 | icu 55.1, VS10 | [3]* |
*[1] RdfToExcel is our own application which is maintained within the RiverSMART (Study Manager) GIT repository.
*[2] QsLog isn't actually needed for the RiverWare build, but rather for the build of the "Remote" executable under RiverWare. This library has not yet been built for 32-bit.
*[3] ICU is required both for building Qt5 itself, and for support of QWebKit within Qt applications. ICU does not, itself, depend on Qt5.
The process of building Qt 5 from source code -- and also ICU -- is documented quite extensively in the following document. This still refers to the building of an earlier version, Qt 5.4.2. Minor changes for Qt 5.5.1 are documented on the accompanying 1-pager cited here.
It's significant to note the options with which Qt 5.5.1 the build was configured:
configure
-prefix %CD%\qtbase
-commercial
-nomake tests
-debug-and-release
-platform win32-msvc2010
-shared
-qt-zlib
-qt-libpng
-qt-libjpeg
-no-opengl
-no-angle
-icu
-no-strip
-saveconfig CwQt551-ConfigOut
Note that the "public" interface of the Qt 5.5.1 build is the "qtbase" subdirectory under the source tree. That is, C:\Riverware\tools\Qt-551\qtbase.
The original build of RiverWare with Qt 5.5.1 went fairly smoothly, but there were confounding difficulties replicating that build onto another 64-bit Windows machine. The seemingly non-deterministic of paths in generated .vcxproj files -- being either absolute or relative -- as a result of running qmake.pl -- apparently creates a problem, and can cause the Qt MOC (meta-object-compiler) to fail with this error: moc: Cannot open options file specified with @. This was seen on spurwink, but the most recent generate of .vcxproj files were successful on that machine). Interestingly, on different invocations of qmake.pl, some paths switch from absolute to relative, and others switch the other way.
To explore this problem (and to refrain from using spurwink further), one of our 64-bit training machines was temporarily reconfigured as a development machine. That produced a different sort of failure which pointed to (by way of some google searches on the error message) some advanced compiler technology options of Visual Studio 2010, and for that reason, I'm suspecting that use of Visual Studio 2010 "Ultimate" (instead of just "Professional") may have been a problem.
Also, according to current Qt documentation, "as of March 2013," Visual Studio 2010 needs to be installed with Windows SDK 7.1 in this order:
... See the bottom of this webpage: http://doc.qt.io/qt-5/windows-requirements.html
Once other 64-Bit development machines become available, we will want to get to the bottom of the intermittent problems with qmake.pl (which calls Qt's qmake.exe on each RiverWare Visual Studio project's .pro file). A question about this particular Qt MOC error was posted to the Qt technical e-mail list, but there has not been any response:
Another problem which has been only temporarily addressed was a cause of a crash due to the invalid use of the QObject::tr() function on literal strings in the initialization of module-level const static QStrings. Invocation of that function "tr" (translate) before the dynamic initialization of Qt's meta object system causes a crash (NULL pointer dereference). Such uses of QObject::tr() have been removed from only the single module which was crashing -- apparently others happen to be called sufficiently later in the RiverWare startup sequence. But that could shift, and we really do need to remove all such uses. More information can be seen in this post to the Qt technical e-mail list:
After building the Qt 5.5.1 and other necessary libraries on our 32-bit machine (Scuba), a build of RiverWare (the Qt5Port2 branch) was attempted. This also resulted in the Qt MOC (meta-object-compiler) error reported above: moc: Cannot open options file specified with @. (But this time, this is happening ON the machine on which Qt 5.5.1 was, itself, built). We haven't gotten to the bottom of this, but probably re-generating the .vcxproj files with qmake.pl may, at least intermittently, result in a complete RiverWare build. This will need to be revisited once we have another 32-Bit machine on which to try this RiverWare build.
Scuba is running Windows XP. For building RiverWare with Qt 5.5.1, it may be important that it be a Windows 7 machine. Also, it may be important that Visual Studio and the Windows SDK 7.1 be installed in the order described above.
After Release 6.8 is branched from the master GIT branch, the Qt5Port1 branch (still a Qt 4.8.5 build) should be merged into the master branch. (At that time, the Qt5Port2 branch, with the "make file" changes for the Qt 5.5.1 build of RiverWare, should be squashed and re-based on top of the master branch).
A significant amount of testing should then be done with the Qt5Port2 branch (using Qt 5.5.1). We would then need to decide when to merge that onto the master branch, effectively converting our continuing RiverWare development over to Qt 5.
We'll also need to confirm the deployment of all necessary execution components (primarily DLLs) required for the Qt5 RiverWare executable.
Other CADSWES applications, notably RiverSMART (Study Manager), need to be built with Qt 5.5.1. I believe that all ancillary libraries dependent on Qt which are needed for these applications have been built and deployed (using win-config.pl). So this process will involve working through the compilation errors, probably fairly limited.
Some advanced components of Qt 5 will require us to upgrade from Visual Studio 2010 to Visual Studio 2013. This applies to the Qt WebEngine (the replacement, albeit incomplete, for Qt WebKit). This may also apply to the OpenGL graphics stack which has been left out of our Qt 5.5.1 build. This is a requirement for Qt Quick and QML 2, and possibly other advanced graphics modules.
We may prefer to drop 32-bit support for RiverWare before attempting to use Qt WebEngine. That component is crazily huge -- almost a million lines of source code -- and my have other special requirements.
--- (end) ---