Qt Lite

Qt Lite is an initiative driven by The Qt Company striving for smaller and leaner Qt builds. It utilizes the new configuration system introduced with Qt 5.8 to create custom builds stripped of features or classes that aren’t needed for a given application. Focus is mostly on Embedded Linux with the goal of making Qt a feasible option on smaller systems. In this post we will have a look at the current state of affairs and we will provide guidance on how to experiment with Qt Lite on your own.

Qt Lite consists of two parts: The first part are changes to the Qt source code and configuration system itself to allow for compiling certain aspects out. This is part of the Open Source code base. The second part is a UI tool to manage build configurations which is part of “Qt for Device Creation”. In this post we will have a look at the Open Source side of things.

What is available?

Qt Lite defines “features” which can be enabled or disabled. This happens via the regular configure script contained in the Qt source base. Qt 5.9 adds an option for listing all available features. Currently there are around 190 feature switches. Most of these are in qtbase and qtdeclarative. Qt 5.9.1 will make the output more accessible by breaking it down into sections.

The following listing shows the full output of configure --list-features for your convenience.

Some of these features are public features which means that they change the official API of Qt. Compiling an application which uses a public feature that has been disabled will result in a compile error for the C++ side. The QML side requires more care and attention since properties which belong to a disabled feature will only be found at runtime. Private features are parts of Qt that are not directly exposed via an API. The removal of a private feature will typically only be found at runtime. The output of --list-features unfortunately doesn’t differentiate between public or private.

A feature can be disabled via configure with “-no-feature-<name>. Features may have dependencies on other features defined. Disabling a single feature can therefore disable a whole set of dependent features. Example: “-no-feature-abstractslider” will also disable feature-filedialog (via slider → scrollbar → scrollarea → itemviews → listview → combobox). Dealing with these dependencies purely on the commandline takes quite a bit of knowledge about the internals of Qt and is a good reason for tooling support.

Note: ./configure will warn about conflicting -feature/-no-feature combinations, but will not tell about all implicitly disabled features in the configuration summary.

can give you a hint what features (including build dependencies which may have failed tests) you are missing in total.

How to create a minimal build?

Creating a minimal build is currently not for the faint of heart as Qt Lite is still evolving. Due to library dependencies detected on your build machine there might be build errors you have to deal with. There is also the issue that there are no CI builds available for Qt Lite configurations.

While Qt Lite is focused on Embedded Linux, we will do our experiment on a regular Linux Desktop (Ubuntu 16.04) for convenience. The knowledge gained can easily be transferred to an Embedded scenario like Buildroot or OpenEmbedded/Yocto.

To get started prepare a build setup as outlined here. Check out the qt5 git repo. You can set the HEAD to 40b07da1941a66a748c2 which is the commit ID we used when preparing this article (5.9 branch). We concentrate on essential modules and qtquickcontrols2.

First configure a regular build. We pick a release build as it won’t stop because of warnings about unused variables or parameters. We also need to skip tools, tests and examples as these assume full Qt builds. Qt Lite is developed/tested without precompiled headers.

Next we will use ./configure and a bit of shell to create the input for our minimal build configuration.

Disabling the following features will currently break the build:

  • -feature-datestring
  • -feature-freetype
  • -feature-http
  • -feature-properties
  • -feature-temporaryfile
  • -feature-textdate
  • -feature-xmlstream
  • -feature-xmlstreamreader

This will change, but for now be sure to remove the respective -no-feature lines from config.opt before proceeding.

Also remove -no-feature-animation if Qt Quick is required and -no-feature-quick-shadereffect and -no-feature-quick-gridview for Qt Graphical Effects resp. Qt Quick Controls 2.

Likely your application will use plugins (eg for platform integration), so let’s also keep -feature-filesystemiterator and -feature-library.

Handy one-liner for all mentioned features above:

Afterwards run

The result will be a quite minimal build of Qt.

The following table shows what is currently possible (Qt 5.9 branch, 1st of May, release builds, x86_64, installed sizes, GCC 5.4.0). We also list results for Qt 5.8 to show the development trend.

Library
5.8 so
5.8 so min.
5.9 so
5.9 so min.
5.9 diff
libQt5Core 4.9MB 3.6MB 5.2MB (+) 3.4MB -35%
libQt5Gui 5.3MB 4.4MB 5.4MB 4.5MB -16%
libQt5Network 1.6MB 1.2MB 1.6MB 1.2MB -25%
libQt5PrintSupport 453KB 43KB 445KB 43KB -90%
libQt5Qml 4.1MB 3.8MB 4.0MB 3.9MB – 3%
libQt5Quick 4.3MB 2.9MB 4.4MB 3.3MB(*) -25%
libQt5Widgets 6.4MB 1.6MB 6.3MB 1.2MB -81%
libQt5Xml 232KB 123KB 236KB 123KB -48%

(*) With -feature-animation, otherwise Qt Quick is not built in 5.9
(+) Increase caused by inclusion of private pcre copy

This of course comes at a price: For a lot of applications such a minimal Qt will be useless due to missing functionality. So the list of removed features needs to be reviewed. And you might need to add things back if it turns out that they are required by the application. For a newly developed project this can be done in lock step with the development of the application itself. For an existing project it’s most likely not a good idea to start out with a minimal build. Here it makes more sense to look for big features that can be removed one by one without breaking the application.

For evaluation of static space savings we took basysKom’s QMLSDR (software defined radio) showcase. Its static binary size could be reduced from 27MB to 21MB (22% off) by using only the minimum required feature set (including settings, translations, quick-itemviews, quick-shadereffect and Qt Quick Templates).

Conclusion

The current state of Qt Lite shows its potential for reducing the size of Qt as well as the challenges ahead. Having unit tests for the Qt Lite subset would help to ensure that the resulting builds work as intended. Adding CI support would help to hunt down permutations of feature switches that don’t compile. Resolving dependencies without tool support takes knowledge about the internals of Qt. Consider what is available with Qt for Device Creation.

We are looking forward to a smaller Qt for embedded (and mobile) applications.

(This article has been written by Stephan and Frank)

Leave a Reply

Your email address will not be published. Required fields are marked *