We are selecting a subset of the tests for batching/CI,
however this is done for the WASM configuration which
interferes with non-batched tests.
- we can only build and run tests which are in the
batching subset
- we are enabling threading tests which breaks the
no-thread configuration.
Add QT_BUILD_WASM_BATCHED_TESTS and enable for WASM and
batching. There's then no restrictions on which tests
can be selected for CI.
Change-Id: I59a67b63e80cd00676cb28f916951d2a52b0ee2c
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
When building examples as part of Qt in the CI, it's best to skip
running deployment for all examples to save resources
(space and time).
Add a QT_DEPLOY_MINIMAL_EXAMPLES option similar to our
QT_BUILD_MINIMAL_STATIC_TESTS option, which will set
QT_INTERNAL_SKIP_DEPLOYMENT at the root examples directory scope, to
skip deployment for all examples.
Each example can then opt into the minimal subset by unsetting the
QT_INTERNAL_SKIP_DEPLOYMENT variable before its
qt_internal_add_example call.
Add Coin instructions to enable this option when building our examples
in the CI.
Pick-to: 6.7
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Task-number: QTBUG-102057
Change-Id: I2efcda455b400c27fe1efd1bcf81b133137fa2d1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If a qt5.git configuration is marked with the StandaloneTests feature,
tell CMake not to build the examples in-tree, and instead use
qt-internal-configure-examples to build the examples out-of-tree.
This brings a couple of improvements:
- higher chance of building examples as ExternalProjects without
issues
- ability to use deployment api in examples, without installing the
examples into a main install prefix
The new coin instructions files use a copy of the standalone tests
instructions as a base.
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: If89e6da0b327a38b9c2738f58aa1b5b5fb9fda37
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Introduce a new libexec/qt-internal-configure-examples script that
allows to configure and build "standalone examples" just like
"standalone tests".
This is a prerequisite for using deployment api in examples for prefix
builds, otherwise deployment api gets confused not finding various
information that it expects from an installed qt.
Because the various conditions in the build system for standalone
examples are similar to standalone tests, introduce a new
QT_BUILD_STANDALONE_PARTS variable and use that in the conditions.
The variable should not be set by the user, and is instead set by the
build system whenever QT_BUILD_STANDALONE_TESTS/EXAMPLES is set.
Unfortunately due to no common file being available before the first
project() call, in qtbase builds, per-repo builds and top-level builds,
we need to duplicate the code for setting QT_BUILD_STANDALONE_PARTS for
all three cases.
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ia40d03a0e8f5142abe5c7cd4ff3000df4a5f7a8a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Unfortunately when using CMake <= 3.27 together with
-debug-and-release, it's not possible to reliably build examples as
external projects due to clobbered files in the same build dir.
Disable building examples as EPs in such a case.
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Icea9fdab47986c2608e1952a0bbae72365ac7a62
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously we had four-ish locations where the CMAKE_BUILD_TYPE was
force set.
Twice in QtBuildInternalsExtra.cmake via
qt_internal_force_set_cmake_build_type_conditionally(), depending on
some conditions. This was executed right at
find_package(Qt6 COMPONENTS BuildInternals)
time.
And twice in qt_internal_set_default_build_type() via
qt_build_repo_begin() / qt_prepare_standalone_project() that goes
through QtSetup.cmake. This was executed only if the relevant functions
were called, rather than directly at find_package() time.
The exact logic of which build type ended up being set was very
confusing.
Refactor the code to decide the build type in one single location
when qt_build_repo_begin() / qt_prepare_standalone_project() are
called, rather than directly at find_package() time.
The actual logic when we override the build type depends on many
factors:
- when an explicit CMAKE_BUILD_TYPE is given, honor it, unless it's
a multi-config build
- when it's a multi-config build, don't set any CMAKE_BUILD_TYPE,
use the value of CMAKE_CONFIGURATION_TYPES
- when it's a qtbase build, compute a default unless an explicit value
was given
- the default is Debug if FEATURE_developer_build is ON
- otherwise the default is Release
- when it's a top-level build, only choose a build type for qtbase
- when it's another repo build, use the original build type unless
another was given explicitly (including in a top-level build)
- when it's a standalone tests build
- if qt is multi-config, the tests will be single config, due to
various CI failure reasons, this hasn't changed
- if qt is single config, use the original unless an explicit
value was given
- when it's a single standalone test build, use the original unless
an explicit value was given
To determine when an explicit CMAKE_BUILD_TYPE was given in contrast
to when it was default initialized, we now have one single function
that uses a few heuristics.
The heuristics are needed because we can't reliably determine an
explicitly given 'Debug' build on Windows, because CMake default
initializes to that.
The heuristics include:
- checking whether CMAKE_BUILD_TYPE_INIT is different from
CMAKE_BUILD_TYPE
- checking what the CMAKE_BUILD_TYPE was before the first project()
call when CMake default initializes
- we save the previous value in the qt.toolchain.cmake file
- also in QtAutoDetect during qtbase configuration
- also when building the sqldrivers project
- honoring the value of QT_NO_FORCE_SET_CMAKE_BUILD_TYPE
As a result of the above changes, the build type will be set exactly
zero or one times, for a particular build directory.
Note that the configure script also has some logic on which
CMAKE_BUILD_TYPE / CMAKE_CONFIGURATION_TYPES to pass to CMake
depending on whether -debug / -release / -debug-and-release /
-force-debug-info were passed. But once the values are passed,
CMake will honor them.
Amends 48841c34d2e86a741ec9992b9704c0fa5973503c
Amends 8c912cddebe544010e7da3f87af5b21f3328d7ec
Pick-to: 6.7
Task-number: QTBUG-114958
Task-number: QTBUG-120436
Change-Id: I30db14d1e8e9ff9bd2d7ea1d2256cdeb9493ca0d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
When the user:
- has a non-developer-build -debug-and-release Qt
- and tries to configure the sqldrivers project with
-DCMAKE_BUILD_TYPE=Debug
our build system discarded the user request, and defaulted to
'Release'.
That happens because CMake sets CMAKE_BUILD_TYPE_INIT to 'Debug' by
default on Windows-MSVC, and we have no marker to differentiate
that the 'Debug' value was user-specified.
We have such a marker
- via the
__qt_auto_detect_cmake_build_type_before_project_call variable
when configuring qtbase / top-level qt
- via the
__qt_toolchain_cmake_build_type_before_project_call variable when
configuring via the qt toolchain file (although that doesn't apply
when configuring a multi-config build for obscure reasons, which
should be addressed).
A conservative fix is to add a new variable / marker called
__qt_internal_standalone_project_cmake_build_type_before_project_call
which the 'sqldrivers' project will set with the build type that is
detected before the first project() call, and use that to decide
whether to override the build type, similar how we do with toolchain
file variable.
We could reuse one of the previous variables, but I figured it's better
to be explicit with a new one. And hopefully we can clean up the whole
logic in a follow-up commit.
Amends 48841c34d2e86a741ec9992b9704c0fa5973503c
Amends 8c912cddebe544010e7da3f87af5b21f3328d7ec
Pick-to: 6.5 6.6 6.7
Fixes: QTBUG-120436
Task-number: QTBUG-114958
Change-Id: I37e3d8041088fe6084a9976ecc80ddd62d73ef81
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Split all code in QtSetup into separate functions and macros, put them
in more appropriate files, and call them in
qt_internal_setup_build_and_global_variables.
A new QtBuildOptionsHelpers.cmake is created which takes care of
computing the default values of user-customizable options that are not
pure configure features, like the cmake build type, whether to build
tests / examples, whether to enable ccache, etc.
The new function calls added in
qt_internal_setup_build_and_global_variables
try to preserve the previous code flow when QtBuild was included
in-between the code that was run in QtSetup.
Macros that have dependencies on various global variables were marked
as such with inline comments for easier navigation and comprehension.
After this change, QtSetup.cmake just includes QtBuild.cmake. We leave
it to exist for easier git blaming, but new code should not be added
to it unless really necessary.
The intent is to merge a variant of this change to 6.6 and 6.5 as
well.
Task-number: QTBUG-86035
Change-Id: I3409c2d3ea8ee19a69104b12ab2692966ba5f9cf
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
