Before this change, the dirty feature code only checked for
differences between FEATURE_foo and QT_FEATURE_foo, without taking
into account modified INPUT_foo values that might passed via the
configure script.
This led to issues in certain scenarios when reconfiguring with the
configure script.
For example configuring with -gui / -DINPUT_gui=ON and then with
-no-gui / -DINPUT_gui=OFF would fail saying
'Feature "widgets": Forcing to "ON" breaks its condition'
This happens because the widgets feature depends on gui being
available, but because INPUT_gui modifications don't trigger the dirty
feature re-eval code, we don't recompute the value of widgets.
Extract the code that takes into account the INPUT_foo variables into
a separate function, and use it both when computing feature values and
also when detecting dirty features.
This means any non-matching INPUT_foo variables will now also trigger
dirty feature checking.
Use the same function to replace the duplicate code we have to early
initialize the developer-build, no-prefix and pkg-config features.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I775cf70b48291a659b0fecf7cb9570ec12735bca
Reviewed-by: Alexey Edelev <alexey.edelev@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>
Previously if Qt was configured with -developer-build, configure
would pass to CMake -DINPUT_developer_build=ON, which will ensure that
both FEATURE_developer_build and QT_FEATURE_developer_build are set to
ON.
Then if somebody tries to toggle FEATURE_developer_build to OFF in
the CMakeCache.txt and rerun cmake, the feature will bounce back to ON,
due to the code in QtSetup.cmake that doesn't take into account if
FEATURE_developer_build is already defined, and thus reset it based
on the value that is cached in INPUT_developer_build.
Change the checks for INPUT_developer_build and INPUT_no_prefix,
to take into account the defined-ness of their
FEATURE_ counterparts.
If they are defined, ignore the INPUT_ values.
This allows toggling the FEATURE_ variables and also aligns with
the INPUT_ handling behavior that we have in qt_evaluate_feature which
ignores INPUT_ values once the FEATURE_ is defined.
While this aligns the behavior with other features, there is still a
problem.
If you first configure without -developer-build,
and FEATURE_developer_build is set OFF, and then reconfigure with
-developer-build, because FEATURE_developer_build is already defined,
the INPUT_developer_build=ON is ignored.
This is a problem for other features as well and will be handled in a
follow up change.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I4f31157b0e7963e4d43e28062a585e939ceea0c1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It makes more sense for it to live next to the other feature code.
Pick-to: 6.6
Task-number: QTBUG-96936
Task-number: QTBUG-85962
Task-number: QTBUG-112957
Task-number: QTBUG-116209
Change-Id: I8438e6fce9deaa5e709e4b0e2e1ea4eb0600a89a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
Do not override CMAKE_<CONFIG>_POSTFIX if it's specified by user.
Using custom CMAKE_<CONFIG>_POSTFIX can potentially break qmake,
since qmake relies on pre-defined postfixes that are set by Qt build
by default. Building Qt with CMAKE_<CONFIG>_POSTFIX different from
default one will now warn about potential issues. Assume that we
still doesn't support setting of CMAKE_<CONFIG>_POSTFIX, but also
don't force our default values.
Fixes: QTBUG-115045
Change-Id: I75a34913189eae77062afa10d384eccf4edfc849
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A regression was introduced in
48841c34d2
when configuring qtshadertools with -prefix -debug and
no -developer-build.
qtbase would have been built as Debug, but qtshadertools as release.
This caused qsb.exe to link to a debug c++ runtime via QtCore, and a
release one via QtShaderTools libraries and thus cause heap corruption
crashes during runtime due to the mismatch.
This happened because the check in cmake/QtSetup.cmake thought Debug
was the default build type (nothing was specified on the command line)
without knowing it was explicitly set BuildInternals.
Set a variable when BuildInternals sets CMAKE_BUILD_TYPE and make
sure QtSetup does not override it then.
Augments 33af62db37
Amends 48841c34d2
Fixes: QTBUG-114958
Change-Id: I5e0a27b4d77512494c026dd911ec5757889a5a1a
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Standalone test projects have the following condition in the
beginning of their project:
if(NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT)
find_package(Qt6BuildInternals COMPONENT STANDALONE_TEST)
endif()
When configuring the project the first time, QT_BUILDING_QT is not
set, find_package is called, configuration succeeds.
But because standalone projects implicitly include QtSetup.cmake,
that file sets the QT_BUILDING_QT cache var to true, and upon test
reconfiguration, cmake errors out with:
Unknown CMake command "qt_internal_add_test"
or similar.
This happens because QT_BUILDING_QT is true on the second
reconfiguration and the find_package mentioned above is not executed
anymore, leading to unknown internal command errors.
Set a new QT_INTERNAL_IS_STANDALONE_TEST variable when we detect
a standalone test and check for its value in QtSetup so we don't
set QT_BUILDING_QT to TRUE anymore.
Adjust a few code locations where QT_BUILDING_QT being false might
trigger different behavior for standalone tests.
Task-number: QTBUG-93020
Change-Id: I5413b9f37653225175a1006f7626e023045b5979
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
The syncqt tool was originally designed to run at build time, as a
part of dependency chain of Qt modules. This works well unless we need
the code model of the Qt project in IDE, since Qt source code actively
uses header aliases, and creating them at build time breaks the code
model until the initial build is done. So we made syncqt the configure
time tool to not break the developer experience.
It's more likely that developers build Qt using command line or don't
need the code model before the first build. So running the tool at
configure time should be optional.
QT_SYNC_HEADERS_AT_CONFIGURE_TIME switches the "mode" of the syncqt
tool from build time tool to the configure time tool. Without the
option enabled build procedure runs all the syncing targets at build
time only. The exception are the developer builds, if the
'-developer-build' option is enabled, QT_SYNC_HEADERS_AT_CONFIGURE_TIME
is set to TRUE by default. This gives better development experience for
the developers that don't use the code model in their IDE or don't
require it before the first build is finished. Also this build time
mode is preferred for the CI or similar build procedures where code
model is not required at all.
By default, the option initialized from the
QT_INTERNAL_CONFIGURE_FROM_IDE CMake variable.
TODO: The option is forced to TRUE for the static Ninja Multi-Config
builds. See QTBUG-113974 for details.
[ChangeLog][Build System] When building Qt from sources, syncqt and Qt
header files are now created at build time, not configure time. This
should speed up the configuration step. You can set the CMake variable
QT_CONFIGURE_TIME_SYNC_HEADERS to ON to use the previous behavior,
though. The old behavior is also preserved if cmake/configure is run
from inside an IDE - Qt Creator, Visual Studio Code, and CLion are
currently detected.
Task-number: QTBUG-111163
Task-number: QTBUG-109792
Pick-to: 6.6
Change-Id: Ib61bda9546e58492be874a8591c37e100313d02c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
`TYPE` argument is not a thing, and if it is there, QT_BUILDING_QT is
set to `TRUE;CACHE;TYPE;STRING;When this is present and set to true, it
signals that we are building Qt from source.` instead of `TRUE`.
Pick-to: 6.2 6.5 6.6
Change-Id: I24784e9aead4929d408d06bce72d3f33ee21eb63
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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 33af62db37
[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>
Introduce QT_ALLOW_DOWNLOAD option that should be used the downloading
of the resources from web in Qt builds. Calls like file(DOWNLOAD or
FetchContent_* should be wrapped with this option, so users that build
Qt could control this and disable functionality that requires
resources from web.
Change-Id: Ie0494265c0c5fe93a7ef0d1cbcee1af919d57fa5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
`QT_ALLOW_SYMLINK_IN_PATHS` disables the
`qt_internal_check_if_path_has_symlinks` command. This allows people of
Homebrew to get their build working without having to patch the entire
function, as they currently do.
Pick-to: 6.5
Change-Id: I4fed3ca497684364eaabbdbc44f1e148e3f28bd7
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We set CMAKE_POSITION_INDEPENDENT_CODE to ON and require CMake 3.16.
This sets CMP0083 to NEW and should pass -fPIE to linker calls as well.
However, the PIE-enabling flag is not passed to the linker unless we
call check_pie_supported(). This behavior is documented in CMake's
CMP0083 documentation page.
[ChangeLog][CMake] Qt tools are now built with position independent code
even with Unix toolchains where this is not the default, for example
clang.
Pick-to: 6.5 6.4 6.2
Change-Id: I1d98e0ea7063a76e3fddc94d6555c6eaf14c7885
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This reverts commit e3ecabad22.
Reason for revert: This breaks the CTest internal switches. So it's better to disable testing directly in submodule.
Change-Id: Ia93dc3bb0a3a34021c8e2d6c3d292e3a4909bef5
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This switch should help switch off some time consuming operations
that make sense only whe configuring Qt project from IDE.
The switch is INTERNAL and depends on environment variables defined
by IDE application when running cmake:
- Qt Creator, detected by QTC_RUN environment variable
- CLion, detected by CLION_IDE environment variable
- Visual Studio Code, detected by VSCODE_CLI environment variable
Pick-to: 6.5
Change-Id: I44086376109a8af8ebb7ecd8bf64dc34f0631527
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This leads to unwanted side issues such as building and running third
party component tests. The option should be enabled explicitly by
user instead.
Fixes: QTBUG-111091
Change-Id: I8942db2bd089ad2a39a70627bfce8314b101ecb8
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@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>
This works by collecting the paths of all blacklist files
and deferring a call which ultimately reads all of the files and
glues them together to form a master blacklist file for the batch.
There might be conflicting function names inside the batch. For now
we ignore the problem, while keeping in mind that it exists.
Fixes: QTBUG-110016
Change-Id: I9c8412097418c6e93297ab89af718d7466e2e451
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Introduce the variable QT_SKIP_SETUP_DEPLOYMENT to turn off the
generation of deployment support files. Set this variable when building
Qt - but only if we're not building examples.
This avoids a warning about missing patchelf when building Qt with CMake
< 3.21.
Change-Id: I8ff5491eb314ff870c210884fbf90dd4c9ad0219
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Batched tests is the default supported test mode of wasm and should
be enabled without explicitly passing a command line argument.
Change-Id: I79424384e4e8ca6f670de1cb056f4713740a584f
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Wasm doesn't play well with these baseline tests in general,
so we can disable them for now.
Pick-to: 6.4
Change-Id: I5a66a932449c8934d88b94e419aae5ddcc89ee78
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
An approach of test batching (joining multiple tests into a single
binary) has been taken, due to long linking times/binary size on certain
platforms, including WASM. This change adds a new feature
'batch_test_support' in Qt testlib. Based on the value of the feature,
test batching may become enabled with the -batch-tests switch.
Batching works for every target added via qt_internal_add_test. When
first such target is being processed, a new combined target for all of
the future test sources is created under the name of 'test_batch'.
CMake attempts to merge the parameters of each of the tests, and some
basic checks are run for parameter differences that are impossible to
reconcile.
On the C++ level, convenience macros instantiating the tests are
redefined when batch_tests is on. The new, changed behavior triggered
by the changes in the macros registers the tests in a central test
registry, where they are available for execution based solely on their
test name. The test name is interoperable with the names CMake is aware
of, so CTest is able to run the tests one by one in the combined binary.
Task-number: QTBUG-105273
Change-Id: I2b6071d58be16979bd967eab2d405249f5a4e658
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Previously configuration would not error out if you configured Qt
with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug -GNinja
instead you would get an error like
CMake Error at cmake/QtBaseConfigureTests.cmake:51 (message):
Failed to find compiled architecture detection executable at
qtbase/build/config.tests/arch/RelWithDebInfo/architecture_test.exe
Note that Qt code tries to find the arch test in a RelWithDebInfo
directory but due to using single-config Ninja,
CMAKE_CONFIGURATION_TYPES is ignored, and the executable is placed
in a non-config specific folder.
Error out early in such a case, and mention that for multi-config
builds, the Ninja Multi-Config generator should be used.
Pick-to: 6.4
Change-Id: I0192185123be563671cbe154f968a03b7458e327
Reviewed-by: Alexey Edelev <alexey.edelev@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>
Add an option to limit the number of tests for building and testing
Android multi-ABI configurations in CI. Currently only Core tests
supposed to run.
Change-Id: Ibb8a41d60d108259ef2675ec54bde2482f87c8b2
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Also replace the duplicate call in QtSetup using the
new function.
To do that, we have to actually the call it in QtBuild
after QtPublicDependencyHelpers.cmake is available.
That call is needed so that Qt6_HOST_INFO_foo variables
are available in qt_generate_qmake_and_qtpaths_wrapper_for_target.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ic5776c214bee6bedcea714b213b0e5a42c1bae06
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This will hide the configuration summary and cmake feature summary and
found packages output upon reconfiguration.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-104128
Change-Id: I42270b99e45076052ec176df4652661cae10ac0c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
...when QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON.
When QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON, we want to set
QT_FORCE_BUILD_TOOLS. But this happened too late: after the
initialization of QT_BUILD_TOOLS_BY_DEFAULT. This value depends on
QT_FORCE_BUILD_TOOLS.
This amends commit acfbe3b779.
Change-Id: Ibdba54da943aea1b55618f10d2b8485f4390878a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously, this was only supported when cross-compiling, but that's an
unnecessary limitation. Instead, make it possible to build the "host"
tools (notably qmake) even when they've been found elsewhere due to
QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH.
The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to
ON is useful for developers who touch content that ends up in the
bootstrap library.
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of
QT_FORCE_BUILD_TOOLS.
[ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been
deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in
combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from
a host Qt even for a non-cross build and still build the tools.
Fixes: QTBUG-99683
Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Previously if
-extprefix /tmp/sysroot (CMAKE_STAGING_PREFIX)
-developer-build (FEATURE_developer_build)
were specified, but
-prefix (CMAKE_INSTALL_PREFIX)
was not,
the build system would set the CMAKE_INSTALL_PREFIX to the
qtbase build dir.
Then, if targeting desktop, this would be considered a non-prefix
build (ninja install would refuse to work), whereas in a cross-build
it would be considered an installable build.
In both cases though, the rpath of installed binaries would point to
the qtbase build dir (because CMAKE_INSTALL_PREFIX would be set to the
qtbase build dir).
This is quite confusing behavior, in more than one way.
Change the build system to consider that an explicit -extprefix should
cause Qt to always be installed, even if -developer-build is
specified.
This means the installed rpaths and on-device install prefix
(CMAKE_INSTALL_PREFIX) will now use the default computed install
prefix, e.g. /usr/local/Qt
It also means that to get a non-installable developer + custom staging
and install (on-device) prefix build, users will have to be explicit
and set all the options
-extprefix ~/qt/qtbase_build_dir
-prefix /usr
-developer-build
Pick-to: 6.2 6.3
Change-Id: Ib560452a4b4778860e0fd7666c76f8a6745773ee
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Allow such a combination
- staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the
qtbase build dir
- install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set
to some custom location
even for non-cross builds.
An example would be
configure -prefix /usr \
-extprefix ~/qt/qtbase_build_dir
CMake will put the Qt libraries in the qtbase build dir, ninja install
will not be required, but ultimately in order to run applications,
the Qt libraries are expected to be in /usr.
Support for this scenario was originally added for cross-builds in
062318feb2 , but not desktop builds.
Such a build is useful when you want to have install rpaths different
from where Qt is initially installed to (the staging prefix).
This case doesn't really happen often when targeting desktop
platforms, it's mostly used for cross-compilation (e.g yocto).
Being able to have the same setup with a desktop build is nevertheless
useful for faster iteration on build system issues in such a scenario.
Amends 062318feb2
Pick-to: 6.2 6.3
Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Only show the more verbose configure output when configuring
with -developer-build (which matches --log-level=STATUS)
Otherwise in a non-developer build, restrict the output
to NOTICE+ message (includes WARNINGs and ERRORs).
Developers can still pass a custom log level when configuring.
For example -DCMAKE_MESSAGE_LOG_LEVEL=STATUS or
--log-level=STATUS.
The former method will be cached, while the latter is only applied
to the current configure invocation.
Also show the build instructions hint message only when configuring
for the first time.
[ChangeLog][CMake][configure] The configure output verbosity of
non developer-builds of Qt is now reduced by default. Pass
"-- --log-level=STATUS" to configure to make it verbose again.
Pick-to: 6.2 6.3
Change-Id: I7583a9c92142e0b1d7c5411b06403f40d8ebaf20
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>
For cross-compiled conan packages we need conan to export QT_HOST_PATH
as an environment variable. The Qt build now picks up this environment
variable if no QT_HOST_PATH cache variable was specified.
Pick-to: 6.2 6.3
Change-Id: I0c3e15e82842061d5db81949ffcc1c240f6ed6a4
Reviewed-by: Iikka Eklund <iikka.eklund@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
In a single-config build on Linux, we usually don't want a debug
postfix in library names (as opposed to Windows/macOS).
But when doing a multi-config build on Linux, assigning no postfixes
causes CMake to generate rules for a single config only, the first one
specified in CMAKE_CONFIGURATION_TYPES.
This leads to being unable to build all configurations from the same
build.ninja file as well as other obscure issues like race-conditions
when generating prl files.
To address this, when doing a multi-config build, always assign a
postfix for each config except the first release-like one, while
preserving the existing rules we had for debug postfix names.
Pick-to: 6.2 6.3
Fixes: QTBUG-100493
Change-Id: Ie9c88e074abdcf2961d7b3dee19a5694292717b8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
There are issues when building examples as external projects in the CI
in child repos like qtsvg.
QEMU configurations fail to find some CMake Config files, Windows
configs fail to find libraries.
Until these issues are fixed, build examples in-tree (without using
external projects) like we did before.
Temporarily disables 98c89c8cc1
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ia4b39812b27cfde5f5a103fd39cc1cb032842643
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Change prefix builds to use ExternalProjects to build examples
by default. This will affect our CI which only does prefix builds.
To make it work, we have to do a few adjustments:
- look for Config files in the build-tree (before Qt is installed)
- build only one examples with only a single config,
even if Qt is a multi-config build
- install examples as part of main make install step, rather than
as part of the make step (which is the default for EPs)
- adjust CXX flags when building with MSVC to ensure we can still
use sccache and separate debug info
- derive the correct install prefix for each example and pass it
to the ExternalProject
As a drive-by, add TODOs to address tidiness of the code and corner
cases that likely don't work (Conan).
Amends d97fd7af2b
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This will show the CMAKE_BUILD_TYPE that was computed for a configured
repo or standalone tests, after the logic in
QtBuildInternalsExtra.cmake is executed.
Pick-to: 6.2 6.3
Change-Id: Ib8ffa2c7806a4c16385a2fcd4500f8a0f6a9aa88
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In non-prefix builds, we want to prevent users from accidentally running
"cmake --install". We did that by replacing cmake_install.cmake with an
empty file.
The responsible target remove_cmake_install is visible in IDEs, appears
in the build output, and the approach is hacky.
It's cleaner and easier to add bail out code at the top of
cmake_install.cmake. This is now done when calling qt_build_repo_begin.
As a bonus, print an informative message on installation.
Change-Id: I022b36289358ba09cac8b79781f44cd7b93113f7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We default to configuring examples as separate ExternalProjects when
using a developer / non-prefix Qt build.
This ensures we test that the examples configure successfully without
the pollution of the main Qt build (e.g. already found packages).
One down-side of this is that a developer's IDE doesn't see these
example targets, unless each project is loaded into the IDE
separately. This is cumbersome to do when refactoring or renaming
code across multiple example projects.
Allow configuring the example projects as part of the main Qt build
by setting QT_BUILD_EXAMPLES_AS_EXTERNAL to FALSE when configuring Qt.
Save the value of the variable in QtBuildInternalsExtra.cmake.in
so it's propagated to leaf repositories as well.
Amends dab8f64b6d
Amends d97fd7af2b
Task-number: QTBUG-90820
Task-number: QTBUG-94608
Task-number: QTBUG-96232
Task-number: QTCREATORBUG-26168
Pick-to: 6.2
Change-Id: Ie1f724f74365b3a788b04c3fffe9eb2d0611dd50
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Before, we would just issue a warning which is likely to get overlooked
in CMake's output. Also, the configure summary would report "Using
ccache ... yes" but CMAKE_<LANG>_COMPILER_LAUNCHER stays unset, which is
inconsistent.
Make QT_USE_CCACHE=ON and missing ccache a hard error.
Task-number: QTBUG-88308
Change-Id: Iddc7f3a91428fd96ad0defbb1ca72bd46a90aa98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change the default installation prefix to C:/Qt/Qt-${version} on Windows
and /usr/local/Qt-${version} elsewhere.
This is what's expected by users coming from Qt5, and setting the
installation prefix to "/usr/local" manually is easier than setting the
versioned variant "/usr/local/Qt-6.2.0".
[ChangeLog][Build System] The installation prefix now defaults to
/usr/local/Qt-${version} and C:/Qt/Qt-${version} like it did in Qt 5.
Fixes: QTBUG-91632
Pick-to: 6.2
Change-Id: I8ce57b1b18084c705b194c776e038cc807a6ed5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Ensure that Qt user projects build with sanitizer flags if Qt was
configured with any of the sanitizers enabled.
To compile Qt with sanitizer support enable any of Qt sanitizer
features.
Passing -DECM_ENABLE_SANITIZERS=address to CMake is NOT supported
anymore.
When configuring Qt using CMake directly, pass
-DFEATURE_sanitizer_address=ON
-DFEATURE_sanitizer_undefined=ON
instead of
-DECM_ENABLE_SANITIZERS=address;undefined
When configuring Qt with the configure script pass
-sanitize address -sanitize undefined
as usual.
QtConfig.cmake now records the sanitizer options that should be
enabled for all consuming projects based on the enabled Qt features.
This applies to internal Qt builds as well as well as tests an
examples.
The recorded sanitizer options are assigned to the ECM_ENABLE_SANITIZERS
variable in the directory scope where find_package(Qt6) is called.
The ECMEnableSanitizers module is included to add the necessary flags to
all targets in that directory scope or its children.
This behavior can be opted out by setting the
QT_NO_ADD_SANITIZER_OPTIONS variable in projects that use Qt and might
be handling sanitizer options differently.
Amends 7e03bc39b8
Pick-to: 6.2
Fixes: QTBUG-87989
Task-number: QTBUG-92083
Change-Id: I2e3371147277bdf8f55a39abaa34478dea4853a6
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add new configure option -make minimal-static-tests and CMake option
QT_BUILD_MINIMAL_STATIC_TESTS. In conjunction with QT_BUILD_TESTS
it will enable building a minimal subset of tests when targeting
a static desktop Qt build.
In qtbase the minimal subset includes all the auto tests of testlib,
tools, corelib and cmake. In particular this will also do cmake build
tests and qmake build tests (tst_qmake)
Adjust CI instructions to enable building a minimal subset of static
tests when a platform configuration is tagged with the
MinimalStaticTests feature.
Fix and skip a few tests that were failing.
Pick-to: 6.1
Task-number: QTBUG-87580
Task-number: QTBUG-91869
Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Developer builds with RelWithDebInfo should also make benchmarks, it
is how we get good traces.
Change-Id: I009d40580d5d784f78bd18ebf21887ce3c1fa97d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In QtSetup.cmake the PROJECT_VERSION_MAJOR variable was used to
identify prefix of 'Qt<version>HostInfoConfig.cmake'.
Qt<version>HostInfo is not found, if project version differs
from qtbase version.
Move the 'INSTALL_CMAKE_NAMESPACE' and 'QT_CMAKE_EXPORT_NAMESPACE'
variables to 'QtBuildInternalsConfig.cmake'. In this case
variables will be exposed for a wider list of internal routines.
Use the 'INSTALL_CMAKE_NAMESPACE' variable as prefix to find
Qt<version>HostInfo module.
Fixes: QTBUG-90345
Change-Id: Ic595d1c5beb74f34e69b58e18590a3afc2f346f7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
