Last week in Qt development (week 30 2012)
This post is part of an ongoing series about developments and discussions in Qt.
Some parts of this report are still under discussion, and don’t necessarily reflect the final state of Qt 5. The target audience is people involved in Qt development itself, but without the time to follow everything that happens, and others with a strong interest in Qt, Qt 5, and the community.
This week we cover QLibrary loading performance, release preparations and improved APIs for stable and repeatable unit tests.
QLibrary loading performance
The performance of QLibrary loading has been improved with a series of patches in Qt 5 written by KDAB engineer Sean Harmer. The patches use an improved search heuristic for the common case of file names for libraries and plugins. As this is a behavior change in Qt 5, the patches were also added in a backwards compatible way to Qt4 followed by a series of patches to enable use of the feature.
More cleanup of Qt5 CMake files
Some recent effort has gone into improving the test coverage across all Qt modules of the Qt 5 CMake files. All CMake packages which would be expected to work with find_package or qt5_use_widgets are tested, and CMake packages which have previously been generated for modules ‘internal’ to Qt have been removed.
More wait APIs in QTestLib
Several new APIs have appeared in QTestLib to allow waiting during tests. It is now possible to wait for a window to be exposed, or become active etc. Another patch implements a wait() method for QSignalSpy. These APIs have previously typically been implemented by waiting an arbitrary amount of time, which has been problem prone in the QtProject CI system.
Custom large static Qt builds
An interesting thread explored the possibilities of a statically compiled Qt for improving startup performance on restricted proprietary platforms. The discussion centered around reducing the number of relocations in the libraries by compiling into one large static binary and using “protected” symbol exporting.
Fixing what we have
Many of the commits to Qt are fixes for issues as they arise, particularly those which can not be fixed after the release of Qt 5.0 for binary compatibility or stability reasons. These include changes to signatures used with hash functions and more use of C++11 functionality. Simultaneously, many gaps in the documentation are being filled, more unit tests are added, and fixes for new known bugs.
The beta release of Qt 5 will be ready for further testing and evaluation, but it depends mostly on packaging scripts for binary packages being fixed up at the moment. This being summer-time and vacation-time means that progress is not fast.
It will make sense eventually to not build against both Qt 4 and Qt 5 in the same branch. Having a fully ported to Qt 5 codebase with all unit tests passing marks the point where it will start to make sense to use different branches for Qt 4 based and Qt 5 based versions. One consequence of that is to be able to port away from API that is present in Qt 4 but is deprecated in Qt 5.