Qt Build System Glossary: Difference between revisions
(Initial revision) |
mNo edit summary |
||
Line 22: | Line 22: | ||
$ cd qt-source-dir | $ cd qt-source-dir | ||
$ ./configure | $ ./configure | ||
$ | $ cmake --build . | ||
$ | $ cmake --install . | ||
</syntaxhighlight> | </syntaxhighlight> |
Revision as of 12:59, 9 December 2020
To be on the same page when talking about Qt build system related topics, we're offering here a collection of used terms.
Build System
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.
Build Tool
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.
In-source Build
This means that your build directory is the same as your source directory.
$ cd qt-source-dir
$ ./configure
$ cmake --build .
$ cmake --install .
Out-of-source Build
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.
Shadow Build
This is just another name for out-of-source build.
Developer 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 .
Prefix Build
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.
Non-prefix Build
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.
Top-level Build
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.
Per-repository Build
This is building Qt's single repositories one by one.
Dependencies have to be resolved by the user doing the build.