Qt Build System Glossary
To be on the same page when talking about Qt build system related topics, we're offering here a collection of used terms.
- 1 Build System
- 2 Build Tool
- 3 Build System Generator
- 4 In-source Build
- 5 Out-of-source Build
- 6 Shadow Build
- 7 Developer Build
- 8 Prefix Build
- 9 Non-prefix Build
- 10 Top-level Build
- 11 Per-repository Build
- 12 debug-and-release build
- 13 Framework Build
- 14 Documentation-only Build
- 15 Qt tests
- 16 qmake trace file
- 17 CMake trace file
- 18 Repo Target Sets
The build system of Qt is the collection of files that describe how to build Qt from source.
This includes, among others, the project files and all configure-related files.
It does not include QMake, CMake, make or ninja.
In the widest sense, those are tools that contribute to the build.
Common build tools are ninja, make, nmake and jom.
We can count build system generators to the the build tools.
Build System Generator
Build system generators are tools that take a high-level project description as input (e.g. a qmake project file) and output a lower level build system (e.g. a Makefile). Examples are QMake, CMake, gyp or gn.
This means that your build directory is the same as your source directory. This is also called in-tree build.
$ cd qt-source-dir $ ./configure $ cmake --build . $ cmake --install .
This means that your build directory is outside your source directory.
$ mkdir qt-build-dir $ cd qt-build-dir $ ../qt-source-dir/configure $ cmake --build . $ cmake --install .
This has the advantage that you can have multiple builds of the same source.
Also, it's very easy to do a fresh build by purging your build directory.
This is just another name for out-of-source build.
A developer build of Qt is meant for developers of Qt.
It differs from a non-developer build in two details:
- It's a non-prefix build if the -prefix configure option is omitted. See below for non-prefix builds.
- It enables private tests. Those are autotests that require symbols to be exported that would be hidden under normal circumstances.
$ mkdir qt-build-dir $ cd qt-build-dir $ ../qt-source-dir/configure -developer-build $ cmake --build .
It's perfectly possible to have a developer prefix build:
$ mkdir qt-build-dir $ cd qt-build-dir $ ../qt-source-dir/configure -developer-build -prefix ~/Qt $ cmake --build . $ cmake --install .
This means that you configured Qt with an installation prefix.
$ mkdir qt-build-dir $ cd qt-build-dir $ ../qt-source-dir/configure -prefix /opt/qt6 $ cmake --build . $ cmake --install .
Prefix builds require that you install after building.
Note that, by default, configure uses /usr/local as installation prefix. Unless -developer-build is specified. See below.
This means that you configured Qt without an installation prefix.
This is only possible for developer builds.
$ mkdir qt-build-dir $ cd qt-build-dir $ ../qt-source-dir/configure -developer-build $ cmake --build .
There's no point in installing a non-prefix build.
Technically, the install prefix is set to the build dir, and care is taken by the build system that the necessary files are copied/built into the right place.
As you probably know, Qt is split into several repositories: qtbase, qtdeclarative, qttools and so on. There's also a "super" repository called "qt5" that bundles everything as git submodules.
A top-level build means building the "super" repository.
Dependencies between the single repositories are automatically resolved by the build system.
This is building Qt's single repositories one by one.
Dependencies have to be resolved by the user doing the build.
Per-repository builds can be configured as either prefix or non-prefix builds.
An out-of-source non-prefix build example:
$ mkdir qtbase-build-dir $ cd qtbase-build-dir $ ../qtbase-source-dir/configure -developer-build $ cmake --build . $ cd .. $ mkdir qtdeclarative-build-dir $ cd qtdeclarative-build-dir $ ../qtbase-build-dir/bin/qt-configure-module ../qtdeclarative $ cmake --build . # Repeat for other needed repositories
An out-of-source prefix build example:
$ mkdir qtbase-build-dir $ cd qtbase-build-dir $ ../qtbase-source-dir/configure -prefix /opt/qt6 $ cmake --build . $ cmake --install . $ cd .. $ mkdir qtdeclarative-build-dir $ cd qtdeclarative-build-dir $ /opt/qt6/bin/qt-configure-module ../qtdeclarative $ cmake --build . $ cmake --install . # Repeat for other needed repositories
This means that Qt (or some other project) is configured for building the Debug and Release configurations in the same build directory.
QMake has in-built support for that. Out of the box, two fixed configs are available: debug and release.
For CMake projects, Multi-Config generators (e.g. Ninja Multi-Config) support the build of multiple configurations per build directory.
On Apple platforms, the Qt libraries are built by default as frameworks.
The <install-prefix>/lib/Qt6Core.framework then contains the library and all related header files.
Qt can also be configured as non-framework build by passing -no-framework to configure.
In this case, <install-prefix>/lib contains the libraries as .dylib files, and the header files are placed below <install-prefix>/include.
Packagers usually build Qt per repo, but the documentation must be built from the full Qt source archive to ensure that inter-repo links are set up correctly. When building the documentation, it's desirable to avoid building tools and re-use to tools of an existing Qt build.
Prior to configuring, make sure you have LLVM/libclang v10.0+ installed and LLVM_INSTALL_DIR set to the base of the installation. This is required to build the qdoc tool which is required for building documentation.
One now can do a documentation-only build by configuring Qt like this:
cmake /path/to/Qt/source -GNinja -DQT_HOST_PATH=/path/to/Qt/installation ...other flags...
and build the documentation with
Introduced in https://codereview.qt-project.org/c/qt/qtbase/+/346155
To just build the documentation for one module after you have built it for all modules once:
For example, to build the docs for the qtdoc module, enter:
Starting with Qt 6, Qt's tests can be built in a few ways:
- all tests defined in a repository are built in-tree with the Qt build directory (henceforth called 'in-tree')
- all tests defined in a repository are built in a standalone build directory (called 'standalone tests')
- one specific test is built in a standalone build directory (called 'standalone test')
To build tests in-tree with the Qt build itself, you need to pass the following configure argument when configuring Qt
$ mkdir qt-build-dir $ cd qt-build-dir $ ../qt-source-dir/configure -make tests $ cmake --build . $ ctest # to run the tests
The advantage of this approach is that you can build and run the tests from the same build directory as your Qt build directory. The disadvantage is that configuration time and total build time will be longer.
To build standalone tests in a separate build directory you first need to build at least qtbase, and then you need to use a special shell script provided by the qtbase installation:
$ mkdir qt-build-dir $ cd qt-build-dir $ ../qt-source-dir/configure -developer-build $ cmake --build . $ cd .. $ mkdir qtbase-standalone-tests $ cd qtbase-standalone-tests $ ../qt-build-dir/bin/qt-internal-configure-tests ../qt-source-dir $ cmake --build . $ ctest # to run the tests
The advantage of this approach is that you can build and run the tests from a separate build directory, without affecting overall Qt build times. This approach is what Qt's CI is currently using. The disadvantage is that you have to go through a few steps more than usual.
Single standalone test
Sometimes you just want to build one single test, outside your Qt build directory. You can do that with a special 'qt-cmake-standalone' shell script.
$ mkdir qt-build-dir $ cd qt-build-dir $ ../qt-source-dir/configure -developer-build $ cmake --build . $ cd .. $ mkdir tst_qwidget-build-dir $ cd tst_qwidget-build-dir $ ../qt-build-dir/bin/qt-cmake-standalone-test ../qt-source-dir/tests/auto/widgets/kernel/qwidget $ cmake --build . $ ctest # to run the test
The advantage of this approach is that the configuration time and build time of one test is very fast.
qmake trace file
A qmake trace file for a qmake-based project is produced by passing three -d arguments to qmake:
$ qmake /my/project/sources -d -d -d >qmake.trace 2>&1
CMake trace file
A CMake trace file for a CMake-based project is produced like this:
$ cmake /my/project/sources --trace-expand --trace-redirect=cmake.trace
For a Qt build you would do
$ configure ...more options... -- --trace-expand --trace-redirect=cmake.trace
Repo Target Sets
A repo target set is a named set of targets within a Qt repository. One can build a repo target set by passing QT_BUILD_SINGLE_TARGET_SET=target-set-name to cmake when configuring the Qt repository.
The concept was introduced by this change for aiding building conan packages, but it may be useful for any kind of Qt distribution that wishes to create packages of a finer granularity than Qt repository level.
Repo target sets are defined in the top-level CMakeLists.txt of a repository. The definitions must be followed by a call to qt_internal_prepare_single_repo_target_set_build().
Let's walk through what has been done for the qtscxml repository.
# CMakeLists.txt # Define the repo target set "qtscxml". # That matches the conan package name but can be an arbitrary string. qt_internal_define_repo_target_set(qtscxml) # Define the repo target set "qtscxmlqml". # The target ScxmlQml will be part of this set, and building it requires a call to # find_package(Qt6 COMPONENTS Scxml). # Denote this requirement with the DEPENDS argument. qt_internal_define_repo_target_set(qtscxmlqml DEPENDS Scxml) qt_internal_prepare_single_repo_target_set_build()
By now, all those repo target sets contain all targets of the repository. We now assign every module, plugin and tool to its target set.
# src/scxml/CMakeLists.txt qt_internal_include_in_repo_target_set(qtscxml) qt_internal_add_module(Scxml ...
# src/scxmlqml/CMakeLists.txt qt_internal_include_in_repo_target_set(qtscxmlqml) qt_internal_add_qml_module(ScxmlQml ...
qt_internal_include_in_repo_target_set operates on file level and simply skips the rest of the file if we're currently building a repo target set that does not match.