2020-11-05 14:02:44 +01:00
|
|
|
Usage: configure [options] [-- cmake-options]
|
2016-08-10 12:34:24 +02:00
|
|
|
|
2020-11-05 14:02:44 +01:00
|
|
|
This is a convenience script for configuring Qt with CMake.
|
|
|
|
|
Options after the double dash are directly passed to CMake.
|
2024-09-04 09:52:15 +02:00
|
|
|
You can pass CMake variables as configure arguments:
|
|
|
|
|
configure VAR=value
|
|
|
|
|
which is equivalent to
|
|
|
|
|
configure -- -DVAR=value
|
2024-08-29 16:24:27 +02:00
|
|
|
|
2016-08-05 17:58:02 +02:00
|
|
|
Top-level installation directories:
|
|
|
|
|
-prefix <dir> ...... The deployment directory, as seen on the target device.
|
2018-12-11 14:17:05 +01:00
|
|
|
[/usr/local/Qt-$QT_VERSION; qtbase build directory if
|
|
|
|
|
-developer-build]
|
2022-02-22 18:51:16 +01:00
|
|
|
-no-prefix ......... The deployment directory is set to the qtbase build
|
|
|
|
|
directory. Can be used instead of -developer-build
|
|
|
|
|
to not have to install, as well as avoid
|
|
|
|
|
-developer-build's default of -warnings-are-errors.
|
2016-08-05 17:58:02 +02:00
|
|
|
-extprefix <dir> ... The installation directory, as seen on the host machine.
|
|
|
|
|
[SYSROOT/PREFIX]
|
|
|
|
|
|
|
|
|
|
Fine tuning of installation directory layout. Note that all directories
|
2020-11-05 14:02:44 +01:00
|
|
|
except -sysconfdir should be located under -prefix:
|
2016-08-05 17:58:02 +02:00
|
|
|
|
|
|
|
|
-bindir <dir> ......... Executables [PREFIX/bin]
|
|
|
|
|
-headerdir <dir> ...... Header files [PREFIX/include]
|
|
|
|
|
-libdir <dir> ......... Libraries [PREFIX/lib]
|
|
|
|
|
-archdatadir <dir> .... Arch-dependent data [PREFIX]
|
|
|
|
|
-plugindir <dir> ...... Plugins [ARCHDATADIR/plugins]
|
|
|
|
|
-libexecdir <dir> ..... Helper programs [ARCHDATADIR/bin on Windows,
|
|
|
|
|
ARCHDATADIR/libexec otherwise]
|
2019-02-01 11:50:05 +01:00
|
|
|
-qmldir <dir> ......... QML imports [ARCHDATADIR/qml]
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
This change adds a new -sbom configure option to allow generating and
installing an SPDX v2.3 SBOM file when building a qt repo.
The -sbom-dir option can be used to configure the location where
each repo sbom file will be installed.
By default it is installed into
$prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx
which is basically ~/Qt/sbom/qtbase-6.8.0.spdx
The file is installed as part of the default installation rules, but
it can also be installed manually using the "sbom" installation
component, or "sbom_$lower_project_name" in a top-level build. For
example: cmake install . --component sbom_qtbase
CMake 3.19+ is needed to read the qt_attribution.json files for
copyrights, license info, etc. When using an older cmake version,
configuration will error out. It is possible to opt into using an
older cmake version, but the generated sbom will lack all the
attribution file information.
Using an older cmake version is untested and not officially supported.
Implementation notes.
The bulk of the implementation is split into 4 new files:
- QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing
and dispatching the generation of various pieces of the SBOM document
e.g. a SDPX package associated with a target like Core, a SDPX
file entry for each target binary file (per-config shared library,
archive, executable, etc)
- QtPublicSbomGenerationHelpers.cmake - for non-Qt specific
implementation of SPDX generation. This also has some code that was
taken from the cmake-sbom 3rd party project, so it is dual licensed
under the usual Qt build system BSD license, as well as the MIT
license of the 3rd party project
- QtPublicGitHelpers.cmake - for git related features, mainly to embed
queried hashes or tags into version strings, is dual-licensed for
the same reasons as QtPublicSbomGenerationHelpers.cmake
- QtSbomHelpers.cmake - Qt-specific functions that just forward
arguments to the public functions. These are meant to be used in our
Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones
for naming consistency. These function would mostly be used to
annotate 3rd party libraries with sbom info and to add sbom info
for unusual target setups (like the Bootstrap library), because most
of the handling is already done automatically via
qt_internal_add_module/plugin/etc.
The files are put into Public cmake files, with the future hope of
making this available to user projects in some capacity.
The distinction of Qt-specific and non-Qt specific code might blur a
bit, and thus the separation across files might not always be
consistent, but it was best effort.
The main purpose of the code is to collect various information about
targets and their relationships and generate equivalent SPDX info.
Collection is currently done for the following targets: Qt modules,
plugins, apps, tools, system libraries, bundled 3rd party libraries
and partial 3rd party sources compiled directly as part of Qt targets.
Each target has an equivalent SPDX package generated with information
like version, license, copyright, CPE (common vulnerability
identifier), files that belong to the package, and relationships on
other SPDX packages (associated cmake targets), mostly gathered from
direct linking dependencies.
Each package might also contain files, e.g. libQt6Core.so for the Core
target. Each file also has info like license id, copyrights, but also
the list of source files that were used to generate the file and a
sha1 checksum.
SPDX documents can also refer to packages in other SPDX documents, and
those are referred to via external document references. This is the
case when building qtdeclarative and we refer to Core.
For qt provided targets, we have complete information regarding
licenses, and copyrights.
For bundled 3rd party libraries, we should also have most information,
which is usually parsed from the
src/3rdparty/libfoo/qt_attribution.json files.
If there are multiple attribution files, or if the files have multiple
entries, we create a separate SBOM package for each of those entries,
because each might have a separate copyright or version, and an sbom
package can have only one version (although many copyrights).
For system libraries we usually lack the information because we don't
have attribution files for Find scripts. So the info needs to be
manually annotated via arguments to the sbom function calls, or the
FindFoo.cmake scripts expose that information in some form and we
can query it.
There are also corner cases like 3rdparty sources being directly
included in a Qt library, like the m4dc files for Gui, or PCRE2 for
Bootstrap.
Or QtWebEngine libraries (either Qt bundled or Chromium bundled or
system libraries) which get linked in by GN instead of CMake, so there
are no direct targets for them.
The information for these need to be annotated manually as well.
There is also a distinction to be made for static Qt builds (or any
static Qt library in a shared build), where the system libraries found
during the Qt build might not be the same that are linked into the
final user application or library.
The actual generation of the SBOM is done by file(GENERATE)-ing one
.cmake file for each target, file, external ref, etc, which will be
included in a top-level cmake script.
The top-level cmake script will run through each included file, to
append to a "staging" spdx file, which will then be used in a
configure_file() call to replace some final
variables, like embedding a file checksum.
There are install rules to generate a complete SBOM during
installation, and an optional 'sbom' custom target that allows
building an incomplete SBOM during the build step.
The build target is just for convenience and faster development
iteration time. It is incomplete because it is missing the installed
file SHA1 checksums and the document verification code (the sha1 of
all sha1s). We can't compute those during the build before the files
are actually installed.
A complete SBOM can only be achieved at installation time. The install
script will include all the generated helper files, but also set some
additional variables to ensure checksumming happens, and also handle
multi-config installation, among other small things.
For multi-config builds, CMake doesn't offer a way to run code after
all configs are installed, because they might not always be installed,
someone might choose to install just Release.
To handle that, we rely on ninja installing each config sequentially
(because ninja places the install rules into the 'console' pool which
runs one task at a time).
For each installed config we create a config-specific marker file.
Once all marker files are present, whichever config ends up being
installed as the last one, we run the sbom generation once, and then
delete all marker files.
There are a few internal variables that can be set during
configuration to enable various checks (and other features) on the
generated spdx files:
- QT_INTERNAL_SBOM_VERIFY
- QT_INTERNAL_SBOM_AUDIT
- QT_INTERNAL_SBOM_AUDIT_NO_ERROR
- QT_INTERNAL_SBOM_GENERATE_JSON
- QT_INTERNAL_SBOM_SHOW_TABLE
- QT_INTERNAL_SBOM_DEFAULT_CHECKS
These use 3rd party python tools, so they are not enabled by default.
If enabled, they run at installation time after the sbom is installed.
We will hopefully enable them in CI.
Overall, the code is still a bit messy in a few places, due to time
constraints, but can be improved later.
Some possible TODOs for the future:
- Do we need to handle 3rd party libs linked into a Qt static library
in a Qt shared build, where the Qt static lib is not installed, but
linked into a Qt shared library, somehow specially?
We can record a package for it, but we can't
create a spdx file record for it (and associated source
relationships) because we don't install the file, and spdx requires
the file to be installed and checksummed. Perhaps we can consider
adding some free-form text snippet to the package itself?
- Do we want to add parsing of .cpp source files for Copyrights, to
embed them into the packages? This will likely slow down
configuration quite a bit.
- Currently sbom info attached to WrapFoo packages in one repo is
not exported / available in other repos. E.g. If we annotate
WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be
available when looking up WrapZLIB in qtimageformats.
This is because they are IMPORTED libraries, and are not
exported. We might want to record this info in the future.
[ChangeLog][Build System] A new -sbom configure option can be used
to generate and install a SPDX SBOM (Software Bill of Materials) file
for each built Qt repository.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
|
|
|
-sbomdir <dir> ....... Software Bill of Materials (SBOM)
|
|
|
|
|
installation directory [ARCHDATADIR/sbom]
|
2016-08-05 17:58:02 +02:00
|
|
|
-datadir <dir> ........ Arch-independent data [PREFIX]
|
|
|
|
|
-docdir <dir> ......... Documentation [DATADIR/doc]
|
|
|
|
|
-translationdir <dir> . Translations [DATADIR/translations]
|
|
|
|
|
-sysconfdir <dir> ..... Settings used by Qt programs [PREFIX/etc/xdg]
|
|
|
|
|
-examplesdir <dir> .... Examples [PREFIX/examples]
|
|
|
|
|
-testsdir <dir> ....... Tests [PREFIX/tests]
|
2020-11-05 14:02:44 +01:00
|
|
|
-hostdatadir <dir> .... Data used by qmake [PREFIX]
|
2016-08-05 17:58:02 +02:00
|
|
|
|
|
|
|
|
Conventions for the remaining options: When an option's description is
|
|
|
|
|
followed by a list of values in brackets, the interpretation is as follows:
|
|
|
|
|
'yes' represents the bare option; all other values are possible prefixes to
|
|
|
|
|
the option, e.g., -no-gui. Alternatively, the value can be assigned, e.g.,
|
2016-08-30 18:10:41 +02:00
|
|
|
--gui=yes. Values are listed in the order they are tried if not specified;
|
2016-08-05 17:58:02 +02:00
|
|
|
'auto' is a shorthand for 'yes/no'. Solitary 'yes' and 'no' represent binary
|
|
|
|
|
options without auto-detection.
|
|
|
|
|
|
|
|
|
|
Configure meta:
|
|
|
|
|
|
|
|
|
|
-help, -h ............ Display this help screen
|
2022-11-11 14:48:57 +01:00
|
|
|
-redo ................ Re-configure with previously used options. In addition,
|
|
|
|
|
redo removes CMakeCache.txt file and CMakeFiles/ directory
|
|
|
|
|
and recreates them from scratch.
|
2016-07-06 14:41:09 +02:00
|
|
|
Additional options may be passed, but will not be
|
|
|
|
|
saved for later use by -redo.
|
2016-08-05 17:58:02 +02:00
|
|
|
|
2017-02-08 18:46:21 +01:00
|
|
|
-feature-<feature> ... Enable <feature>
|
|
|
|
|
-no-feature-<feature> Disable <feature> [none]
|
2020-11-05 15:50:57 +01:00
|
|
|
-list-features ....... List available features. Note that some features
|
|
|
|
|
have dedicated command line options as well.
|
2017-02-08 19:38:31 +01:00
|
|
|
|
2016-08-05 17:58:02 +02:00
|
|
|
Build options:
|
|
|
|
|
|
2020-07-03 12:25:44 +02:00
|
|
|
-cmake-generator <name> ... Explicitly specify the build system generator for
|
|
|
|
|
CMake instead of auto-detecting one.
|
|
|
|
|
-cmake-use-default-generator ... Turn off auto-detection of the CMake build
|
|
|
|
|
system generator.
|
2021-03-29 16:27:33 +02:00
|
|
|
-cmake-file-api ...... Let CMake store build metadata for loading the build
|
|
|
|
|
into an IDE. [no; yes if -developer-build]
|
2020-11-02 15:26:24 +01:00
|
|
|
-no-guess-compiler ... Do not guess the compiler from the target mkspec.
|
CMake: Unify CMAKE_BUILD_TYPE behavior on all platforms
Before this change, we had the following behaviors.
On platforms other than Windows-MSVC:
- when no build type was specified, we defaulted to Release
- when -developer-build was specified, we defaulted to Debug
- regardless of platform, unless the option was explicitly specified,
we never defaulted to -debug-and-release.
On Windows-MSVC, we always defaulted to Debug. Which is inconsistent
with the rules above.
The difference happens because CMake always sets CMAKE_BUILD_TYPE to
Debug during the first project() call when targeting the Windows-MSVC
platform.
We interpreted that as the user setting the build type, and thus we
didn't want to override what the user specified.
After this change, if we detect that it's cmake setting the build
type, we assign a build type that follows the non-Windows-MSVC rules.
This change unifies the behavior across all platforms.
Adjusted the configure help with the new reality.
Augments 33af62db3747bb6fcb7490ef2d2abc5bb53925b6
[ChangeLog][configure] When no explicit build type is specified,
Windows will now default to building Release like the other
platforms.
Pick-to: 6.5 6.6
Change-Id: Id2bf269c51cf300ec09751ece2ad721869e0f90c
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-06-02 16:22:39 +02:00
|
|
|
-release ............. Build Qt with optimizations and without debug
|
|
|
|
|
symbols [yes]
|
|
|
|
|
Note that -developer-build implies -debug unless
|
|
|
|
|
-release is also explicitly specified
|
|
|
|
|
-debug ............... Build Qt without optimizations and with debug symbols
|
|
|
|
|
[no]
|
|
|
|
|
-debug-and-release ... Build two versions of Qt in one build tree [no]
|
2016-11-17 15:01:59 +01:00
|
|
|
-optimize-debug ...... Enable debug-friendly optimizations in debug builds
|
2017-11-21 20:42:51 +01:00
|
|
|
[auto] (Not supported with MSVC or Clang toolchains)
|
2017-04-07 15:49:10 +02:00
|
|
|
-optimize-size ....... Optimize release builds for size instead of speed [no]
|
2016-08-05 17:58:02 +02:00
|
|
|
-force-debug-info .... Create symbol files for release builds [no]
|
|
|
|
|
-separate-debug-info . Split off debug information to separate files [no]
|
2018-03-14 16:01:59 +01:00
|
|
|
-gdb-index ........... Index the debug info to speed up GDB
|
|
|
|
|
[no; auto if -developer-build with debug info]
|
2018-04-10 15:03:11 +02:00
|
|
|
-gc-binaries ......... Place each function or data item into its own section
|
|
|
|
|
and enable linker garbage collection of unused
|
|
|
|
|
sections. [auto for static builds, otherwise no]
|
2016-08-05 17:58:02 +02:00
|
|
|
-force-asserts ....... Enable Q_ASSERT even in release builds [no]
|
|
|
|
|
-developer-build ..... Compile and link Qt for developing Qt itself
|
CMake: Unify CMAKE_BUILD_TYPE behavior on all platforms
Before this change, we had the following behaviors.
On platforms other than Windows-MSVC:
- when no build type was specified, we defaulted to Release
- when -developer-build was specified, we defaulted to Debug
- regardless of platform, unless the option was explicitly specified,
we never defaulted to -debug-and-release.
On Windows-MSVC, we always defaulted to Debug. Which is inconsistent
with the rules above.
The difference happens because CMake always sets CMAKE_BUILD_TYPE to
Debug during the first project() call when targeting the Windows-MSVC
platform.
We interpreted that as the user setting the build type, and thus we
didn't want to override what the user specified.
After this change, if we detect that it's cmake setting the build
type, we assign a build type that follows the non-Windows-MSVC rules.
This change unifies the behavior across all platforms.
Adjusted the configure help with the new reality.
Augments 33af62db3747bb6fcb7490ef2d2abc5bb53925b6
[ChangeLog][configure] When no explicit build type is specified,
Windows will now default to building Release like the other
platforms.
Pick-to: 6.5 6.6
Change-Id: Id2bf269c51cf300ec09751ece2ad721869e0f90c
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-06-02 16:22:39 +02:00
|
|
|
(exports for auto-tests, extra checks, implies
|
|
|
|
|
-no-prefix, etc.) [no]
|
2016-08-05 17:58:02 +02:00
|
|
|
|
|
|
|
|
-shared .............. Build shared Qt libraries [yes] (no for UIKit)
|
|
|
|
|
-static .............. Build static Qt libraries [no] (yes for UIKit)
|
|
|
|
|
-framework ........... Build Qt framework bundles [yes] (Apple only)
|
|
|
|
|
|
2020-11-05 14:02:44 +01:00
|
|
|
-platform <target> ... Select mkspec for the qmake companion files
|
|
|
|
|
-device <name> ....... Select devices/mkspec for the qmake companion files
|
2016-08-05 17:58:02 +02:00
|
|
|
-device-option <key=value> ... Add option for the device mkspec
|
|
|
|
|
|
2016-12-03 02:24:55 -08:00
|
|
|
-appstore-compliant .. Disable code that is not allowed in platform app stores.
|
|
|
|
|
This is on by default for platforms which require distribution
|
|
|
|
|
through an app store by default, in particular Android,
|
2020-06-05 09:24:37 +02:00
|
|
|
iOS, tvOS, and watchOS. [auto]
|
2016-12-03 02:24:55 -08:00
|
|
|
|
2024-10-14 17:05:23 +02:00
|
|
|
-sbom ................ Enable generation of Software Bill of Materials (SBOM)
|
|
|
|
|
documents in SPDX tag:value format
|
|
|
|
|
[yes; no for developer builds]
|
|
|
|
|
-sbom-json ........... Enable SBOM generation in SPDX JSON format [auto]
|
|
|
|
|
(if Python dependencies are available)
|
|
|
|
|
-sbom-json-required .. Fails the build if the Python dependencies for JSON
|
|
|
|
|
generation are not found [no]
|
|
|
|
|
-sbom-verify ......... Verify generated SBOM files [auto] (if Python
|
|
|
|
|
dependencies are available)
|
|
|
|
|
-sbom-verify-required Fails the build if the Python dependencies for SBOM
|
|
|
|
|
verification are not found [no]
|
|
|
|
|
|
CMake: Generate an SPDX v2.3 SBOM file for each built repository
This change adds a new -sbom configure option to allow generating and
installing an SPDX v2.3 SBOM file when building a qt repo.
The -sbom-dir option can be used to configure the location where
each repo sbom file will be installed.
By default it is installed into
$prefix/$archdatadir/sbom/$sbom_lower_project_name.sdpx
which is basically ~/Qt/sbom/qtbase-6.8.0.spdx
The file is installed as part of the default installation rules, but
it can also be installed manually using the "sbom" installation
component, or "sbom_$lower_project_name" in a top-level build. For
example: cmake install . --component sbom_qtbase
CMake 3.19+ is needed to read the qt_attribution.json files for
copyrights, license info, etc. When using an older cmake version,
configuration will error out. It is possible to opt into using an
older cmake version, but the generated sbom will lack all the
attribution file information.
Using an older cmake version is untested and not officially supported.
Implementation notes.
The bulk of the implementation is split into 4 new files:
- QtPublicSbomHelpers.cmake - for Qt-specific collecting, processing
and dispatching the generation of various pieces of the SBOM document
e.g. a SDPX package associated with a target like Core, a SDPX
file entry for each target binary file (per-config shared library,
archive, executable, etc)
- QtPublicSbomGenerationHelpers.cmake - for non-Qt specific
implementation of SPDX generation. This also has some code that was
taken from the cmake-sbom 3rd party project, so it is dual licensed
under the usual Qt build system BSD license, as well as the MIT
license of the 3rd party project
- QtPublicGitHelpers.cmake - for git related features, mainly to embed
queried hashes or tags into version strings, is dual-licensed for
the same reasons as QtPublicSbomGenerationHelpers.cmake
- QtSbomHelpers.cmake - Qt-specific functions that just forward
arguments to the public functions. These are meant to be used in our
Qt CMakeLists.txt instead of the public _qt_internal_add_sbom ones
for naming consistency. These function would mostly be used to
annotate 3rd party libraries with sbom info and to add sbom info
for unusual target setups (like the Bootstrap library), because most
of the handling is already done automatically via
qt_internal_add_module/plugin/etc.
The files are put into Public cmake files, with the future hope of
making this available to user projects in some capacity.
The distinction of Qt-specific and non-Qt specific code might blur a
bit, and thus the separation across files might not always be
consistent, but it was best effort.
The main purpose of the code is to collect various information about
targets and their relationships and generate equivalent SPDX info.
Collection is currently done for the following targets: Qt modules,
plugins, apps, tools, system libraries, bundled 3rd party libraries
and partial 3rd party sources compiled directly as part of Qt targets.
Each target has an equivalent SPDX package generated with information
like version, license, copyright, CPE (common vulnerability
identifier), files that belong to the package, and relationships on
other SPDX packages (associated cmake targets), mostly gathered from
direct linking dependencies.
Each package might also contain files, e.g. libQt6Core.so for the Core
target. Each file also has info like license id, copyrights, but also
the list of source files that were used to generate the file and a
sha1 checksum.
SPDX documents can also refer to packages in other SPDX documents, and
those are referred to via external document references. This is the
case when building qtdeclarative and we refer to Core.
For qt provided targets, we have complete information regarding
licenses, and copyrights.
For bundled 3rd party libraries, we should also have most information,
which is usually parsed from the
src/3rdparty/libfoo/qt_attribution.json files.
If there are multiple attribution files, or if the files have multiple
entries, we create a separate SBOM package for each of those entries,
because each might have a separate copyright or version, and an sbom
package can have only one version (although many copyrights).
For system libraries we usually lack the information because we don't
have attribution files for Find scripts. So the info needs to be
manually annotated via arguments to the sbom function calls, or the
FindFoo.cmake scripts expose that information in some form and we
can query it.
There are also corner cases like 3rdparty sources being directly
included in a Qt library, like the m4dc files for Gui, or PCRE2 for
Bootstrap.
Or QtWebEngine libraries (either Qt bundled or Chromium bundled or
system libraries) which get linked in by GN instead of CMake, so there
are no direct targets for them.
The information for these need to be annotated manually as well.
There is also a distinction to be made for static Qt builds (or any
static Qt library in a shared build), where the system libraries found
during the Qt build might not be the same that are linked into the
final user application or library.
The actual generation of the SBOM is done by file(GENERATE)-ing one
.cmake file for each target, file, external ref, etc, which will be
included in a top-level cmake script.
The top-level cmake script will run through each included file, to
append to a "staging" spdx file, which will then be used in a
configure_file() call to replace some final
variables, like embedding a file checksum.
There are install rules to generate a complete SBOM during
installation, and an optional 'sbom' custom target that allows
building an incomplete SBOM during the build step.
The build target is just for convenience and faster development
iteration time. It is incomplete because it is missing the installed
file SHA1 checksums and the document verification code (the sha1 of
all sha1s). We can't compute those during the build before the files
are actually installed.
A complete SBOM can only be achieved at installation time. The install
script will include all the generated helper files, but also set some
additional variables to ensure checksumming happens, and also handle
multi-config installation, among other small things.
For multi-config builds, CMake doesn't offer a way to run code after
all configs are installed, because they might not always be installed,
someone might choose to install just Release.
To handle that, we rely on ninja installing each config sequentially
(because ninja places the install rules into the 'console' pool which
runs one task at a time).
For each installed config we create a config-specific marker file.
Once all marker files are present, whichever config ends up being
installed as the last one, we run the sbom generation once, and then
delete all marker files.
There are a few internal variables that can be set during
configuration to enable various checks (and other features) on the
generated spdx files:
- QT_INTERNAL_SBOM_VERIFY
- QT_INTERNAL_SBOM_AUDIT
- QT_INTERNAL_SBOM_AUDIT_NO_ERROR
- QT_INTERNAL_SBOM_GENERATE_JSON
- QT_INTERNAL_SBOM_SHOW_TABLE
- QT_INTERNAL_SBOM_DEFAULT_CHECKS
These use 3rd party python tools, so they are not enabled by default.
If enabled, they run at installation time after the sbom is installed.
We will hopefully enable them in CI.
Overall, the code is still a bit messy in a few places, due to time
constraints, but can be improved later.
Some possible TODOs for the future:
- Do we need to handle 3rd party libs linked into a Qt static library
in a Qt shared build, where the Qt static lib is not installed, but
linked into a Qt shared library, somehow specially?
We can record a package for it, but we can't
create a spdx file record for it (and associated source
relationships) because we don't install the file, and spdx requires
the file to be installed and checksummed. Perhaps we can consider
adding some free-form text snippet to the package itself?
- Do we want to add parsing of .cpp source files for Copyrights, to
embed them into the packages? This will likely slow down
configuration quite a bit.
- Currently sbom info attached to WrapFoo packages in one repo is
not exported / available in other repos. E.g. If we annotate
WrapZLIB in qtbase with CPE_VENDOR zlib, this info will not be
available when looking up WrapZLIB in qtimageformats.
This is because they are IMPORTED libraries, and are not
exported. We might want to record this info in the future.
[ChangeLog][Build System] A new -sbom configure option can be used
to generate and install a SPDX SBOM (Software Bill of Materials) file
for each built Qt repository.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: I9c730a6bbc47e02ce1836fccf00a14ec8eb1a5f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-03-07 18:02:56 +01:00
|
|
|
|
2020-12-07 10:28:47 +01:00
|
|
|
-qt-host-path <path> . Specify path to a Qt host build for cross-compiling.
|
2016-08-05 17:58:02 +02:00
|
|
|
-qtnamespace <name> .. Wrap all Qt library code in 'namespace <name> {...}'.
|
2024-03-05 11:31:09 +01:00
|
|
|
-qtinlinenamespace ... Make -qtnamespace an inline namespace
|
2020-09-21 15:45:28 +02:00
|
|
|
-qtlibinfix <infix> .. Rename all libQt6*.so to libQt6*<infix>.so.
|
2016-08-05 17:58:02 +02:00
|
|
|
|
2023-09-13 16:31:52 +02:00
|
|
|
-coverage <tool> ..... Instrument with the code coverage tool.
|
2016-08-05 17:58:02 +02:00
|
|
|
-gcov ................ Instrument with the GCov code coverage tool [no]
|
2017-02-01 17:32:13 -02:00
|
|
|
|
|
|
|
|
-trace [backend] ..... Enable instrumentation with tracepoints.
|
2023-11-21 09:54:00 +02:00
|
|
|
Currently supported backends are 'etw' (Windows),
|
|
|
|
|
'lttng' (Linux), 'ctf' (Common Trace Format, cross-platform)
|
|
|
|
|
or 'yes' for auto-detection. [no]
|
2017-02-01 17:32:13 -02:00
|
|
|
|
2019-11-01 13:21:33 +01:00
|
|
|
-sanitize {address|thread|memory|fuzzer-no-link|undefined}
|
2016-08-05 17:58:02 +02:00
|
|
|
Instrument with the specified compiler sanitizer.
|
2018-01-11 12:26:32 +01:00
|
|
|
Note that some sanitizers cannot be combined;
|
|
|
|
|
for example, -sanitize address cannot be combined with
|
|
|
|
|
-sanitize thread.
|
2016-08-05 17:58:02 +02:00
|
|
|
|
|
|
|
|
-mips_dsp/-mips_dspr2 Use MIPS DSP/rev2 instructions [auto]
|
|
|
|
|
|
|
|
|
|
-qreal <type> ........ typedef qreal to the specified type. [double]
|
|
|
|
|
Note: this affects binary compatibility.
|
|
|
|
|
|
|
|
|
|
-R <string> .......... Add an explicit runtime library path to the Qt
|
|
|
|
|
libraries. Supports paths relative to LIBDIR.
|
|
|
|
|
-rpath ............... Link Qt libraries and executables using the library
|
|
|
|
|
install path as a runtime library path. Similar to
|
|
|
|
|
-R LIBDIR. On Apple platforms, disabling this implies
|
|
|
|
|
using absolute install names (based in LIBDIR) for
|
|
|
|
|
dynamic libraries and frameworks. [auto]
|
|
|
|
|
|
|
|
|
|
-reduce-exports ...... Reduce amount of exported symbols [auto]
|
2016-08-01 12:40:03 +02:00
|
|
|
-reduce-relocations .. Reduce amount of relocations [auto] (Unix only)
|
|
|
|
|
|
|
|
|
|
-plugin-manifests .... Embed manifests into plugins [no] (Windows only)
|
|
|
|
|
-static-runtime ...... With -static, use static runtime [no] (Windows only)
|
2016-08-05 17:58:02 +02:00
|
|
|
|
|
|
|
|
-pch ................. Use precompiled headers [auto]
|
|
|
|
|
-ltcg ................ Use Link Time Code Generation [no]
|
Add hardening build options
This commit enables hardened-specific checks and codegen, inspired by
GCC 14's -fhardened command line switch and LLVM/libc++'s hardened
modes.
We enable (depending on compiler capabilities):
* -ftrivial-auto-var-init=pattern;
* -fstack-protector-strong;
* -fstack-clash-protection;
* -fcf-protection=full or /CETCOMPAT;
* -D_FORTIFY_SOURCE=3 or 2 on Glibc, depending on the Glibc version,
provided that some optimization level is enabled (release build or
optimized debug build);
* on libstdc++, -D_GLIBCXX_ASSERTIONS;
* on libc++, -D_LIBCPP_HARDENING_MODE set to
_LIBCPP_HARDENING_MODE_EXTENSIVE in debug and to
_LIBCPP_HARDENING_MODE_FAST in release (_DEBUG is too slow);
* -Wl,-z,relro,-z,now.
This aligns us 100% with -fhardened (we already pass -fPIE and -pie
anyhow). Some Linux distributions already ship GCC/Clang with some of
these options enabled by default.
The check for Intel CET has been amended to always test if the compiler
supports the corresponding flag; and, if so, enable the feature. Before,
it was behind a configure option and the test only checked if the
compiler had CET support automatically active (the test didn't pass
-fcf-protection to the compiler).
The check for -fstack-protector-strong has been made general (rather
than QNX-specific). We don't support QNX < 7 anyhow.
Finally, the qt_config_linker_supports_flag_test test has been
amended to also support MSVC.
All of the hardening options are enabled by default.
[ChangeLog][Build System] Qt builds by default in "hardened mode",
meaning that a series of security-related compiler options are
automatically enabled. In the unlikely case in which these options
constitute an unacceptable performance hit, it is possible to disable
individual hardening options when configuring Qt.
Change-Id: I2c026b0438010ad10d5e7b1136fedf4ae3af8822
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2024-03-06 16:22:12 +01:00
|
|
|
-intelcet ............ Use Intel Control-flow Enforcement Technology [auto]
|
|
|
|
|
-glibc-fortify-source Use Glibc function fortification [auto]
|
|
|
|
|
-trivial-auto-var-init-pattern
|
|
|
|
|
Use -ftrivial-auto-var-init=pattern [auto]
|
|
|
|
|
-stack-protector ..... Use -fstack-protector-strong [auto]
|
|
|
|
|
-stack-clash-protection
|
|
|
|
|
Use -fstack-clash-protection [auto]
|
|
|
|
|
-libstdcpp-assertions Use libstdc++ assertions [auto]
|
|
|
|
|
-libcpp-hardening .... Use libc++ hardening [auto]
|
|
|
|
|
-relro-now-linker .... Use -z relro -z now when linking [auto]
|
2022-03-29 23:18:34 +09:00
|
|
|
-linker [bfd,gold,lld,mold]
|
|
|
|
|
Force use of the GNU ld, GNU gold, LLVM/LLD or mold
|
|
|
|
|
linker instead of default one (GCC and clang only)
|
2017-06-02 14:08:32 +02:00
|
|
|
-ccache .............. Use the ccache compiler cache [no] (Unix only)
|
2023-02-08 12:08:37 +01:00
|
|
|
-unity-build ......... Enable Unity (Jumbo) build
|
|
|
|
|
-unity-build-batch-size <int>
|
|
|
|
|
Maximum number of source files used by the unity build
|
2023-07-18 16:51:07 +02:00
|
|
|
to create unity source files [32]
|
2016-08-05 17:58:02 +02:00
|
|
|
|
|
|
|
|
-warnings-are-errors . Treat warnings as errors [no; yes if -developer-build]
|
|
|
|
|
|
2022-08-16 13:02:27 +02:00
|
|
|
-disable-deprecated-up-to <version>
|
|
|
|
|
Set the QT_DISABLE_DEPRECATED_UP_TO value to <version>.
|
|
|
|
|
QT_DISABLE_DEPRECATED_UP_TO is used to remove
|
|
|
|
|
deprecated methods from both API and ABI.
|
|
|
|
|
<version> is a hex value, for example 0x060500 can be
|
|
|
|
|
used to remove all code deprecated in Qt 6.5.0 or
|
|
|
|
|
earlier releases.
|
|
|
|
|
By default <version> is set to 0x040000 and 0x050000 on
|
|
|
|
|
Windows, and non-Windows respectively.
|
|
|
|
|
|
2016-08-05 17:58:02 +02:00
|
|
|
Build environment:
|
|
|
|
|
|
2016-08-01 12:40:03 +02:00
|
|
|
-pkg-config .......... Use pkg-config [auto] (Unix only)
|
2016-08-05 17:58:02 +02:00
|
|
|
|
2023-07-11 14:58:50 +02:00
|
|
|
-vcpkg ............... Use vcpkg [no]
|
2023-06-22 17:38:39 +02:00
|
|
|
|
2016-08-05 17:58:02 +02:00
|
|
|
-D <string> .......... Pass additional preprocessor define
|
|
|
|
|
-I <string> .......... Pass additional include path
|
|
|
|
|
-L <string> .......... Pass additional library path
|
|
|
|
|
-F <string> .......... Pass additional framework path (Apple only)
|
|
|
|
|
|
|
|
|
|
-sdk <sdk> ........... Build Qt using Apple provided SDK <sdk>. The argument
|
|
|
|
|
should be one of the available SDKs as listed by
|
|
|
|
|
'xcodebuild -showsdks'.
|
|
|
|
|
|
|
|
|
|
-android-sdk path .... Set Android SDK root path [$ANDROID_SDK_ROOT]
|
|
|
|
|
-android-ndk path .... Set Android NDK root path [$ANDROID_NDK_ROOT]
|
|
|
|
|
-android-ndk-platform Set Android platform
|
2020-11-12 13:16:47 +02:00
|
|
|
-android-abis ....... Only one ABI can be specified, default is: armeabi-v7a
|
2020-09-16 16:02:08 +03:00
|
|
|
-android-javac-target Set the javac build target version [8]
|
|
|
|
|
-android-javac-source Set the javac build source version [8]
|
2016-08-05 17:58:02 +02:00
|
|
|
-android-style-assets Automatically extract style assets from the device at
|
|
|
|
|
run time. This option makes the Android style behave
|
|
|
|
|
correctly, but also makes the Android platform plugin
|
|
|
|
|
incompatible with the LGPL2.1. [yes]
|
|
|
|
|
|
|
|
|
|
Component selection:
|
|
|
|
|
|
2022-02-02 16:46:49 +01:00
|
|
|
-submodules <repo>[,<repo>] ... Build the listed repositories and those they
|
|
|
|
|
depend on rather than all checked-out repositories.
|
|
|
|
|
The list should be separated with commas, e.g.
|
|
|
|
|
-submodules qtsvg,qtnetworkauth
|
|
|
|
|
[default is to build all checked out repositories]
|
2022-02-02 17:04:44 +01:00
|
|
|
-skip <repo>[,<repo>] Exclude one or more entire repositories from the
|
|
|
|
|
build. The list should be separated with commas.
|
|
|
|
|
e.g. -skip qtimageformats,qtsvg
|
2024-02-07 14:26:45 +01:00
|
|
|
-skip-tests <repo>[,<repo>] ... Skip building tests for one or more
|
|
|
|
|
repositories. The list should be separated with commas.
|
|
|
|
|
e.g. -skip-tests qtimageformats,qtsvg
|
|
|
|
|
-skip-examples <repo>[,<repo>] ... Skip building examples for one or more
|
|
|
|
|
repositories. The list should be separated with commas.
|
|
|
|
|
e.g. -skip-examples qtimageformats,qtsvg
|
2024-02-13 18:48:03 +01:00
|
|
|
-init-submodules ..... When configure is called from the qt git super module,
|
|
|
|
|
it will automatically clone and initialize the
|
|
|
|
|
repositories specified by the -submodules option. When
|
|
|
|
|
no -submodules are specified, and no existing
|
|
|
|
|
submodules are cloned, a default set of submodules
|
|
|
|
|
will be initialized. To adjust other aspects of the
|
|
|
|
|
cloning process, check the init-repository --help
|
|
|
|
|
output for additional options that can be passed
|
|
|
|
|
to configure.
|
2016-08-05 17:58:02 +02:00
|
|
|
-make <part> ......... Add <part> to the list of parts to be built.
|
|
|
|
|
Specifying this option clears the default list first.
|
2021-03-15 17:03:38 +01:00
|
|
|
(allowed values: libs, tools, examples, tests,
|
|
|
|
|
benchmarks, manual-tests, minimal-static-tests)
|
|
|
|
|
[default: libs and examples, also tools if not
|
|
|
|
|
cross-building, also tests if -developer-build]
|
2016-08-05 17:58:02 +02:00
|
|
|
-nomake <part> ....... Exclude <part> from the list of parts to be built.
|
CMake: Allow installation of example sources into the Qt prefix
In Qt 5 times, if Qt was configured with -make examples, running
make install would not only build and install the example binaries,
but would also install the example sources into the prefix.
Installation of example sources was not implemented when the Qt 6
build system has switched to using CMake.
There is still a use case for it though, mainly for Qt Creator, which
only shows the examples of a Qt kit if the sources are available.
In contrast to Qt 5, in Qt 6 we will not install example sources
by default. It will be opt in.
To enable installation of examples sources, configure with
configure -make examples -install-examples-sources
or
cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON
The -make examples part is required, otherwise
-install-examples-sources has no effect.
All example sources can be installed by calling
cmake --install . --component examples_sources
in the qt repo build directory.
In a top-level build, per-repo installation can be done using
cmake --install . --component examples_sources_<repo_name>
where repo_name could be 'qtbase'.
A single example's source can be installed by calling
cmake --install . --component examples_sources_<subdir_name>
where subdir_name is the subdirectory name of the example, e.g.
'gallery'.
Implement installation of example sources by hooking into the
qt_internal_add_example command.
This means that all examples in all repos need to be added via
qt_internal_add_example instead of add_subdirectory, to ensure the
sources are installed. The majority of repos already use it.
For testing purposes one can configure with
-DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON
-DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation
of examples sources without building them.
Take into account an additional variable called
QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of
example sources into a location different from the example binaries.
As a cleanup, the NAME option that could previously be passed to
qt_internal_add_example_external_project has been removed.
That's because it's never used anywhere and could not have worked
anyway because qt_internal_add_example_in_tree never handled it.
Pick-to: 6.6
Fixes: QTBUG-112135
Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 12:15:35 +02:00
|
|
|
-install-examples-sources Installs examples source code into the Qt prefix
|
|
|
|
|
Only possible when -make examples is also passed
|
|
|
|
|
[no]
|
2016-08-05 17:58:02 +02:00
|
|
|
-gui ................. Build the Qt GUI module and dependencies [yes]
|
|
|
|
|
-widgets ............. Build the Qt Widgets module and dependencies [yes]
|
2016-08-01 12:40:03 +02:00
|
|
|
-no-dbus ............. Do not build the Qt D-Bus module
|
|
|
|
|
[default on Android and Windows]
|
2016-08-05 17:58:02 +02:00
|
|
|
-dbus-linked ......... Build Qt D-Bus and link to libdbus-1 [auto]
|
|
|
|
|
-dbus-runtime ........ Build Qt D-Bus and dynamically load libdbus-1 [no]
|
|
|
|
|
-accessibility ....... Enable accessibility support [yes]
|
|
|
|
|
Note: Disabling accessibility is not recommended.
|
|
|
|
|
|
|
|
|
|
Qt comes with bundled copies of some 3rd party libraries. These are used
|
|
|
|
|
by default if auto-detection of the respective system library fails.
|
|
|
|
|
|
2023-09-22 14:10:09 +02:00
|
|
|
-force-bundled-libs .. Only use bundled 3rd party libraries [no]
|
|
|
|
|
-force-system-libs ... Do not use bundled 3rd party libraries [no]
|
|
|
|
|
|
2016-08-05 17:58:02 +02:00
|
|
|
Core options:
|
|
|
|
|
|
|
|
|
|
-doubleconversion .... Select used double conversion library [system/qt/no]
|
|
|
|
|
No implies use of sscanf_l and snprintf_l (imprecise).
|
2016-08-01 12:40:03 +02:00
|
|
|
-glib ................ Enable Glib support [no; auto on Unix]
|
2016-07-14 12:46:44 +02:00
|
|
|
-inotify ............. Enable inotify support
|
2016-08-05 17:58:02 +02:00
|
|
|
-icu ................. Enable ICU support [auto]
|
Add jemalloc support
Large graphical Qt applications heavily rely on heap allocations.
Jemalloc is a general-purpose malloc(3) implementation designed to
reduce heap fragmentation and improve scalability. It also provides
extensive tuning options.
Add a -jemalloc configure option, disabled by default. When enabled, Qt
and user code link to jemalloc, overriding the system's default
malloc().
Add cooperation with jemalloc for some Qt key classes: QArrayData (used
by QByteArray, QString and QList<T>), QBindingStoragePrivate,
QDataBuffer (used by the Qt Quick renderer), QDistanceFieldData,
QImageData, QObjectPrivate::TaggedSignalVector, QVarLengthArray.
This cooperation relies on two jemalloc-specific optimizations:
1. Efficient allocation via fittedMalloc():
Determine the actual allocation size using nallocx(), then adjust the
container’s capacity to match. This minimizes future reallocations.
Note: we round allocSize to a multiple of sizeof(T) to ensure that
we can later recompute the exact allocation size during deallocation.
2. Optimized deallocation via sizedFree():
Use sdallocx(), which is faster than free when the allocation size
is known, as it avoids internal size lookups.
Adapt the QVarLengthArray auto tests on capacity.
Non-standard functions docs are at https://jemalloc.net/jemalloc.3.html
[ChangeLog][QtCore] Added optional support for the jemalloc allocator,
and optimized memory allocations and deallocations in core Qt classes to
cooperate with it.
Change-Id: I6166e64e66876dee22662d3f3ea3e42a6647cfeb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2025-01-24 17:09:58 +01:00
|
|
|
-jemalloc ............ Enable jemalloc support and cooperation [no]
|
2019-01-04 16:26:19 +01:00
|
|
|
-pcre ................ Select used libpcre2 [system/qt/no]
|
2016-08-05 17:58:02 +02:00
|
|
|
-zlib ................ Select used zlib [system/qt]
|
|
|
|
|
|
|
|
|
|
Logging backends:
|
2016-08-01 12:40:03 +02:00
|
|
|
-journald .......... Enable journald support [no] (Unix only)
|
|
|
|
|
-syslog ............ Enable syslog support [no] (Unix only)
|
2016-08-05 17:58:02 +02:00
|
|
|
-slog2 ............. Enable slog2 support [auto] (QNX only)
|
|
|
|
|
|
|
|
|
|
Network options:
|
|
|
|
|
|
|
|
|
|
-ssl ................. Enable either SSL support method [auto]
|
2020-06-05 09:24:37 +02:00
|
|
|
-no-openssl .......... Do not use OpenSSL [default on Apple]
|
2016-08-05 17:58:02 +02:00
|
|
|
-openssl-linked ...... Use OpenSSL and link to libssl [no]
|
|
|
|
|
-openssl-runtime ..... Use OpenSSL and dynamically load libssl [auto]
|
2021-10-06 12:11:32 +02:00
|
|
|
-schannel ............ Use Secure Channel [auto] (Windows only)
|
2016-08-05 17:58:02 +02:00
|
|
|
-securetransport ..... Use SecureTransport [auto] (Apple only)
|
|
|
|
|
|
|
|
|
|
-sctp ................ Enable SCTP support [no]
|
|
|
|
|
|
|
|
|
|
-libproxy ............ Enable use of libproxy [no]
|
|
|
|
|
-system-proxies ...... Use system network proxies by default [yes]
|
|
|
|
|
|
|
|
|
|
Gui, printing, widget options:
|
|
|
|
|
|
2016-08-01 12:40:03 +02:00
|
|
|
-cups ................ Enable CUPS support [auto] (Unix only)
|
2016-08-05 17:58:02 +02:00
|
|
|
|
2024-02-02 15:45:20 +01:00
|
|
|
-emojisegmenter ...... Enable complex emoji sequences [yes]
|
2016-08-01 12:40:03 +02:00
|
|
|
-fontconfig .......... Enable Fontconfig support [auto] (Unix only)
|
2016-08-05 17:58:02 +02:00
|
|
|
-freetype ............ Select used FreeType [system/qt/no]
|
|
|
|
|
-harfbuzz ............ Select used HarfBuzz-NG [system/qt/no]
|
|
|
|
|
(Not auto-detected on Apple and Windows)
|
|
|
|
|
|
|
|
|
|
-gtk ................. Enable GTK platform theme support [auto]
|
|
|
|
|
|
|
|
|
|
-no-opengl ........... Disable OpenGL support
|
|
|
|
|
-opengl <api> ........ Enable OpenGL support. Supported APIs:
|
Remove ANGLE
This marks the end of EGL and OpenGL ES support on Windows.
The concepts of -opengl dynamic, -opengl desktop, QT_OPENGL=software,
etc. remain unchanged, with the exception of the disapperance of
everything ANGLE related.
CMake builds now work identically to qmake on Windows: they default to
'dynamic' OpenGL on Windows, unless -DINPUT_opengl=desktop is specified.
On Windows, Qt 6 is expected to default to the "dynamic" OpenGL model by
default, just like Qt 5.15. This can be changed by switching to "desktop"
OpenGL, which will link to opengl32 (publicly, so other libs and applications
will do so as well) and disallows using another OpenGL DLL.
The "dynamic" mode is essential still because the fallback to a software
rasterizer, such as the opengl32sw.dll we ship with the Qt packages,
has to to work exactly like in Qt 5, the removal of ANGLE does not
change this concept in any way (except of course that the middle option
of using ANGLE is now gone)
When it comes to the windows plugin's OpenGL blacklist feature, it works
like before and accepts the ANGLE/D3D related keywords. They will
then be ignored. Similarly, requesting QT_OPENGL=angle is ignored (but
will show a warning).
The D3D11 and DXGI configure time tests are removed: Qt 5.14 already
depends on D3D 11.1 and DXGI 1.3 headers being available unconditionally
on Win32 (in QRhi's D3D11 backend). No need to test for these.
[ChangeLog][Windows] ANGLE is no longer included with Qt. Dynamic OpenGL
builds work like before but ANGLE is no longer an option. OpenGL proper
or an alternative opengl32 implementation are the two remaining options
now. Attempting to set QT_OPENGL=angle or Qt::AA_UseOpenGLES will have
no effect on Windows.
Fixes: QTBUG-79103
Change-Id: Ia404e0d07f3fe191b27434d863c81180112ecb3b
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
2020-05-18 15:16:30 +02:00
|
|
|
es2, desktop (default on Unix),
|
|
|
|
|
dynamic (Windows only, default on Windows)
|
2016-08-05 17:58:02 +02:00
|
|
|
-opengles3 ........... Enable OpenGL ES 3.x support instead of ES 2.x [auto]
|
2019-08-16 14:26:32 +02:00
|
|
|
-egl ................. Enable EGL support [auto]
|
2016-08-05 17:58:02 +02:00
|
|
|
|
2024-04-11 10:55:53 +02:00
|
|
|
-qpa <qpa1>[;<qpa2>] . Select supported QPA backend(s) (e.g., xcb, cocoa,
|
|
|
|
|
windows). A list separated by semi-colons.
|
|
|
|
|
-default-qpa <name> .. Select the default QPA backend (e.g., xcb, cocoa,
|
|
|
|
|
windows).
|
2016-08-05 17:58:02 +02:00
|
|
|
-xcb-xlib............. Enable Xcb-Xlib support [auto]
|
|
|
|
|
|
|
|
|
|
Platform backends:
|
2016-11-02 10:14:58 +01:00
|
|
|
-direct2d .......... Enable Direct2D support [auto] (Windows only)
|
2016-08-05 17:58:02 +02:00
|
|
|
-directfb .......... Enable DirectFB support [no] (Unix only)
|
2016-08-01 12:40:03 +02:00
|
|
|
-eglfs ............. Enable EGLFS support [auto; no on Android and Windows]
|
2016-08-05 17:58:02 +02:00
|
|
|
-gbm ............... Enable backends for GBM [auto] (Linux only)
|
|
|
|
|
-kms ............... Enable backends for KMS [auto] (Linux only)
|
|
|
|
|
-linuxfb ........... Enable Linux Framebuffer support [auto] (Linux only)
|
3rdparty: remove xcb libs and bump minimal required version to 1.11
With libxcb 1.11 as minimal required version we can:
(a) (Maybe) Enable threaded GL for MESA, see QTBUG-67277.
(b) Avoid performance issues described in QTBUG-46017. Bundled xcb libs don't
contain the more modern SHM fd passing APIs. The official binaries use
"-qt-xcb", therefore we were shipping with the performance fix #ifdef-ed out.
(c) Make xcb-xkb a mandatory dependency avoiding issues described in QTBUG-30911.
Issues that appear when Qt was configure with "-no-xkb -xcb-xlib", but
X server has the XKB extension.
(d) Drop all, but xcb-xinput sources from src/3rdparty/xcb/, for which
we need "xcb-xinput >= 1.12". This way we can reduce maintenance
work. The xcb libraries were origianlly bundled because of lack of availability
on supported distributions. This is not the case anymore:
CI for Qt 5.13 has:
Ubuntu 18.04 - libxcb 1.13
RHEL 7.4 - libxcb 1.13
openSUSE 15.0 - libxcb 1.13
CI for Qt 5.12 has:
Ubuntu 16.04 - libxcb 1.11
RHEL 7.4 - libxcb 1.13
openSUSE 42.3 - libxcb 1.11
RHEL 6.x - not relevant because it was dropped from supported platforms.
Why 1.11 (released on Aug, 2014), but not 1.13 (released on March 2018)?
Based on what we have in CI for 5.13 and 5.14 we could update to 1.13,
but it means that Qt would require a very recent version of 3rd party
dependency.
[ChangeLog][Configure][X11] The minimal required version of libxcb now is 1.11.
[ChangeLog][Third-Party Code][X11] Removed all bundled XCB libs, with
the exception of xcb-xinput, which is not available on systems with
libxcb 1.11.
[ChangeLog][Configure][X11] Removed -qt-xcb, -system-xcb, -xkb, -xcb-xinput switches.
[ChangeLog][Platform Specific Changes][X11] XKB and XInput2 now are mandatory
dependencies for XCB plugin. XCB-XKB is a part of libxcb 1.11 releases.
XCB-XInput is not part of libxcb 1.11 releases, but Qt builders can use
-bundled-xcb-xinput switch.
Fixes: QTBUG-73862
Fixes: QTBUG-73888
Task-number: QTBUG-67277
Task-number: QTBUG-30939
Change-Id: I4c2bd2a0e667220d32fd1fbfa1419c844f17fcce
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2019-02-19 10:09:19 +01:00
|
|
|
-xcb ............... Enable X11 support [auto] (Linux only)
|
2016-08-05 17:58:02 +02:00
|
|
|
|
|
|
|
|
Input backends:
|
2017-11-28 14:11:07 +01:00
|
|
|
-libudev............ Enable udev support [auto]
|
2016-08-05 17:58:02 +02:00
|
|
|
-evdev ............. Enable evdev support [auto]
|
|
|
|
|
-libinput .......... Enable libinput support [auto]
|
|
|
|
|
-mtdev ............. Enable mtdev support [auto]
|
|
|
|
|
-tslib ............. Enable tslib support [auto]
|
3rdparty: remove xcb libs and bump minimal required version to 1.11
With libxcb 1.11 as minimal required version we can:
(a) (Maybe) Enable threaded GL for MESA, see QTBUG-67277.
(b) Avoid performance issues described in QTBUG-46017. Bundled xcb libs don't
contain the more modern SHM fd passing APIs. The official binaries use
"-qt-xcb", therefore we were shipping with the performance fix #ifdef-ed out.
(c) Make xcb-xkb a mandatory dependency avoiding issues described in QTBUG-30911.
Issues that appear when Qt was configure with "-no-xkb -xcb-xlib", but
X server has the XKB extension.
(d) Drop all, but xcb-xinput sources from src/3rdparty/xcb/, for which
we need "xcb-xinput >= 1.12". This way we can reduce maintenance
work. The xcb libraries were origianlly bundled because of lack of availability
on supported distributions. This is not the case anymore:
CI for Qt 5.13 has:
Ubuntu 18.04 - libxcb 1.13
RHEL 7.4 - libxcb 1.13
openSUSE 15.0 - libxcb 1.13
CI for Qt 5.12 has:
Ubuntu 16.04 - libxcb 1.11
RHEL 7.4 - libxcb 1.13
openSUSE 42.3 - libxcb 1.11
RHEL 6.x - not relevant because it was dropped from supported platforms.
Why 1.11 (released on Aug, 2014), but not 1.13 (released on March 2018)?
Based on what we have in CI for 5.13 and 5.14 we could update to 1.13,
but it means that Qt would require a very recent version of 3rd party
dependency.
[ChangeLog][Configure][X11] The minimal required version of libxcb now is 1.11.
[ChangeLog][Third-Party Code][X11] Removed all bundled XCB libs, with
the exception of xcb-xinput, which is not available on systems with
libxcb 1.11.
[ChangeLog][Configure][X11] Removed -qt-xcb, -system-xcb, -xkb, -xcb-xinput switches.
[ChangeLog][Platform Specific Changes][X11] XKB and XInput2 now are mandatory
dependencies for XCB plugin. XCB-XKB is a part of libxcb 1.11 releases.
XCB-XInput is not part of libxcb 1.11 releases, but Qt builders can use
-bundled-xcb-xinput switch.
Fixes: QTBUG-73862
Fixes: QTBUG-73888
Task-number: QTBUG-67277
Task-number: QTBUG-30939
Change-Id: I4c2bd2a0e667220d32fd1fbfa1419c844f17fcce
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2019-02-19 10:09:19 +01:00
|
|
|
-bundled-xcb-xinput Use bundled XInput2 support [auto]
|
2018-11-16 17:07:33 +01:00
|
|
|
-xkbcommon ......... Enable key mapping support [auto]
|
2016-08-05 17:58:02 +02:00
|
|
|
|
|
|
|
|
Image formats:
|
|
|
|
|
-gif ............... Enable reading support for GIF [auto]
|
2016-07-15 16:29:37 +02:00
|
|
|
-ico ............... Enable support for ICO [yes]
|
2016-08-05 17:58:02 +02:00
|
|
|
-libpng ............ Select used libpng [system/qt/no]
|
|
|
|
|
-libjpeg ........... Select used libjpeg [system/qt/no]
|
|
|
|
|
|
|
|
|
|
Database options:
|
|
|
|
|
|
|
|
|
|
-sql-<driver> ........ Enable SQL <driver> plugin. Supported drivers:
|
2023-04-16 13:02:48 +08:00
|
|
|
db2 ibase mysql oci odbc psql sqlite mimer
|
2016-08-05 17:58:02 +02:00
|
|
|
[all auto]
|
2020-01-31 22:02:03 +01:00
|
|
|
-sqlite .............. Select used sqlite [system/qt]
|
