Emit a warning if `FEATURE_*` variable is set. The "feature" is not
registered as a true feature after deprecation.
Pick-to: 6.8
Change-Id: I715af231c228c73d70b037ee31aa61edcd45c21e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 618053e27907369c92fbf5aac37ced07fb6e16c6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 17c522418466a53b9fb7ea7bc1c8d4aa90692e4f)
Unlike chaining a feature into its `CONDITION`, it has a guaranteed
one-to-one equivalence with the original target.
- An alias cannot be set if the main feature is already set
- Multiple aliases of a feature cannot be set at the same time
Pick-to: 6.8
Change-Id: I5b17ec3af51761880a7edb0c47ad8144815f1f93
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 4bbd324a0a4a488b9ff4272888cc6b7f516d78ff)
It usage of libc++ was never detected if the compiler was explicitly set
to a specific clang binary and clang wrapper.
Change-Id: I5fd3c84223cafedf06b34afe91d975e71c199e24
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
(cherry picked from commit 982fe396e5908a6f1089ba577ed6220d90eaaa95)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Currently there're two FFmpeg-specific CMake arguments used by
Qt Multimedia to enable building with FFmpeg support:
- FFMPEG_DIR: Specifies the directory path of the FFmpeg development
libraries. The new -ffmpeg-dir configure option maps to this variable.
- QT_DEPLOY_FFMPEG: Determines whether FFmpeg binaries should be copied
to Qt's install directory. The new -ffmpeg-deploy configure option maps
to this variable.
[ChangeLog][configure] `-DFFMPEG_DIR=<dir>` and `-DQT_DEPLOY_FFMPEG=ON`
can now be set via `-ffmpeg-dir <dir>` and `-ffmpeg-deploy` respectively.
Change-Id: Iaff4da99be2682730653178e3b3fef46cfa0bc63
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Artem Dyomin <artem.dyomin@qt.io>
qt_config_compile_test doesn't run the compile test immediately anymore
but just defines the test. Compile tests defined with this function are
run only if their value TEST_${name} is requested in a feature's
condition variable (EMIT_IF, CONDITION, ENABLE, ...).
If you need the TEST_${name} variable regardless of any feature
conditions, call qt_run_config_compile_test right after
qt_config_compile_test.
This avoids having e.g. Windows-specific compile tests on Linux (and
vice versa) and speeds configuration up a bit.
Fixes: QTBUG-115705
Task-number: QTBUG-107248
Change-Id: I38c4d2a48b1e5dc2f5133e0ad507ede0520ca3b8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Adds loongarch simd extension(LSX LASX) configure test and
-feature-lsx and -feature-lasx configure options.
Add detection of LSX and LASX at run-time in qsimd.cpp.
Change-Id: I63eab2f4f45c306b672a89b376e0cbc01da0df83
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Previously SBOM generation was opt-in.
This patch changes the generation of the plain-text tag:value SBOM
to be enabled by default, except for:
- developer builds
- no-prefix builds
- standalone tests or examples
- cmake build tests
The JSON SBOM generation and the verification steps have also been
changed to be enabled by default, but only if the Python dependencies
can be found. If the dependencies are not found, the build will
skip the generation and verification steps.
Four new configure options have been added to control these aspects:
-(no-)sbom-json: Allows explicitly enabling or disabling JSON SBOM
generation
-(no-)sbom-json-required: Fails the build if JSON SBOM generation
Python dependencies are not found
-(no-)sbom-verify: Allows explicitly enabling or disabling SBOM
verification
-(no-)sbom-verify-required: Fails the build if SBOM verification
Python dependencies are not found
There are corresponding CMake variables for each of the configure
options, see the cmake mapping document.
[ChangeLog][Build Systems] SBOM generation is now enabled by default,
when building Qt, except for developer builds and no-prefix builds.
JSON SBOM generation is enabled by default if the required Python
dependencies are available.
Pick-to: 6.8
Task-number: QTBUG-122899
Change-Id: I6dbe1869f8342154a89ff2ab84ac53c9ef1b2eb7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We had no routines for checking compiler support instead only compiler
currently enabled.
Change-Id: I5543e4cff2b0bab494e11abf257061147baaf0d7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Commit ae64c54f8cc2491988241a7433f5e8cfc6016ab4 broke configure
arguments like
--webengine-jumbo-build=20.
That commit transforms the argument to
-webengine-jumbo-build=20
but single-hyphen arguments take values without an equal sign.
We need to store the unaltered argument (with the two hyphens) for
further handling instead of the single-hyphen variant.
Pick-to: 6.8
Fixes: QTBUG-126872
Change-Id: I243eb072dfe5535a648bd78bb3aeb3b9e0e4ede0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
Parse the -qpa configure argument as list and translate it to the
QT_QPA_PLATFORMS cmake variable. This variable is new to the Qt build
procedure. The QT_QPA_DEFAULT_PLATFORM variable supposed to get
multiple values, but this didn't work at all, since the variable value
then was used in the compile definition that is expected to be a single
value QPA platfrom definition. This inconsistency forced to introduce
a new variable.
The QT_QPA_DEFAULT_PLATFORM variable now controls the first-choice QPA
plugin for the GUI applications. The new configure argument
-default-qpa is now translated to the QT_QPA_DEFAULT_PLATFORM variable
instead the of -qpa one. The -qpa configure argument is now translated
to the QT_QPA_PLATFORMS variable, which is new one as well. The
variable contains the list of QPA plugins that are "default" for this
Qt configuration. The meaning of the "default" plugins is related to
the DEFAULT_IF argument of qt_internal_add_plugin command. Plugins
that are listed in the QT_QPA_PLATFORMS variable will be treated as
default by the build system and will be deployed within user
applications when using deployment API or linked statically when using
static Qt.
The QT_QPA_DEFAULT_PLATFORM falls back to the QT_QPA_PLATFORMS first
value in the list if it's not set explicitly and either
'-DQT_QPA_PLATFORMS' or '-qpa' arguments are specified.
[ChangeLog][CMake] Added QT_QPA_PLATFORMS variable which controls the
list of QPA plugins that will be deployed within the applications by
default.
[ChangeLog][CMake] The '-qpa' configure argument now is mapped to the
QT_QPA_PLATFORMS variable and has different functionality. It doesn't
control the platform plugin that the GUI application is using by
default, but controls the list of QPA plugins that will be deployed
within the applications by default.
[ChangeLog][CMake] Added '-default-qpa' argument which replaces the
'-qpa' one. The argument is translated to the QT_DEFAULT_QPA_PLATFORM
CMake variable and selects the default platform that should be used
by GUI application if QT_QPA_PLATFORM environment variable is not set.
Task-number: QTBUG-124265
Task-number: QTBUG-87805
Task-number: QTBUG-124449
Change-Id: Ibcebaccc535aaed6374f15ccfeddb3e6128f5ce0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We never properly handled double-hyphen arguments like --list-features.
However --developer-build worked by accident, because it did set
INPUT_developer_build implicitly.
Now, we don't automagically translate INPUT_foo to FEATURE_foo anymore,
and --developer-build stopped working.
Fix this by consistently handling -foo and --foo arguments.
Change-Id: Ibf32979b419c28e0a8e1f810f03ae3f295b14c69
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
'headersclean' shoudn't be a feature. The respective flag should behave
like command-line switch that affects the only repo that it was passed
for. This also avoids propagating of the headersclean feature between
the different repos when qtbase was built with the headerclean enabled.
Fixes: QTBUG-121722
Change-Id: I304cbc980b06030513c015a2016678a6a0965fed
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Inline namespaces serve the purpose for which the original
-qtnamespace option was added and allow for macro simplification (no
need for any using directives). This makes it possible to use
namespaced builds of Qt also for Qt for Python and similar use cases
which have issues with the additional namespace.
[ChangeLog][QtCore] It is now possible to use an inline namespace for
-qtnamespace (option -qtinlinenamespace).
Task-number: PYSIDE-2590
Change-Id: Ia0cecf041321933a2e02d1fd8ae0e9cda699cd1e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
These options are declared with TYPE enum and a MAPPING that's supposed
to control the feature 'system-zlib' or 'system-sqlite'. Since only
inputs of type boolean control features now, we need to somehow declare
that this non-boolean input controls a feature.
We do this by adding the keyword CONTROLS_FEATURE to
qt_commandline_option. For example,
qt_commandline_option(zlib
CONTROLS_FEATURE
TYPE enum
NAME system-zlib
MAPPING system yes qt no
)
declares
- commandline option "zlib" sets the input "system-zlib",
because of the "NAME system-zlib" argument
- accepted input values are "system" and "qt", because
we have "TYPE enum" and the odd values of MAPPING
- those values are translated to yes/no, because of the
even values of MAPPING
- CONTROLS_FEATURE forces the translated input's type
to boolean, and with that it will set the corresponding
feature 'system-zlib'
Luckily, only qtbase has command line options with MAPPING declared.
Change-Id: I82d06cec43ece3b002c8f5dd414c68dc730909af
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends commit 110f656da9e9b2511c89679e79b197a3e7b07393.
Command line options with a TYPE that denotes a custom command line
argument handler cannot set a feature "foo" anymore by just setting
INPUT_foo to "yes". Instead, they must use the newly introduced
functions qtConfCommandlineEnableFeature and
qtConfCommandlineDisableFeature.
These functions will set INPUT_foo and augment the input with the
information "this input is of boolean type". This information is used
when deciding whether to use this input as feature switch.
Change-Id: I83c691cc57424159148f059c2a1c8cd72e39ee63
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We don't need to deal with the input arguments to configure. We
can instead look at QT_QMAKE_TARGET_MKSPEC, like we do when we
auto detect other platforms. This handles both the -xplatform
and the -platform arguments.
Change-Id: I8d987d23e16bfa106833d521f67e8b5a931d9169
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The -sdk argument is documented as:
Build Qt using Apple provided SDK <sdk>. The argument should be
one of the available SDKs as listed by 'xcodebuild -showsdks'.
[ChangeLog][configure] The -sdk argument no longer auto-enables
the macx-ios-clang makespec. Pass -xplatform macx-ios-clang to
explicitly build Qt for iOS.
Change-Id: Ia4074015aba2c8296a65534c38eb2f06db32f286
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The SDK is relevant for all Apple systems, including macOS, iOS, tvOS,
watchOS, and visionOS.
We still pick up -DQT_UIKIT_SDK for iOS for compatibility.
[ChangeLog][CMake] The -sdk configure argument now maps
to the QT_APPLE_SDK CMake variable. QT_UIKIT_SDK is still
supported for iOS builds for compatibility.
Change-Id: I983a2f23c2414eb73cd35bb83738088defb45cbd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends commit be009c6857dc75c0bdf789c4ac9323f0cf1fd9e6.
The configure option -no-opengl was mistakenly translated to the CMake
argument -DFEATURE_opengl=no. The command line option "opengl" however
is defined as
qt_commandline_option(opengl
TYPE optionalString
VALUES no yes desktop es2 dynamic
)
which is not boolean. And only boolean command-line options may
automagically control features of the same name. It just happens that
the values "no" and "yes" look boolean.
Setting FEATURE_opengl instead of INPUT_opengl broke feature conditions
that check the INPUT_opengl value.
Fix this by checking the type of the corresponding command line option
instead of guessing the type from the INPUT_* value.
An option (e.g. force-asserts) can be diverted to a differently named
input (e.g. force_asserts) with the NAME argument of
qt_commandline_option. In this case, we cannot deduce the option name
from the input's name. To handle this, we store the input's type in
commandline_input_${name}_type and read it when translating feature
values.
Fixes: QTBUG-122914
Change-Id: Ibb4b0633b6635bd2ef6f26ed8f4b19d239bf5854
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Inputs (in the sense of configure commandline options) are now
translated to -DFEATURE_foo=ON/OFF if the input name matches a feature
name. This is going to replace more complicated logic in our feature
evaluation.
Task-number: QTBUG-120529
Change-Id: I3ef45cd0e0a1462c53543cd2152eaf7f94318d9d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Directly set the feature variable instead of the INPUT_* variable.
The magic translation from INPUT_* to FEATURE_* is removed in a
subsequent commit.
Change-Id: I8156a20e9af6883783c9a7fa6b4f591d7a2f587c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We now convert the configure arguments -feature-foo and -no-feature-foo
to the CMake arguments -DFEATURE_foo=ON and -DFEATURE_foo=OFF. This is
done, because the former behavior was surprising, and it allows us to
remove quite some code that was needed to calculate feature values from
INPUT_foo and FEATURE_foo.
Task-number: QTBUG-120529
Change-Id: I94f8eb4adbbcaa1090aedce6e711012781c62a3c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When using configure arguments like -system-libpng then we saw lines
like this in configure's output:
opt: libpng val: system
This is a left-over debug message which went unnoticed for a long time.
This patch removes it.
Change-Id: Ic655fbc9aedb887743206fdfb344bf2f5eca7a12
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Features enable code coverage collecting using the gcov tool. The
resulting reports can then be post-processed by lcov or similar tools.
[ChangeLog][CMake][Coverage] Added the coverage configuration argument.
The only supported coverage tool at the moment is gcov. The argument
requires Qt is built in Debug otherwise setting the argument leads to
the configuration error. Typical usage:
<...>/configure -developer-build -coverage gcov
Task-number: QTBUG-86223
Change-Id: I39b2061f544997a7c4fe6f4d135c0ab447f15a17
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Just some help to users, so they can spot the allowed values without
looking into docs.
Pick-to: 6.6
Change-Id: I22ad9533104949286de447a05a6e875e8d933bf6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To be able to reconfigure Qt with modified feature values using the
configure script, and take into account INPUT_foo values, we need to
ignore FEATURE_foo values. But we can't always ignore FEATURE_foo
values, because users might want to toggle them by editing
CMakeCache.txt or using an IDE.
What we can do is tell CMake we are configuring via the configure
script, in which case we can mostly be sure that any passed
INPUT_foo values should have higher priority than pre-cached
FEATURE_foo values.
We also need to remove all the cached INPUT_foo variables after they
have been used for feature computation, so that subsequent
reconfigurations where an INPUT_foo is not passed anymore, doesn't
cause a feature to accidentally reuse the previous (stale) value.
Pass -DQT_INTERNAL_CALLED_FROM_CONFIGURE=TRUE to CMake when configuring
via the configure script, and use that as a marker to make INPUT_foo
values have a higher priority.
This needs to be done centrally in qt_evaluate_feature and also in a
few more locations where we check INPUT_ values, like the developer
build and pkgconfig features.
Because QT_INTERNAL_CALLED_FROM_CONFIGURE would become a cached
variable, we want to remove it at the end of the configuration phase,
so that future 'cmake .' reconfigurations are not considered to be done
via configure.
To do that, we unset it right at the end of
qt_build_repo_end in a per-repo build, and in the final
qt_print_build_instructions call in a top-level build.
The latter needs a cleaner fix in follow up commits in qt5.git and
qtbase.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I3fd338092041ef09e3f5a4dfbaf61da5deea0514
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
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>
If '-G<generator type>' is passed to configure script we should respect
this argument but not override it by the autodetected generator type.
'-cmake-generator' option will still have higher priority, but if
generator is set using CMake argument it will not be auto-detected by
other build config specific options, like '-debug-and-release'.
Change-Id: I75b49e33fa717f90bbd74045948fccb9f5350e8d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
I added the ability to use `-no-unity-build`, and included the
batch size in the config.summary as well. In addition, qt_feature is not
being used for `-unity-build` anymore.
Pick-to: 6.5 6.6
Change-Id: I4a10e03d3505336d2256280ed2854ec0425df47f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Vcpkg detection is enabled by default, but we did not have a flag to
disable it, and it was not showing up in config.summary either. By
adding a -vcpkg flag, we get to use `-no-vcpkg` when necessary, as well
as adding an entry to config summary indicating whether vcpkg is in use
or not. Besides `-no-vcpkg`, one can pass `-DQT_USE_VCPKG=OFF` to cmake
command in order to disable the automatic vcpkg detection/integration.
[ChangeLog][configure] vcpkg detection, and integration can be disabled
by passing the -no-vcpkg flag to the configure command, or by passing
`-DQT_USE_VCPKG=OFF` to the cmake command.
Pick-to: 6.6
Change-Id: Ide8da70a7b473ec23995104d162356e75e6d1240
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Accounting for the case where `MODULE_ROOT` is set to `.` which then
makes the `get_filename_component` command to return an empty string;
consequently, we cannot find the `config_file.txt`, and cannot process
the features correctly.
Amend f4bf7982a679312146546fabfb086e801c2bbc37
Pick-to: 6.5 6.6
Fixes: QTBUG-114085
Change-Id: I55c7529be6caba4691adec80efca8021bd03c500
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The `-sysroot` does not have any effect, and it can be removed.
I added a warning in case someone is still using it.
[ChangeLog][configure] The -sysroot option was removed. Use
CMAKE_SYSROOT or CMAKE_TOOLCHAIN_FILE instead.
Task-number: QTBUG-112951
Change-Id: Ib180b891ca8228ef1ebf9be43f2f6b8b5b5b0ee7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In unity build, when calling qt-configure-module.bat, if we don't pass
an absolute path, CMake will not be able to resolve the header paths in
`*_cxx.cxx` unity headers. So far, this only happens on Windows/LLVM,
and it is probably an oversight on CMake side, as passing a path without
drive letter is perfectly fine in most cases, and CMake can handle it.
We don't need the TO_CMAKE_PATH, as `get_filename_component` also does
the transformation.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I474750af13291cbf1a46a12be5fc4a0f6e88accf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If -unity-build-batch-size is not given, we default to CMake's default
which is 8. In QtSetup.cmake, we explicitly set the default to avoid
having it set to OFF in case it is missing, just to make sure that we
don't get any unintended behavior.
Task-number: QTBUG-109394
Change-Id: I19849e9baa507b64fb23847c740e20a7adc61b8f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the case of re-doing, `configure` and `configure.bat` pass an extra
parameter to the `QtProcessConfigureArgs.cmake`. As a result, CMake
removes CMakeCache.txt and CMakeFiles/ before the reconfiguration. If
the user is using CMake 3.24 or newer, this is achieved by passing
the `--fresh` option to CMake call. In older CMake(s), CMakeCache.txt
and CMakeFiles/ found in CMAKE_BINARY_DIR will be removed using a
file(REMOVE_RECURSIVE call.
[ChangeLog] The -redo option now additionally removes existing
CMakeCache.txt file, and CMakeFiles/ directory, and recreates them from
scratch.
Task-number: QTBUG-108287
Change-Id: I11a5c8f9df1247d11eb7097552e6764463583346
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And also teach CMake to treat it properly instead of hardcoding the
version number.
[ChangeLog][Build System] The configure script now accepts a new
parameter -disable-deprecated-up-to which is used to remove all
deprecated code from API and ABI while building the libraries.
The version number must be specified in a hex format.
For example, it can be used like this:
/path/to/qt/configure -disable-deprecated-up-to 0x060500
to remove all code deprecated in Qt 6.5.0 or earlier releases.
Task-number: QTBUG-101510
Change-Id: I557cf83e29b867fa1052bb097985e144b5eaf34d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Raise the CMake log level to STATUS when the 'verbose' argument is
passed to the configure script.
Change-Id: I736d95ab66b115f8416eec7f9e2ee96d1580c78d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
ANDROID_NATIVE_API_LEVEL is an alias for ANDROID_PLATFORM and the
Android's CMake docs [1] uses directly ANDROID_PLATFORM so let's use
that as well. Also, NDK r23b seems to have removed the part of code from
android.toolchain.cmake that handles ANDROID_NATIVE_API_LEVEL to set
the correct value to ANDROID_PLATFORM.
With this change, CMake will pass the value from the configure argument
-android-ndk-platform as -DANDROID_PLATFORM instead of
-DANDROID_NATIVE_API_LEVEL. Otherwise, if if -DANDROID_NATIVE_API_LEVEL
is passed directly to CMake, it should work as before.
[1] https://developer.android.com/ndk/guides/cmake#build-command
Pick-to: 6.3
Task-number: QTQAINFRA-4837
Change-Id: I5c21af53ac91e11a27c4b033313d22d1115c1abc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It broke drive-less (no C:\ prefix) paths passed to configure.
Invoking configure on Windows with the following args
qtbase/configure --
-DCMAKE_INSTALL_PREFIX=\Users\qt\work\install
called CMake with
-DCMAKE_INSTALL_PREFIX=\\Users\\qt\\work\\install
saying
Qt will be installed into '//Users/qt/work/install'
and while the build succeeded, installation would fail with
CMake Error at cmake_install.cmake:41 (file):
file cannot create directory:
//Users/qt/work/install/lib/cmake/Qt6BuildInternals. Maybe need
administrative privileges.
Note the double slash in the beginning is likely interpreted as a
Windows share URI / UNC path.
The same would happen when passing -prefix '\Users\qt\work\install'
As a reminder, we want to support drive-less prefix paths because
that's what Qt's Coin CI uses passes to ensure DESTDIR installation
works correctly.
Amends cb7f4030bc89471aa6489be60ac1c728a3dfd06b
Pick-to: 6.2 6.3
Fixes: QTBUG-94366
Change-Id: I9267b6f784babfbdaeafc65267ba96c75fa24112
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Introduce a new -no-prefix option that can be used to build Qt without
having to install it.
Currently, -no-prefix is already implied by -developer-build, but
-developer-build also implies -warnings-are-errors and
-feature-private-tests, which not everyone might want to use.
Some Qt builders likely use -developer-build for the no-prefix
behavior, hence we introduce a standalone -no-prefix option to offer
a nicer user experience without -Werror and friends.
Previously it was possible to achieve the same by specifying
-prefix $PWD, but that relies on $PWD expanding property in the used
shell.
The new -no-prefix doesn't depend on the type of the shell and
is shorter to type.
Internally this gets passed by configure as -DINPUT_no_prefix=yes to
CMake, and transformed into a -DQT_FEATURE_no_prefix=ON feature.
The feature also gets automatically auto-detected to ON if
developer-build is set, -prefix is either unset or $PWD.
CMake code should still query QT_WILL_INSTALL to decide whether
files need to be installed or not.
As a drive-by, we now also export QT_FEATURE_developer_build to
be available for querying during configuration of other repos
(previously it was only possible to query FEATURE_developer_build).
Pick-to: 6.2 6.3
Change-Id: Iaa6c8d8ae2b736282e9949d2a5d7f412e290a253
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Yield a warning instead of an error that -skip and -submodules have
no effect in a per-repo build.
Amends acaba632605ac22aa3da4c3cf8e5891cb9cde657
Adjusts to 11ae0e772cccd3028771c1380f077c605224cc19
Pick-to: 6.2 6.3
Change-Id: Ic26b0ba29e48be5162f13ad75308f8358d8878e3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Specifying the options would do nothing, so it's better to error out
early in case the developer accidentally added them.
Pick-to: 6.2 6.3
Change-Id: Ia516468a22c3c48e9e84dc78e522e8870186d96b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The option is used to specify a list of Qt repos (git submodules)
that should be included in the configuration of a top-level Qt build.
The option takes a comma-separated list of qt submodule names e.g.
'qtbase,qtsvg,qtdeclarative'
It can also take a single value like 'qtbase' or 'qtquick3d'.
Each specified submodule and all of its transitive dependencies will
be included when configuring the top-level Qt build (assuming that the
submodules have previously been already checked out).
Any missing submodules or dependencies will not be automatically
checked out, but rather skipped. This can result in a failed
configuration if a required submodule is missing.
If some optional transitive submodule dependency is not desired in the
build, you can combine the -submodules option together with -skip
options.
E.g. configuring with
-submodules qtdoc,qtnetworkauth -skip qtmultimedia,qtimageformats
will result in a top-level build with the following submodules:
- qtbase (common dependency)
- qttools (dependency of qtdoc)
- qtactiveqt dependency of qttools)
- qshadertools (dependency of qtdeclarative)
- qtdeclarative (explicit)
- qtnetworkauth (explicit)
- qtdoc (explicit)
Pick-to: 6.2 6.3
Fixes: QTBUG-100388
Change-Id: Ie8c47cfd1d1e0e44a27260bf9ddf968531cc1cc0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This makes skipping a list of submodules more concise.
e.g. instead of passing
-skip qtsvg -skip qtimageformats -skip qtmultimedia
pass
-skip qtsvg,qtimageformats,qtmultimedia
Pick-to: 6.2 6.3
Change-Id: I6a48828b2fd7cec9f6e19988f7b4033333768abb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously we passed flags like -ld-fuse=lld only to compile
calls, but not to the link call of a compile test project.
Make sure to pass it to the link call instead by using
check_cxx_source_compiles + CMAKE_REQUIRED_LINK_OPTIONS
instead of
check_cxx_compiler_flag.
Note the flag that is passed is still via passed via the
compiler launcher and not directly to the linker.
Remove duplicate flag handling code.
Pick-to: 6.2 6.3
Change-Id: I1bf90573904a9df83240b6debfee3cc9e425c6bb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
