The version variable that is used to define the packages to download was updated to reflect the new version. A new case was added for the new "Debian11" on "arm64" package which was not a provisioned package on older version but is now provided. As "Debian11" was not currenly loading "libclang.sh", a new script that performs this process was added to "coin/provisioning/qtci-linux-Debian-11.6-aarch64". The newly sourced "libclang.sh" includes "coin/provisiong/common/unix/common.sourced.sh", which sets up certain common variables such as the used architecture and the platform id. When "common.sourced.sh" sets "PROVISION_ARCH", that contains the current platform architecture, it fails if the platform architecture is not supported. For "Debian11" on "arm64", the architecture, as reported by "uname -m" is "aarch64", which is equivalent to "arm64". "aarch64" was not handled by the script, so that a platform with that architecture would result in a fail when sourcing "common.sourced.sh". To avoid the failure, the case that sets "PROVISIONING_ARCH" to "arm64" will not trigger when the reported architecture is "aarch64". The specialized RedHat case was update to work specifically for version 9, to use the new specifically built package for Rhel9.2. The default case, previously using an "ubuntu20.04" package, was modified to use a "Rhel8.8" package. A package for "Ubuntu20.04" is not currently provided anymore as the platform was removed from CI and the new "22.04" package is not compatible with all the platforms that would use it. In particular, the new packages are built on a too new glibc, which will then fail to link, due to undefined symbols in the produced Clang libraries, when used on older-glibc platforms such as "OpenSuse15" and "Rhel8.8". The "Rhel8.8" package was specifically used as the platform for the default package as it ships the older glibc, "2.28", of the supported platforms, which should ensure that it works on the older-version platforms. The "sha1" variables for cached downloads was updated to reflect the new packages. For provisioning on windows, the version variable and the sha1 variables were updated to reflect the new version and the new packages, respectively. Task-number: QTBUG-111580 Task-number: QTBUG-121548 Change-Id: Ie7c1a8d8fe9114912d53a87f70ebfa00341a9d8a Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io> (cherry picked from commit9975595a5e) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit1b97371ea0)
HOW TO BUILD Qt 6
Synopsis
System requirements
- C++ compiler supporting the C++17 standard
- CMake
- Ninja
- Python 3
For more details, see also https://doc.qt.io/qt-6/build-sources.html
Linux, Mac:
cd <path>/<source_package>
./configure -prefix $PWD/qtbase
cmake --build .
Windows:
- Open a command prompt.
- Ensure that the following tools can be found in the path:
- Supported compiler (Visual Studio 2019 or later, or MinGW-builds gcc 11.2 or later)
- Python 3 ([https://www.python.org/downloads/windows/] or from Microsoft Store)
cd <path>\<source_package>
configure -prefix %CD%\qtbase
cmake --build .
More details follow.
Build!
Qt is built with CMake, and a typical
configure && cmake --build . build process is used.
If Ninja is installed, it is automatically chosen as CMake generator.
Some relevant configure options (see configure -help):
-releaseCompile and link Qt with debugging turned off.-debugCompile and link Qt with debugging turned on.
Example for a release build:
./configure -prefix $PWD/qtbase
cmake --build .
Example for a developer build: (enables more autotests, builds debug version of libraries, ...)
./configure -developer-build
cmake --build .
See output of ./configure -help for documentation on various options to
configure.
The above examples will build whatever Qt modules have been enabled by default in the build system.
It is possible to build selected repositories with their dependencies by doing
a ninja <repo-name>/all. For example, to build only qtdeclarative,
and the modules it depends on:
./configure
ninja qtdeclarative/all
This can save a lot of time if you are only interested in a subset of Qt.
Hints
The submodule repository qtrepotools contains useful scripts for
developers and release engineers. Consider adding qtrepotools/bin
to your PATH environment variable to access them.
Building Qt from git
See http://wiki.qt.io/Building_Qt_6_from_Git and README.git for more information. See http://wiki.qt.io/Qt_6 for the reference platforms.
Documentation
After configuring and compiling Qt, building the documentation is possible by running
cmake --build . --target docs
After having built the documentation, you need to install it with the following command:
cmake --build . --target install_docs
The documentation is installed in the path specified with the
configure argument -docdir.
Information about Qt's documentation is located in qtbase/doc/README
Note: Building the documentation is only tested on desktop platforms.