AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
9826e4e38b
qt5base-lts/cmake/QtSetup.cmake

443 lines
18 KiB
CMake
Raw Normal View History

Add license headers to cmake files 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>
2022-07-05 11:26:52 +00:00
# Copyright (C) 2022 The Qt Company Ltd.
Change the license of all CMakeLists.txt and *.cmake files to BSD Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-19 13:21:34 +00:00
# SPDX-License-Identifier: BSD-3-Clause
Add license headers to cmake files 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>
2022-07-05 11:26:52 +00:00
cmake: set a CMAKE_BUILD_TYPE if none was specified Because the default "empty" CMAKE_BUILD_TYPE is a weird default Change-Id: I5768f67aa85dce4108e421d2f4eacdfb1cb5beb0 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2019-02-19 15:38:11 +00:00
## Set a default build type if none was specified
Android: Generate deployment-settings.json Generate the android deployment settings json for android apk targets. QtPlatformAndroid is now also deployed as a public build dependency of QtCore. Some minor refactoring has been performed to the naming of variables and functions to better match the public facing apis. Extra settings for the file can be configured using the following target properties: set_target_properties(Core PROPERTIES QT_ANDROID_DEPLOYMENT_DEPENDENCIES "foo;bar" QT_ANDROID_EXTRA_LIBS "foo;bar" QT_ANDROID_EXTRA_PLUGINS "foo;bar" QT_ANDROID_PACKAGE_SOURCE_DIR "/foo/bar/" ) The file is generated using the function qt_android_generate_depoyment_settings(). We need to install the android template files and jar files during the android build as the androiddeployqt tool wont work if parts of it are split between the host install and the android install. Added QT_BUILD_QT variable to check whether we are building Qt from source. Finally, we also force the stdlib to shared via cmake configuration with -DANDROID_STL="c++_shared" Change-Id: I063c47e11749d56ba4c6f02101dbcc09e1b9fe87 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 12:29:31 +00:00
CMake: Don't set QT_BUILDING_QT for single standalone tests 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>
2023-07-04 15:47:14 +00:00
# Set the QT_BUILDING_QT variable so we can verify whether we are building
# Qt from source.
# Make sure not to set it when building a standalone test, otherwise
# upon reconfiguration we get an error about qt_internal_add_test
# not being found due the if(NOT QT_BUILDING_QT) check we have
# in each standalone test.
if(NOT QT_INTERNAL_IS_STANDALONE_TEST)
set(QT_BUILDING_QT TRUE CACHE BOOL
Fix the issue with setting the QT_BUILDING_QT `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>
2023-06-09 08:33:38 +00:00
"When this is present and set to true, it signals that we are building Qt from source.")
CMake: Don't set QT_BUILDING_QT for single standalone tests 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>
2023-07-04 15:47:14 +00:00
endif()
Android: Generate deployment-settings.json Generate the android deployment settings json for android apk targets. QtPlatformAndroid is now also deployed as a public build dependency of QtCore. Some minor refactoring has been performed to the naming of variables and functions to better match the public facing apis. Extra settings for the file can be configured using the following target properties: set_target_properties(Core PROPERTIES QT_ANDROID_DEPLOYMENT_DEPENDENCIES "foo;bar" QT_ANDROID_EXTRA_LIBS "foo;bar" QT_ANDROID_EXTRA_PLUGINS "foo;bar" QT_ANDROID_PACKAGE_SOURCE_DIR "/foo/bar/" ) The file is generated using the function qt_android_generate_depoyment_settings(). We need to install the android template files and jar files during the android build as the androiddeployqt tool wont work if parts of it are split between the host install and the android install. Added QT_BUILD_QT variable to check whether we are building Qt from source. Finally, we also force the stdlib to shared via cmake configuration with -DANDROID_STL="c++_shared" Change-Id: I063c47e11749d56ba4c6f02101dbcc09e1b9fe87 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 12:29:31 +00:00
CMake: Rework INPUT_foo vars handling when reconfiguring 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>
2023-08-25 15:32:19 +00:00
# Pre-calculate the developer_build feature if it's set by the user via the INPUT_developer_build
# variable when using the configure script. When not using configure, don't take the INPUT variable
# into account, so that users can toggle the feature directly in the cache or via IDE.
CMake: Handle INPUT_foo values when detecting dirty builds 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>
2023-08-25 16:20:01 +00:00
qt_internal_compute_feature_value_from_possible_input(developer_build)
CMake: Use Release build type by default Use developer-build feature to set Debug build by default instead of .git folder detection Task-number: QTBUG-89410 Fixes: QTBUG-89476 Pick-to: 6.0 Change-Id: I2a4f529299d4875e7b0eef5b41dd7a6b9402178b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-18 17:58:38 +00:00
configure: CMake: Add -no-prefix option 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>
2022-02-22 17:51:16 +00:00
# Pre-calculate the no_prefix feature if it's set by configure via INPUT_no_prefix.
# This needs to be done before qtbase/configure.cmake is processed.
CMake: Handle INPUT_foo values when detecting dirty builds 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>
2023-08-25 16:20:01 +00:00
qt_internal_compute_feature_value_from_possible_input(no_prefix)
configure: CMake: Add -no-prefix option 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>
2022-02-22 17:51:16 +00:00
cmake: set a CMAKE_BUILD_TYPE if none was specified Because the default "empty" CMAKE_BUILD_TYPE is a weird default Change-Id: I5768f67aa85dce4108e421d2f4eacdfb1cb5beb0 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2019-02-19 15:38:11 +00:00
set(_default_build_type "Release")
CMake: Use Release build type by default Use developer-build feature to set Debug build by default instead of .git folder detection Task-number: QTBUG-89410 Fixes: QTBUG-89476 Pick-to: 6.0 Change-Id: I2a4f529299d4875e7b0eef5b41dd7a6b9402178b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-18 17:58:38 +00:00
if(FEATURE_developer_build)
cmake: set a CMAKE_BUILD_TYPE if none was specified Because the default "empty" CMAKE_BUILD_TYPE is a weird default Change-Id: I5768f67aa85dce4108e421d2f4eacdfb1cb5beb0 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2019-02-19 15:38:11 +00:00
set(_default_build_type "Debug")
endif()
CMake: Ensure top-level builds are affected by our chosen log level 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>
2022-06-09 16:52:56 +00:00
function(qt_internal_set_message_log_level out_var)
# Decide whether output should be verbose or not.
# Default to verbose (--log-level=STATUS) in a developer-build and
# non-verbose (--log-level=NOTICE) otherwise.
# If a custom CMAKE_MESSAGE_LOG_LEVEL was specified, it takes priority.
# Passing an explicit --log-level=Foo has the highest priority.
if(NOT CMAKE_MESSAGE_LOG_LEVEL)
if(FEATURE_developer_build OR QT_FEATURE_developer_build)
set(CMAKE_MESSAGE_LOG_LEVEL "STATUS")
else()
set(CMAKE_MESSAGE_LOG_LEVEL "NOTICE")
endif()
set(${out_var} "${CMAKE_MESSAGE_LOG_LEVEL}" PARENT_SCOPE)
CMake: Make configure less verbose by default 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>
2022-03-01 16:11:03 +00:00
endif()
CMake: Ensure top-level builds are affected by our chosen log level 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>
2022-06-09 16:52:56 +00:00
endfunction()
qt_internal_set_message_log_level(CMAKE_MESSAGE_LOG_LEVEL)
CMake: Make configure less verbose by default 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>
2022-03-01 16:11:03 +00:00
Add initial support for CMake "Ninja Multi-Config" generator This allows doing debug_and_release builds with Ninja on all platforms. The "Ninja Multi-Config generator" is available starting with CMake 3.17. Desired configurations can be set via CMAKE_CONFIGURATION_TYPES. Possible values: "Release, Debug, RelWithDebInfo, MinRelSize". For example -DCMAKE_CONFIGURATION_TYPES="Release;Debug". The first configuration is the 'default' configuration which is built when calling ninja with no arguments. To build all targets of a certain configuration use "ninja all:Release" or "ninja all:Debug". To build all targets in all configurations use "ninja all:all". Note that the first configuration influences which configuration of tools will be used when building the libraries for all configurations. In simple terms, when configured with -DCMAKE_CONFIGURATION_TYPES="Release;Debug" the release version of moc is used by AUTOMOC. When configured with -DCMAKE_CONFIGURATION_TYPES="Debug;Release" the debug version of moc is used by AUTOMOC. Framework builds and Ninja Multi-Config don't currently work together due to multiple bugs in CMake, which ends up generating an invalid ninja file with duplicate rules. There are also issues with placement of the debug artifacts. This will be handled in a follow up patch after CMake is fixed. Task-number: QTBUG-76899 Change-Id: If224adc0b71b7d1d6606738101536146aa866cd7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-12-06 14:12:17 +00:00
# Reset content of extra build internal vars for each inclusion of QtSetup.
unset(QT_EXTRA_BUILD_INTERNALS_VARS)
CMake: Port the 'debug_and_release' feature This feature is read-only. It's controlled by the multi-config feature of CMake. It mainly exists for the qmake support. Change-Id: I322459598fe92568eda4d42319ded444537e95d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-26 12:23:05 +00:00
# Save the global property in a variable to make it available to feature conditions.
get_property(QT_GENERATOR_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
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 14:22:39 +00:00
# Try to detect if an explicit CMAKE_BUILD_TYPE was set by the user.
# CMake sets CMAKE_BUILD_TYPE_INIT to Debug on most Windows platforms and doesn't set
# anything for UNIXes. CMake assigns CMAKE_BUILD_TYPE_INIT to CMAKE_BUILD_TYPE during
# first project() if CMAKE_BUILD_TYPE has no previous value.
# We use extra information about the state of CMAKE_BUILD_TYPE before the first
# project() call that's set in QtAutodetect.
# STREQUAL check needs to have expanded variables because an undefined var is not equal
# to an empty defined var.
# See also qt_internal_force_set_cmake_build_type_conditionally which is used
# to set the build type when building other repos or tests.
if("${CMAKE_BUILD_TYPE}" STREQUAL "${CMAKE_BUILD_TYPE_INIT}"
AND NOT __qt_auto_detect_cmake_build_type_before_project_call
CMake: Make sure to follow BuildInternals CMAKE_BUILD_TYPE on Windows A regression was introduced in 48841c34d2e86a741ec9992b9704c0fa5973503c 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 33af62db3747bb6fcb7490ef2d2abc5bb53925b6 Amends 48841c34d2e86a741ec9992b9704c0fa5973503c Fixes: QTBUG-114958 Change-Id: I5e0a27b4d77512494c026dd911ec5757889a5a1a Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-07-26 12:37:09 +00:00
AND NOT __qt_build_internals_cmake_build_type
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 14:22:39 +00:00
AND NOT CMAKE_CONFIGURATION_TYPES)
cmake: set a CMAKE_BUILD_TYPE if none was specified Because the default "empty" CMAKE_BUILD_TYPE is a weird default Change-Id: I5768f67aa85dce4108e421d2f4eacdfb1cb5beb0 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2019-02-19 15:38:11 +00:00
message(STATUS "Setting build type to '${_default_build_type}' as none was specified.")
set(CMAKE_BUILD_TYPE "${_default_build_type}" CACHE STRING "Choose the type of build." FORCE)
Add initial support for CMake "Ninja Multi-Config" generator This allows doing debug_and_release builds with Ninja on all platforms. The "Ninja Multi-Config generator" is available starting with CMake 3.17. Desired configurations can be set via CMAKE_CONFIGURATION_TYPES. Possible values: "Release, Debug, RelWithDebInfo, MinRelSize". For example -DCMAKE_CONFIGURATION_TYPES="Release;Debug". The first configuration is the 'default' configuration which is built when calling ninja with no arguments. To build all targets of a certain configuration use "ninja all:Release" or "ninja all:Debug". To build all targets in all configurations use "ninja all:all". Note that the first configuration influences which configuration of tools will be used when building the libraries for all configurations. In simple terms, when configured with -DCMAKE_CONFIGURATION_TYPES="Release;Debug" the release version of moc is used by AUTOMOC. When configured with -DCMAKE_CONFIGURATION_TYPES="Debug;Release" the debug version of moc is used by AUTOMOC. Framework builds and Ninja Multi-Config don't currently work together due to multiple bugs in CMake, which ends up generating an invalid ninja file with duplicate rules. There are also issues with placement of the debug artifacts. This will be handled in a follow up patch after CMake is fixed. Task-number: QTBUG-76899 Change-Id: If224adc0b71b7d1d6606738101536146aa866cd7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-12-06 14:12:17 +00:00
set_property(CACHE CMAKE_BUILD_TYPE
PROPERTY STRINGS
"Debug" "Release" "MinSizeRel" "RelWithDebInfo") # Set the possible values for cmake-gui.
elseif(CMAKE_CONFIGURATION_TYPES)
message(STATUS "Building for multiple configurations: ${CMAKE_CONFIGURATION_TYPES}.")
message(STATUS "Main configuration is: ${QT_MULTI_CONFIG_FIRST_CONFIG}.")
if(CMAKE_NINJA_MULTI_DEFAULT_BUILD_TYPE)
message(STATUS
"Default build configuration set to '${CMAKE_NINJA_MULTI_DEFAULT_BUILD_TYPE}'.")
endif()
CMake: Bail when configuring multiple configurations and plain Ninja 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>
2022-08-08 13:40:31 +00:00
if(CMAKE_GENERATOR STREQUAL "Ninja")
message(FATAL_ERROR
"It's not possible to build multiple configurations with the single config Ninja "
"generator. Consider configuring with -G\"Ninja Multi-Config\" instead of -GNinja."
)
endif()
CMake: Display CMAKE_BUILD_TYPE when including QtSetup 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>
2022-01-19 16:45:37 +00:00
else()
message(STATUS "CMAKE_BUILD_TYPE was set to: '${CMAKE_BUILD_TYPE}'")
cmake: set a CMAKE_BUILD_TYPE if none was specified Because the default "empty" CMAKE_BUILD_TYPE is a weird default Change-Id: I5768f67aa85dce4108e421d2f4eacdfb1cb5beb0 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2019-02-19 15:38:11 +00:00
endif()
CMake: Assign proper postfixes in multi-config builds 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>
2022-02-08 16:23:20 +00:00
# Append a config-specific postfix to library names to ensure distinct names
# in a multi-config build.
# e.g. lib/libQt6DBus_relwithdebinfo.6.3.0.dylib
# Don't apply the postfix to the first encountered release-like config, so we have at least one
# config without a postifx.
Allow using custom CMAKE_<CONFIG>_POSTFIX when building Qt 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>
2023-07-28 11:11:02 +00:00
# If postfixes are set by user warn about potential issues.
function(qt_internal_setup_cmake_config_postfix)
# Collect configuration that require postfix in Qt library names.
if(QT_GENERATOR_IS_MULTI_CONFIG)
set(postfix_configurations ${CMAKE_CONFIGURATION_TYPES})
else()
set(postfix_configurations ${CMAKE_BUILD_TYPE})
# Set the default postfix to empty by default for single-config builds.
string(TOLOWER "${CMAKE_BUILD_TYPE}" build_type_lower)
set(default_cmake_${build_type_lower}_postfix "")
endif()
# Override the generic debug postfixes above with custom debug postfixes (even in a single
# config build) to follow the conventions we had since Qt 5.
# e.g. lib/libQt6DBus_debug.6.3.0.dylib
if(WIN32)
if(MINGW)
# On MinGW we don't have "d" suffix for debug libraries like on Linux,
# unless we're building debug and release libraries in one go.
if(QT_GENERATOR_IS_MULTI_CONFIG)
set(default_cmake_debug_postfix "d")
endif()
else()
set(default_cmake_debug_postfix "d")
endif()
elseif(APPLE)
set(default_cmake_debug_postfix "_debug")
endif()
set(custom_postfix_vars "")
set(release_configs Release RelWithDebInfo MinSizeRel)
set(found_first_release_config FALSE)
foreach(config_type IN LISTS postfix_configurations)
string(TOLOWER "${config_type}" config_type_lower)
string(TOUPPER "${config_type}" config_type_upper)
set(postfix_var CMAKE_${config_type_upper}_POSTFIX)
CMake: Assign proper postfixes in multi-config builds 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>
2022-02-08 16:23:20 +00:00
# Skip assigning postfix for the first release-like config.
Allow using custom CMAKE_<CONFIG>_POSTFIX when building Qt 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>
2023-07-28 11:11:02 +00:00
if(NOT found_first_release_config
AND config_type IN_LIST release_configs)
set(found_first_release_config TRUE)
if(NOT "${${postfix_var}}" STREQUAL "")
list(APPEND custom_postfix_vars ${postfix_var})
endif()
CMake: Assign proper postfixes in multi-config builds 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>
2022-02-08 16:23:20 +00:00
continue()
endif()
Allow using custom CMAKE_<CONFIG>_POSTFIX when building Qt 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>
2023-07-28 11:11:02 +00:00
# Check if the default postfix is set, use '_<config_type_lower>' otherwise.
set(default_postfix_var
default_cmake_${config_type_lower}_postfix)
if(NOT DEFINED ${default_postfix_var})
set(${default_postfix_var}
"_${config_type_lower}")
endif()
# If postfix is set by user avoid changing it, but save postfix variable that has
# a non-default value for further warning.
if("${${postfix_var}}" STREQUAL "")
set(${postfix_var} "${${default_postfix_var}}" PARENT_SCOPE)
elseif(NOT "${${postfix_var}}" STREQUAL "${${default_postfix_var}}")
list(APPEND custom_postfix_vars ${postfix_var})
endif()
# Adjust framework postfixes accordingly
CMake: Assign proper postfixes in multi-config builds 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>
2022-02-08 16:23:20 +00:00
if(APPLE)
Allow using custom CMAKE_<CONFIG>_POSTFIX when building Qt 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>
2023-07-28 11:11:02 +00:00
set(CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_${config_type_upper}
"${${postfix_var}}" PARENT_SCOPE)
CMake: Assign proper postfixes in multi-config builds 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>
2022-02-08 16:23:20 +00:00
endif()
endforeach()
Allow using custom CMAKE_<CONFIG>_POSTFIX when building Qt 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>
2023-07-28 11:11:02 +00:00
if(custom_postfix_vars)
list(REMOVE_DUPLICATES custom_postfix_vars)
list(JOIN custom_postfix_vars ", " postfix_vars_string)
CMake: Assign proper postfixes in multi-config builds 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>
2022-02-08 16:23:20 +00:00
Allow using custom CMAKE_<CONFIG>_POSTFIX when building Qt 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>
2023-07-28 11:11:02 +00:00
message(WARNING "You are using custom library postfixes: '${postfix_vars_string}' which are"
" considered experimental and are not officially supported by Qt."
" Expect unforeseen issues and user projects built with qmake to be broken."
)
CMake: Don't add "d" suffix to MinGW debug libraries To be in line with the qmake build we drop the "d" suffix for MinGW debug libraries unless the debug_and_release feature is enabled. Task-number: QTBUG-84781 Change-Id: I1b83492bff561d3d7647dde467931ec3866ae940 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-11 09:45:22 +00:00
endif()
Allow using custom CMAKE_<CONFIG>_POSTFIX when building Qt 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>
2023-07-28 11:11:02 +00:00
endfunction()
qt_internal_setup_cmake_config_postfix()
Add a debug suffix to libraries and plugins on macOS and Windows This is especially important on macOS when doing a debug build, because QPluginLoader is looking for the cocoa QPA plugin suffixed with "_debug" when executing a test or example. Change-Id: Ief23b3a82c567c16ab9dd30d04d1729031262d7d Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-03-26 18:37:01 +00:00
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
## Position independent code:
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
CMake: Fix position independent code linker flags not being set 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>
2023-02-22 09:47:00 +00:00
# Does the linker support position independent code?
include(CheckPIESupported)
check_pie_supported()
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
# Do not relink dependent libraries when no header has changed:
set(CMAKE_LINK_DEPENDS_NO_SHARED ON)
CMake: Make build system of installed Qt more relocatable Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way. The following story inspired this change. If a user wants to build a Qt repo into a different install prefix than the usual Qt one, this will fail configuration because we look for various things like syncqt, qdoc, etc relative to CMAKE_INSTALL_PREFIX, which will now point to a different location where none of the above tools are located. The intent for such a use case is to support building Qt packages with Conan, which sets a random install prefix when configuring a repo. The idea is to derive the qt prefix dynamically from the QtBuildInternals package location. Essentially it's a reverse relative path from the QtBuildInternalsConfig.cmake file to the install prefix that was specified when initially configuring qtbase. Once the dynamic prefix is computed (so we know where the possibly relocated Qt is), we can find tools like syncqt and qdoc. This is an initial attempt to support a use case like that. More design work will probably needed in case if tools / libs need to be found in a location different than the Qt install prefix (so support for multiple install prefixes / search paths). An example of such a case would be when building qtdeclarative and qtquickcontrols2 as Conan packages in one go. Most likely the qmltyperegistrar tool will be located in the random install prefix set by Conan, so building qtquickcontrols2 might fail due to not finding the tool in the original Qt install prefix. As to the implementation details, the change does the following: - Dynamically computes and sets the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when find_package()'ing QtBuildInternals. It's an absolute path pointing to where the relocated Qt is. - When building qtbase this variable is not yet available (due to QtBuildInternalsExtra not existing), in that case we set the variable to the absolute path of CMAKE_INSTALL_PREFIX (but only for the initial qtbase configuration). - Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used for standalone tests purposes. It's not needed now that we compute the location of the Qt prefix dynamically. - The Unixy qt-cmake and qt-cmake-private shell scripts now use a relative path to find the toolchain file we created. - The toolchain file also dynamically computes the location of the Qt packages, and adds them to CMAKE_PREFIX_PATH. - A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding tool locations, mkspecs dir, path environment setup for tools, etc. - Some places still use CMAKE_PREFIX_PATH in the following cases - When determining paths while configuring qtbase (valid cases) - When I wasn't sure what the behavior should be, so I left them as-is (an example is documentation generation, do we want to install it into the random Conan prefix, or into the main prefix? Currently it installs in the random prefix). Note that relocating a Qt installation does not work for non-prefix / non-installed builds, due to hardcoded paths to include directories and libraries in generated FooTargets.cmake files. Task-number: QTBUG-83999 Change-Id: I87d6558729db93121b1715771034b03ce3295923 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
# Detect non-prefix builds: either when the qtbase install prefix is set to the binary dir
CMake: An -extprefix -developer-build should install by default 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>
2022-04-13 13:07:46 +00:00
# or when a developer build is explicitly enabled and no install prefix (or staging prefix)
# is specified.
Fix non-prefix builds for non qtbase repos QT_WILL_INSTALL was previously always set to ON when doing a qtdeclarative build, because CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT evaluated to false due to always having to set CMAKE_INSTALL_PREFIX to point to the qtbase build directory. Instead of recomputing the value of QT_WILL_INSTALL, compute it once while configuring qtbase, and add it to the generated QtBuildInternalsExtra.cmake file, so it propagates to all other repos that will be built. Change-Id: If8bf63e7501b5758fe7aa0f799cb0746704f4811 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-07-22 15:30:24 +00:00
# This detection only happens when building qtbase, and later is propagated via the generated
# QtBuildInternalsExtra.cmake file.
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
if (PROJECT_NAME STREQUAL "QtBase" AND NOT QT_BUILD_STANDALONE_TESTS)
Restore default installation prefix from Qt 5 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>
2021-07-06 10:41:11 +00:00
if(CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT)
configure: CMake: Add -no-prefix option 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>
2022-02-22 17:51:16 +00:00
# Handle both FEATURE_ and QT_FEATURE_ cases when they are specified on the command line
# explicitly. It's possible for one to be set, but not the other, because
# qtbase/configure.cmake is not processed by this point.
CMake: An -extprefix -developer-build should install by default 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>
2022-04-13 13:07:46 +00:00
if((FEATURE_developer_build
OR QT_FEATURE_developer_build
OR FEATURE_no_prefix
OR QT_FEATURE_no_prefix
)
AND NOT CMAKE_STAGING_PREFIX)
Restore default installation prefix from Qt 5 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>
2021-07-06 10:41:11 +00:00
# Handle non-prefix builds by setting the CMake install prefix to point to qtbase's
# build dir. While building another repo (like qtsvg) the CMAKE_PREFIX_PATH should be
# set on the command line to point to the qtbase build dir.
set(__qt_default_prefix "${QtBase_BINARY_DIR}")
else()
if(CMAKE_HOST_WIN32)
set(__qt_default_prefix "C:/Qt/")
else()
set(__qt_default_prefix "/usr/local/")
endif()
string(APPEND __qt_default_prefix
"Qt-${PROJECT_VERSION_MAJOR}.${PROJECT_VERSION_MINOR}.${PROJECT_VERSION_PATCH}")
endif()
set(CMAKE_INSTALL_PREFIX ${__qt_default_prefix} CACHE PATH
Implement developer / non-prefix builds A non-prefix build is a build where you don't have to run make install. To do a non-prefix build, pass -DFEATURE_developer_build=ON when invoking CMake on qtbase. Note that this of course also enables developer build features (private tests, etc). When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable will point to the qtbase build directory. Tests can be run without installing Qt (QPA plugins are picked up from the build dir). This patch stops installation of any files by forcing the make "install" target be a no-op. When invoking cmake on the qtsvg module (or any other module), the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build directory. The developer-build feature is propagated via the QtCore Config file, so that when building other modules, you don't have to specify it on the command line again. As a result of the change, all libraries, plugins, tools, include dirs, CMake Config files, CMake Targets files, Macro files, etc, will be placed in the qtbase build directory, mimicking the file layout of an installed Qt file layout. Only examples and tests are kept in the separate module build directories, which is equivalent to how qmake does it. The following global variables contain paths for the appropriate prefix or non prefix builds: QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR, QT_CONFIG_INSTALL_DIR. These should be used by developers when deciding where files should be placed. All usages of install() are replaced by qt_install(), which has some additional logic on how to handle associationg of CMake targets to export names. When installing files, some consideration should be taken if qt_copy_or_install() needs to be used instead of qt_install(), which takes care of copying files from the source dir to the build dir when doing non-prefix builds. Tested with qtbase and qtsvg, developer builds, non-developer builds and static developer builds on Windows, Linux and macOS. Task-number: QTBUG-75581 Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
"Install path prefix, prepended onto install directories." FORCE)
Restore default installation prefix from Qt 5 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>
2021-07-06 10:41:11 +00:00
unset(__qt_default_prefix)
CMake: Fix non-prefix build detection when CMAKE_STAGING_PREFIX is set It wasn't possible to create a cross, non-prefix build with CMAKE_INSTALL_PREFIX set to something else but the qtbase build dir and CMAKE_STAGING_PREFIX set to the qtbase build dir. This would be equivalent to configure -prefix /usr \ -extprefix ~/my/qtbase/build/dir Fix this by comparing the qtbase build dir against CMAKE_STAGING_PREFIX if it is set. We also have to adjust the QT_BUILD_DIR variable in a similar way. Change-Id: Iaba5cf0f6954ae4b15d8af1fc62634f5d7f68835 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-22 16:01:30 +00:00
endif()
CMake: Allow no install + custom on-device prefix for desktop builds 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 062318feb2d3b7598409c7e81e4459c2f4607764 , 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 062318feb2d3b7598409c7e81e4459c2f4607764 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>
2022-04-13 12:57:34 +00:00
if(CMAKE_STAGING_PREFIX)
CMake: Fix non-prefix build detection when CMAKE_STAGING_PREFIX is set It wasn't possible to create a cross, non-prefix build with CMAKE_INSTALL_PREFIX set to something else but the qtbase build dir and CMAKE_STAGING_PREFIX set to the qtbase build dir. This would be equivalent to configure -prefix /usr \ -extprefix ~/my/qtbase/build/dir Fix this by comparing the qtbase build dir against CMAKE_STAGING_PREFIX if it is set. We also have to adjust the QT_BUILD_DIR variable in a similar way. Change-Id: Iaba5cf0f6954ae4b15d8af1fc62634f5d7f68835 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-22 16:01:30 +00:00
set(__qt_prefix "${CMAKE_STAGING_PREFIX}")
else()
set(__qt_prefix "${CMAKE_INSTALL_PREFIX}")
endif()
if(__qt_prefix STREQUAL QtBase_BINARY_DIR)
set(__qt_will_install_value OFF)
Implement developer / non-prefix builds A non-prefix build is a build where you don't have to run make install. To do a non-prefix build, pass -DFEATURE_developer_build=ON when invoking CMake on qtbase. Note that this of course also enables developer build features (private tests, etc). When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable will point to the qtbase build directory. Tests can be run without installing Qt (QPA plugins are picked up from the build dir). This patch stops installation of any files by forcing the make "install" target be a no-op. When invoking cmake on the qtsvg module (or any other module), the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build directory. The developer-build feature is propagated via the QtCore Config file, so that when building other modules, you don't have to specify it on the command line again. As a result of the change, all libraries, plugins, tools, include dirs, CMake Config files, CMake Targets files, Macro files, etc, will be placed in the qtbase build directory, mimicking the file layout of an installed Qt file layout. Only examples and tests are kept in the separate module build directories, which is equivalent to how qmake does it. The following global variables contain paths for the appropriate prefix or non prefix builds: QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR, QT_CONFIG_INSTALL_DIR. These should be used by developers when deciding where files should be placed. All usages of install() are replaced by qt_install(), which has some additional logic on how to handle associationg of CMake targets to export names. When installing files, some consideration should be taken if qt_copy_or_install() needs to be used instead of qt_install(), which takes care of copying files from the source dir to the build dir when doing non-prefix builds. Tested with qtbase and qtsvg, developer builds, non-developer builds and static developer builds on Windows, Linux and macOS. Task-number: QTBUG-75581 Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
else()
Fix non-prefix builds for non qtbase repos QT_WILL_INSTALL was previously always set to ON when doing a qtdeclarative build, because CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT evaluated to false due to always having to set CMAKE_INSTALL_PREFIX to point to the qtbase build directory. Instead of recomputing the value of QT_WILL_INSTALL, compute it once while configuring qtbase, and add it to the generated QtBuildInternalsExtra.cmake file, so it propagates to all other repos that will be built. Change-Id: If8bf63e7501b5758fe7aa0f799cb0746704f4811 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-07-22 15:30:24 +00:00
set(__qt_will_install_value ON)
Implement developer / non-prefix builds A non-prefix build is a build where you don't have to run make install. To do a non-prefix build, pass -DFEATURE_developer_build=ON when invoking CMake on qtbase. Note that this of course also enables developer build features (private tests, etc). When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable will point to the qtbase build directory. Tests can be run without installing Qt (QPA plugins are picked up from the build dir). This patch stops installation of any files by forcing the make "install" target be a no-op. When invoking cmake on the qtsvg module (or any other module), the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build directory. The developer-build feature is propagated via the QtCore Config file, so that when building other modules, you don't have to specify it on the command line again. As a result of the change, all libraries, plugins, tools, include dirs, CMake Config files, CMake Targets files, Macro files, etc, will be placed in the qtbase build directory, mimicking the file layout of an installed Qt file layout. Only examples and tests are kept in the separate module build directories, which is equivalent to how qmake does it. The following global variables contain paths for the appropriate prefix or non prefix builds: QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR, QT_CONFIG_INSTALL_DIR. These should be used by developers when deciding where files should be placed. All usages of install() are replaced by qt_install(), which has some additional logic on how to handle associationg of CMake targets to export names. When installing files, some consideration should be taken if qt_copy_or_install() needs to be used instead of qt_install(), which takes care of copying files from the source dir to the build dir when doing non-prefix builds. Tested with qtbase and qtsvg, developer builds, non-developer builds and static developer builds on Windows, Linux and macOS. Task-number: QTBUG-75581 Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
endif()
Fix non-prefix builds for non qtbase repos QT_WILL_INSTALL was previously always set to ON when doing a qtdeclarative build, because CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT evaluated to false due to always having to set CMAKE_INSTALL_PREFIX to point to the qtbase build directory. Instead of recomputing the value of QT_WILL_INSTALL, compute it once while configuring qtbase, and add it to the generated QtBuildInternalsExtra.cmake file, so it propagates to all other repos that will be built. Change-Id: If8bf63e7501b5758fe7aa0f799cb0746704f4811 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-07-22 15:30:24 +00:00
set(QT_WILL_INSTALL ${__qt_will_install_value} CACHE BOOL
"Boolean indicating if doing a Qt prefix build (vs non-prefix build)." FORCE)
CMake: Fix non-prefix build detection when CMAKE_STAGING_PREFIX is set It wasn't possible to create a cross, non-prefix build with CMAKE_INSTALL_PREFIX set to something else but the qtbase build dir and CMAKE_STAGING_PREFIX set to the qtbase build dir. This would be equivalent to configure -prefix /usr \ -extprefix ~/my/qtbase/build/dir Fix this by comparing the qtbase build dir against CMAKE_STAGING_PREFIX if it is set. We also have to adjust the QT_BUILD_DIR variable in a similar way. Change-Id: Iaba5cf0f6954ae4b15d8af1fc62634f5d7f68835 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-22 16:01:30 +00:00
unset(__qt_prefix)
Fix non-prefix builds for non qtbase repos QT_WILL_INSTALL was previously always set to ON when doing a qtdeclarative build, because CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT evaluated to false due to always having to set CMAKE_INSTALL_PREFIX to point to the qtbase build directory. Instead of recomputing the value of QT_WILL_INSTALL, compute it once while configuring qtbase, and add it to the generated QtBuildInternalsExtra.cmake file, so it propagates to all other repos that will be built. Change-Id: If8bf63e7501b5758fe7aa0f799cb0746704f4811 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-07-22 15:30:24 +00:00
unset(__qt_will_install_value)
Implement developer / non-prefix builds A non-prefix build is a build where you don't have to run make install. To do a non-prefix build, pass -DFEATURE_developer_build=ON when invoking CMake on qtbase. Note that this of course also enables developer build features (private tests, etc). When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable will point to the qtbase build directory. Tests can be run without installing Qt (QPA plugins are picked up from the build dir). This patch stops installation of any files by forcing the make "install" target be a no-op. When invoking cmake on the qtsvg module (or any other module), the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build directory. The developer-build feature is propagated via the QtCore Config file, so that when building other modules, you don't have to specify it on the command line again. As a result of the change, all libraries, plugins, tools, include dirs, CMake Config files, CMake Targets files, Macro files, etc, will be placed in the qtbase build directory, mimicking the file layout of an installed Qt file layout. Only examples and tests are kept in the separate module build directories, which is equivalent to how qmake does it. The following global variables contain paths for the appropriate prefix or non prefix builds: QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR, QT_CONFIG_INSTALL_DIR. These should be used by developers when deciding where files should be placed. All usages of install() are replaced by qt_install(), which has some additional logic on how to handle associationg of CMake targets to export names. When installing files, some consideration should be taken if qt_copy_or_install() needs to be used instead of qt_install(), which takes care of copying files from the source dir to the build dir when doing non-prefix builds. Tested with qtbase and qtsvg, developer builds, non-developer builds and static developer builds on Windows, Linux and macOS. Task-number: QTBUG-75581 Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-05-08 12:45:41 +00:00
endif()
Ugly fix for handling QT_SOURCE_TREE QT_SOURCE_TREE is a variable that is set in qtbase/.qmake.conf. In qtbase, it's used throughout various projects to find cpp sources when building standalone tests (among other things). Everything works fine with qmake, because even if qmake is invoked on the tests subfolder, qmake searches up the source directory tree until it finds a .qmake.conf file, and uses that. When building qttools with qmake, the qdoc project expects to have a QT_SOURCE_TREE value, but it's not actually set in the qttools/.qmake.conf file, so the generated include paths that use that value are incorrect. Curiously the build still succeeds. Now in CMake land we replaced QT_SOURCE_TREE with CMAKE_SOURCE_DIR, but that does not work properly when doing a standalone tests build, because the project in that case is the tests one, and not the qtbase one, so configuration fails in a developer build when trying to configure some private tests. So far I've found that only qtbase actively uses this value. A temporary fix is to save the qtbase source directory into a QT_SOURCE_TREE variable inside the generated BuildInternalsExtra.cmake file. The pro2cmake script is changed to handle presence of QT_SOURCE_TREE in a qrc file path. This is handled by finding the location of a .qmake.conf file starting from the project file absolute path. This is needed to stop the script from crashing when handling the mimedatabase test projects for example. The change also regenerates the relevant failing test projects, and thus standalone tests (when doing developer builds aka private_tests enabled) now configure and build successfully. Change-Id: I15adc6f4ab6e3056c43ed850196204e2229c4d98 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-07-26 16:59:53 +00:00
# Specify the QT_SOURCE_TREE only when building qtbase. Needed by some tests when the tests are
# built as part of the project, and not standalone. For standalone tests, the value is set in
# QtBuildInternalsExtra.cmake.
if(PROJECT_NAME STREQUAL "QtBase")
set(QT_SOURCE_TREE "${QtBase_SOURCE_DIR}" CACHE PATH
"A path to the source tree of the previously configured QtBase project." FORCE)
endif()
Add the QT_INTERNAL_CONFIGURE_FROM_IDE option 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>
2023-02-21 11:57:02 +00:00
# QT_INTERNAL_CONFIGURE_FROM_IDE is set to TRUE for the following known IDE applications:
# - Qt Creator, detected by QTC_RUN environment variable
# - CLion, detected by CLION_IDE environment variable
# - Visual Studio Code, detected by VSCODE_CLI environment variable
if("$ENV{QTC_RUN}" OR "$ENV{CLION_IDE}" OR "$ENV{VSCODE_CLI}")
set(QT_INTERNAL_CONFIGURE_FROM_IDE TRUE CACHE INTERNAL "Configuring Qt Project from IDE")
else()
set(QT_INTERNAL_CONFIGURE_FROM_IDE FALSE CACHE INTERNAL "Configuring Qt Project from IDE")
endif()
Introduce QT_SYNC_HEADERS_AT_CONFIGURE_TIME flag 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>
2023-02-15 14:36:44 +00:00
set(_qt_sync_headers_at_configure_time_default ${QT_INTERNAL_CONFIGURE_FROM_IDE})
Allow prefix builds with developer-build as feature enabled Just like with qmake, separate the two "features". Change-Id: Idf2a796c7c4aaa740c471688b2221d7041fed643 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-25 10:09:10 +00:00
if(FEATURE_developer_build)
if(DEFINED QT_CMAKE_EXPORT_COMPILE_COMMANDS)
set(CMAKE_EXPORT_COMPILE_COMMANDS ${QT_CMAKE_EXPORT_COMPILE_COMMANDS})
else()
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
endif()
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
set(_qt_build_tests_default ON)
Add support for benchmark conversion Convert benchmark executables to add_qt_benchmark(). Currently add_qt_benchmark just calls add_qt_executable() and ensures that it they build under CMAKE_CURRENT_BUILD_DIR and do not install. Add QT_BUILD_BENCHMARKS option to enable/disable building of benchmarks. Change-Id: Id0bc676698d21d50048d97d9abef51d92ccb6638 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-10-28 14:35:47 +00:00
set(__build_benchmarks ON)
Add initial support for cross-building to iOS Tested locally with the following configurations: - iOS device builds (arm64) - iOS simulator builds (x86_64) - iOS simulator_and_device builds (fat arm64 and x86_64 archives) All iOS builds currently require a custom vcpkg fork which contains fixes for building the required 3rd party libraries. qtsvg, qtdeclarative, qtgraphicaleffects and qtquickcontrols2 have also been tested to build successfully. simulator_and_device builds are also supported, but require an umerged patch in upstream CMake as well as further patches to vcpkg. Task-number: QTBUG-75576 Change-Id: Icd29913fbbd52a60e07ea5253fd9c7af7f8ce44c Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-04-08 15:23:57 +00:00
# Tests are not built by default with qmake for iOS and friends, and thus the overall build
# tends to fail. Disable them by default when targeting uikit.
cmake: Remove APPLE prefix from platform names None of the other platforms have it. Change-Id: Ib448c2c03ba03f711b507ef391977c0e6aa7c192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-16 12:36:47 +00:00
if(UIKIT OR ANDROID)
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
set(_qt_build_tests_default OFF)
Add initial support for cross-building to iOS Tested locally with the following configurations: - iOS device builds (arm64) - iOS simulator builds (x86_64) - iOS simulator_and_device builds (fat arm64 and x86_64 archives) All iOS builds currently require a custom vcpkg fork which contains fixes for building the required 3rd party libraries. qtsvg, qtdeclarative, qtgraphicaleffects and qtquickcontrols2 have also been tested to build successfully. simulator_and_device builds are also supported, but require an umerged patch in upstream CMake as well as further patches to vcpkg. Task-number: QTBUG-75576 Change-Id: Icd29913fbbd52a60e07ea5253fd9c7af7f8ce44c Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-04-08 15:23:57 +00:00
endif()
Add support for benchmark conversion Convert benchmark executables to add_qt_benchmark(). Currently add_qt_benchmark just calls add_qt_executable() and ensures that it they build under CMAKE_CURRENT_BUILD_DIR and do not install. Add QT_BUILD_BENCHMARKS option to enable/disable building of benchmarks. Change-Id: Id0bc676698d21d50048d97d9abef51d92ccb6638 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-10-28 14:35:47 +00:00
# Disable benchmarks for single configuration generators which do not build
# with release configuration.
Allow benchmarks with --force-debug-info 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>
2021-01-28 09:43:17 +00:00
if (CMAKE_BUILD_TYPE AND CMAKE_BUILD_TYPE STREQUAL Debug)
Add support for benchmark conversion Convert benchmark executables to add_qt_benchmark(). Currently add_qt_benchmark just calls add_qt_executable() and ensures that it they build under CMAKE_CURRENT_BUILD_DIR and do not install. Add QT_BUILD_BENCHMARKS option to enable/disable building of benchmarks. Change-Id: Id0bc676698d21d50048d97d9abef51d92ccb6638 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-10-28 14:35:47 +00:00
set(__build_benchmarks OFF)
endif()
Introduce QT_SYNC_HEADERS_AT_CONFIGURE_TIME flag 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>
2023-02-15 14:36:44 +00:00
# Sync headers during the initial configuration of a -developer-build to facilitate code
# navigation for code editors that use an LSP-based code model.
set(_qt_sync_headers_at_configure_time_default TRUE)
Fix non-prefix builds for non qtbase repos QT_WILL_INSTALL was previously always set to ON when doing a qtdeclarative build, because CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT evaluated to false due to always having to set CMAKE_INSTALL_PREFIX to point to the qtbase build directory. Instead of recomputing the value of QT_WILL_INSTALL, compute it once while configuring qtbase, and add it to the generated QtBuildInternalsExtra.cmake file, so it propagates to all other repos that will be built. Change-Id: If8bf63e7501b5758fe7aa0f799cb0746704f4811 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-07-22 15:30:24 +00:00
else()
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
set(_qt_build_tests_default OFF)
Add support for benchmark conversion Convert benchmark executables to add_qt_benchmark(). Currently add_qt_benchmark just calls add_qt_executable() and ensures that it they build under CMAKE_CURRENT_BUILD_DIR and do not install. Add QT_BUILD_BENCHMARKS option to enable/disable building of benchmarks. Change-Id: Id0bc676698d21d50048d97d9abef51d92ccb6638 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-10-28 14:35:47 +00:00
set(__build_benchmarks OFF)
Allow prefix builds with developer-build as feature enabled Just like with qmake, separate the two "features". Change-Id: Idf2a796c7c4aaa740c471688b2221d7041fed643 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-25 10:09:10 +00:00
endif()
Introduce QT_SYNC_HEADERS_AT_CONFIGURE_TIME flag 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>
2023-02-15 14:36:44 +00:00
# Sync Qt header files at configure time
option(QT_SYNC_HEADERS_AT_CONFIGURE_TIME "Run syncqt at configure time already"
${_qt_sync_headers_at_configure_time_default})
unset(_qt_sync_headers_at_configure_time_default)
# In static Ninja Multi-Config builds the sync_headers dependencies(and other autogen dependencies
# are not added to '_autogen/timestamp' targets. See QTBUG-113974.
if(CMAKE_GENERATOR STREQUAL "Ninja Multi-Config" AND NOT QT_BUILD_SHARED_LIBS)
set(QT_SYNC_HEADERS_AT_CONFIGURE_TIME TRUE CACHE BOOL "" FORCE)
endif()
CMake: Add extra targets to run single benchmark using CMake generator Add custom targets with '_benchmark' suffixes to make run of benchmarks using generators possible, e.g.: $ ninja tst_bench_qudpsocket_benchmark Extend '-[no]make' option to pass benchmark. Rework '-[no]make' processing to unify these options processing. Also looks like it doesn't make sense to enable benchmarks without having test enabled. So '-DQT_BUILD_BENCHMARKS' enables test as own dependency automatically. Task-number: QTBUG-89076 Pick-to: 6.0 Change-Id: Ieee9eadaf6d75a1efec120242d6eb786ace1b071 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-03 18:13:08 +00:00
# Build Benchmarks
option(QT_BUILD_BENCHMARKS "Build Qt Benchmarks" ${__build_benchmarks})
if(QT_BUILD_BENCHMARKS)
set(_qt_build_tests_default ON)
endif()
CMake: Disable autotests for non-developer builds Mimic the behavior in the qmake build system, and by default build tests for developer-build, and not build it for a normal build. To do this, we define BUILD_TESTING with the right default before including CTest, which does otherwise define the option itself. Change-Id: Ifa1b1156477919abc1e916ccd9e1e0a74e969ee6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-05 12:49:09 +00:00
## Set up testing
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
option(QT_BUILD_TESTS "Build the testing tree." ${_qt_build_tests_default})
unset(_qt_build_tests_default)
option(QT_BUILD_TESTS_BY_DEFAULT "Should tests be built as part of the default 'all' target." ON)
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
if(QT_BUILD_STANDALONE_TESTS)
# BuildInternals might have set it to OFF on initial configuration. So force it to ON when
# building standalone tests.
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
set(QT_BUILD_TESTS ON CACHE BOOL "Build the testing tree." FORCE)
Always build tests by default when building standalone tests Amends 021c17c62f963a682c6a4b19f0c3d362c28a97ee Change-Id: I8181270ef7506eb5da4d3b43e105e100ed5581e4 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-13 09:20:09 +00:00
# Also force the tests to be built as part of the default build target.
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
set(QT_BUILD_TESTS_BY_DEFAULT ON CACHE BOOL
"Should tests be built as part of the default 'all' target." FORCE)
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
endif()
Revert "Avoid mapping BUILD_TESTING to QT_BUILD_TESTS" This reverts commit e3ecabad228369bfc6dc82085446d7acc05ef45a. 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>
2023-02-20 08:58:55 +00:00
set(BUILD_TESTING ${QT_BUILD_TESTS} CACHE INTERNAL "")
Make standalone tests build via top level repo project Previously repo/tests/CMakeLists.txt was a standalone project on which CMake could be called. This was useful for Coin to be able to build and package only tests, but was a bit troublesome because that means having to specify the usual boilerplate like minimum CMake version, which packages to find in every tests.pro project. Instead of having a separate standalone project, modify the top level project and associated CMake code to allow passing a special QT_BUILD_STANDALONE_TESTS variable, which causes the top level project to build only tests, and find Qt in the previously installed qt location. This also means that when building a repo, we generate a ${repo_name}TestsConfig.cmake file which does find_package on all the modules that have been built as part of that repo. So that when standalone tests bare built for that repo, the modules are automatically found. qt_set_up_standalone_tests_build() is modified to be a no-op because it is not needed anymore. Its usage should be removed from all the other repos, and then removed from qtbase. Non-adjusted tests/CMakeLists.txt projects in other repositories should still be buildable with the current code, until they are updated to the new format. Adjust the Coin build instructions to build the standalone tests in a separate directory. Adjust pro2cmake to generate new structure for the tests/tests.pro projects. Adjust the qtbase tests project. Fixes: QTBUG-79239 Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-01 10:48:23 +00:00
wasm: Enable batch tests by default on wasm 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>
2022-10-18 13:16:49 +00:00
if (WASM)
Implement the batch_tests feature 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>
2022-07-12 16:15:24 +00:00
set(_qt_batch_tests ON)
wasm: Enable batch tests by default on wasm 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>
2022-10-18 13:16:49 +00:00
else()
set(_qt_batch_tests OFF)
endif()
if(DEFINED INPUT_batch_tests)
if (${INPUT_batch_tests})
set(_qt_batch_tests ON)
else()
set(_qt_batch_tests OFF)
endif()
Implement the batch_tests feature 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>
2022-07-12 16:15:24 +00:00
endif()
wasm: Enable batch tests by default on wasm 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>
2022-10-18 13:16:49 +00:00
Implement the batch_tests feature 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>
2022-07-12 16:15:24 +00:00
option(QT_BUILD_TESTS_BATCHED "Link all tests into a single binary." ${_qt_batch_tests})
Concatenate blacklist files for test batch 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>
2023-01-13 15:25:08 +00:00
if(QT_BUILD_TESTS AND QT_BUILD_TESTS_BATCHED AND CMAKE_VERSION VERSION_LESS "3.19")
Implement the batch_tests feature 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>
2022-07-12 16:15:24 +00:00
message(FATAL_ERROR
Concatenate blacklist files for test batch 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>
2023-01-13 15:25:08 +00:00
"Test batching requires at least CMake 3.19, due to requiring per-source "
"TARGET_DIRECTORY assignments and DEFER calls.")
Implement the batch_tests feature 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>
2022-07-12 16:15:24 +00:00
endif()
CMake: Fix initialization of QT_BUILD_TOOLS_BY_DEFAULT ...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 acfbe3b7795c741b269fc23ed2c51c5937cd7f4f. Change-Id: Ibdba54da943aea1b55618f10d2b8485f4390878a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-05-11 13:17:40 +00:00
# QT_BUILD_TOOLS_WHEN_CROSSCOMPILING -> QT_FORCE_BUILD_TOOLS
# pre-6.4 compatibility flag (remove sometime in the future)
if(CMAKE_CROSSCOMPILING AND QT_BUILD_TOOLS_WHEN_CROSSCOMPILING)
message(WARNING "QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated. "
"Please use QT_FORCE_BUILD_TOOLS instead.")
set(QT_FORCE_BUILD_TOOLS TRUE CACHE INTERNAL "" FORCE)
endif()
CMake: Allow excluding tools and apps from the default 'all' target Qt uses the qtNomakeTools() function to mark a directory which will not be built as part of the default target. This is especially important when cross-compiling (to iOS for example) because the build process might fail. The condition for not building these "GUI tool sub-directory projects" is the absence of the "tools" value in qmake's QT_BUILD_PARTS variable. Introduce a QT_NO_MAKE_TOOLS CMake variable. If the value is true, it's equivalent to "tools" not being present in QT_BUILD_PARTS. Introduce qt_exclude_tool_directories_from_default_target(). It's the qmake counter part to qtNomakeTools(). Teach pro2cmake to generate it where appropriate. Change-Id: If2e5958d91847ab139af0e452608510286e73fa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-26 16:42:48 +00:00
# When cross-building, we don't build tools by default. Sometimes this also covers Qt apps as well.
# Like in qttools/assistant/assistant.pro, load(qt_app), which is guarded by a qtNomakeTools() call.
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
set(_qt_build_tools_by_default_default ON)
CMake: also allow building tools when found elsewhere in host builds 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>
2022-01-10 18:12:32 +00:00
if(CMAKE_CROSSCOMPILING AND NOT QT_FORCE_BUILD_TOOLS)
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
set(_qt_build_tools_by_default_default OFF)
CMake: Make it possible to build tools when cross-compiling This patch allows tools to be built for the target platform when the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration time. To avoid naming conflicts, the target tools are suffixed with "_native". The qt_get_tool_target_name() function can be used to get the tool name for both scenarios (cross and non-cross compilation). Extend pro2cmake to refer to the right target name for tools. The relevant write_XXX functions have a new target_ref parameter that will be "${target_name}" for tools and literally the target name for everything else. Fixes: QTBUG-81901 Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-27 13:04:57 +00:00
endif()
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
option(QT_BUILD_TOOLS_BY_DEFAULT "Should tools be built as part of the default 'all' target."
"${_qt_build_tools_by_default_default}")
unset(_qt_build_tools_by_default_default)
CMake: Allow excluding tools and apps from the default 'all' target Qt uses the qtNomakeTools() function to mark a directory which will not be built as part of the default target. This is especially important when cross-compiling (to iOS for example) because the build process might fail. The condition for not building these "GUI tool sub-directory projects" is the absence of the "tools" value in qmake's QT_BUILD_PARTS variable. Introduce a QT_NO_MAKE_TOOLS CMake variable. If the value is true, it's equivalent to "tools" not being present in QT_BUILD_PARTS. Introduce qt_exclude_tool_directories_from_default_target(). It's the qmake counter part to qtNomakeTools(). Teach pro2cmake to generate it where appropriate. Change-Id: If2e5958d91847ab139af0e452608510286e73fa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-26 16:42:48 +00:00
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
include(CTest)
enable_testing()
CMake: Name QT_NO_MAKE_*/BUILD_* variables consistently For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 11:35:15 +00:00
option(QT_BUILD_EXAMPLES "Build Qt examples" OFF)
option(QT_BUILD_EXAMPLES_BY_DEFAULT "Should examples be built as part of the default 'all' target." ON)
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 10:15:35 +00:00
option(QT_INSTALL_EXAMPLES_SOURCES "Install example sources" OFF)
option(QT_INSTALL_EXAMPLES_SOURCES_BY_DEFAULT
"Install example sources as part of the default 'install' target" ON)
Propagate BUILD_TESTING and BUILD_EXAMPLES As with qmake, you configure with or without -nomake tests -nomake examples, and the choice is propagated to other repositories. Do the same for CMake. It's still possible to opt out to build one or the other by passing -DBUILD_TESTING=OFF -DBUILD_EXAMPLES=OFF on the command line, which takes precedence over the value saved to QtBuildInternalsExtra. Change-Id: If0fbfa938d88309e7969c9bacc8d0bf86548bf5e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-06 09:52:47 +00:00
CMake: Temporarily disable building external examples in prefix builds 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 98c89c8cc1c5ceb4bfbb5f5ed6c96ecdbab99afa 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>
2022-02-03 11:06:20 +00:00
# FIXME: Support prefix builds as well QTBUG-96232
if(QT_WILL_INSTALL)
set(_qt_build_examples_as_external OFF)
else()
set(_qt_build_examples_as_external ON)
endif()
option(QT_BUILD_EXAMPLES_AS_EXTERNAL "Should examples be built as ExternalProjects."
${_qt_build_examples_as_external})
unset(_qt_build_examples_as_external)
CMake: Allow opting out of building examples as ExternalProjects 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 dab8f64b6d5d4241b678d0227355858071376496 Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 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>
2021-09-03 15:08:50 +00:00
Offer to build manual tests through QT_BUILD_MANUAL_TESTS Disabled by default as they are currently not being built and many are not working properly, this will allow us to start using them again. Change-Id: I823368d04e9fde2beccabedc3ca15efd1f355bfb Pick-to: 6.0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-16 17:31:56 +00:00
option(QT_BUILD_MANUAL_TESTS "Build Qt manual tests" OFF)
wasm: enable QT_BUILD_MINIMAL_STATIC_TESTS by default 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>
2022-09-27 12:51:09 +00:00
if(WASM)
option(QT_BUILD_MINIMAL_STATIC_TESTS "Build minimal subset of tests for static Qt builds" ON)
else()
option(QT_BUILD_MINIMAL_STATIC_TESTS "Build minimal subset of tests for static Qt builds" OFF)
endif()
Build minimal subset of tests for Android multi-ABI Qt builds 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>
2022-06-21 13:32:00 +00:00
option(QT_BUILD_MINIMAL_ANDROID_MULTI_ABI_TESTS
"Build minimal subset of tests for Android multi-ABI Qt builds" OFF)
Offer to build manual tests through QT_BUILD_MANUAL_TESTS Disabled by default as they are currently not being built and many are not working properly, this will allow us to start using them again. Change-Id: I823368d04e9fde2beccabedc3ca15efd1f355bfb Pick-to: 6.0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-16 17:31:56 +00:00
CMake: Move Qt6HostInfo lookup into a function 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>
2022-07-15 16:14:20 +00:00
## Path used to find host tools, either when cross-compiling or just when using the tools from
## a different host build.
CMake: Read QT_HOST_PATH from the environment too 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>
2022-02-24 10:44:11 +00:00
set(QT_HOST_PATH "$ENV{QT_HOST_PATH}" CACHE PATH
"Installed Qt host directory path, used for cross compiling.")
CMake: Support cross-compilation with qmake When cross-compiling, we now create a target_qt.conf file that's to be used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf" projects can be cross-built against the cross-built Qt. We also create wrapper scripts for the host qmake to save the user from passing the -qtconf argument. Fixes: QTBUG-82581 Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-18 08:07:22 +00:00
Android: Move Platform Include Move the include of the platform from QtPlatformSupport to QtSetup. This no longer causes compile tests to fail since they expect explicit include paths instead of using CMAKE_MODULE_PATH. Change-Id: I9d3bed7845104d84422afb5a976ec14b111d259d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 08:31:55 +00:00
## Android platform settings
if(ANDROID)
include(QtPlatformAndroid)
endif()
Rename / prefix all our private API functions with qt_ Rename internal APIs like extend_target to qt_extend_target. Prefix apis with qt_ where required. Keep old names for compatibility until all their usages are removed. Change-Id: I9a13515a01857257a4c5be3a89253749d46a4f41 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-13 13:03:20 +00:00
## qt_add_module and co.:
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
include(QtBuild)
## Qt Feature support:
CMake: Port most of the configure summary support Teaches configurejson2cmake about summaries / reports, so things like enabled features, configure sections, notes, etc. Add relevant CMake API for adding summary sections and entries, as well as configure reports. The commands record the passed data, and the data is later evaluated when the summary needs to be printed. This is needed, to ensure that all features are evaluated by the time the summary is printed. Some report and summary entries are not generated if they mention a feature that is explicitly exclduded by configurejson2cmake's feature mapping dictionary. This is to prevent CMake from failing at configure time when trying to evaluate an unknown feature. We should re-enable these in the future. A few custom report types are skipped by configurejson2cmake (like values of qmake CONFIG or buildParts). These will have to be addressed a case-by-case basis if still needed. Change-Id: I95d74ce34734d347681905f15a781f64b5bd5edc Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-03-02 17:06:46 +00:00
include(QtBuildInformation)
Begin port of qtbase to CMake Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2018-10-24 13:20:27 +00:00
include(QtFeature)
## Compiler optimization flags:
include(QtCompilerOptimization)
cmake: Start adding compiler flags Only has warnings for now Next to come is the support for developer-build and enabling Werror Change-Id: I8070dc06eb439c2a03007cce975c8147ff7e1582 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2019-02-19 16:37:30 +00:00
## Compiler flags:
include(QtCompilerFlags)
Pick the latest available C/C++ standard when compiling Qt This maps the behavior of mkspecs/features/qt_common.prf and enables the use of C++17 for example in Android, where the toolchain supports it anyway. Change-Id: I41f4bdb160a3929e2fb78f36efb1ad5f2ad391a5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
2019-10-17 08:14:09 +00:00
qt_set_language_standards()
Add support for building conveniently with ccache Pass -DQT_USE_CCACHE=ON to enable the use of ccache. This avoids having to set up symlinks, which is useful when cross-compiling against different targets. Change-Id: I023fff105baaa538730997948aa122d2678887ce Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2019-02-12 11:21:30 +00:00
option(QT_USE_CCACHE "Enable the use of ccache")
if(QT_USE_CCACHE)
find_program(CCACHE_PROGRAM ccache)
CMake: Fix usage of ccache when no executable was found Change-Id: Ia9a44234cb074fa5ba2b1dc9ca22a676d1b2d4ce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-17 14:31:38 +00:00
if(CCACHE_PROGRAM)
set(CMAKE_C_COMPILER_LAUNCHER "${CCACHE_PROGRAM}")
set(CMAKE_CXX_COMPILER_LAUNCHER "${CCACHE_PROGRAM}")
set(CMAKE_OBJC_COMPILER_LAUNCHER "${CCACHE_PROGRAM}")
set(CMAKE_OBJCXX_COMPILER_LAUNCHER "${CCACHE_PROGRAM}")
else()
CMake: Error out if ccache is requested but not found 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>
2021-08-27 09:43:04 +00:00
message(FATAL_ERROR "Ccache use was requested, but the program was not found.")
CMake: Fix usage of ccache when no executable was found Change-Id: Ia9a44234cb074fa5ba2b1dc9ca22a676d1b2d4ce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-17 14:31:38 +00:00
endif()
Add support for building conveniently with ccache Pass -DQT_USE_CCACHE=ON to enable the use of ccache. This avoids having to set up symlinks, which is useful when cross-compiling against different targets. Change-Id: I023fff105baaa538730997948aa122d2678887ce Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2019-02-12 11:21:30 +00:00
endif()
CMake: Add detection of FEATURE_foo change by user Unset all QT_FEATURE_foo values for every build. If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt build as dirty. Reset FEATURE_foo for dirty builds to the calculated value if it doesn't meet its condition. Set Qt module as NOT FOUND if its target was not created during configuration. Main issue with this approach are generated files, that became trash once the related features are disabled. This especially affects features that enable/disable Qt modules. FooConfig.cmake files are created and generate lots of warnings if feature was disabled. We may introduce a module cleanup procedure at some point. Fixes: QTBUG-85962 Pick-to: 6.0 Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-11 15:11:35 +00:00
Add -unity-build, and -unity-build-batch-size to configure 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>
2023-02-08 11:08:37 +00:00
option(QT_UNITY_BUILD "Enable unity (jumbo) build")
Set 32 as the default batch size for unity build Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I4497d1abc85578649f03fc8ae4916f56e4f1f351 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2023-02-20 13:15:23 +00:00
set(QT_UNITY_BUILD_BATCH_SIZE "32" CACHE STRING "Unity build batch size")
Add -unity-build, and -unity-build-batch-size to configure 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>
2023-02-08 11:08:37 +00:00
if(QT_UNITY_BUILD)
set(CMAKE_UNITY_BUILD ON)
set(CMAKE_UNITY_BUILD_BATCH_SIZE "${QT_UNITY_BUILD_BATCH_SIZE}")
endif()
Introduce QT_ALLOW_SYMLINK_IN_PATHS flag `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>
2023-05-02 12:07:41 +00:00
option(QT_ALLOW_SYMLINK_IN_PATHS "Allows symlinks in paths." OFF)
CMake: Move dirty feature / dirty build detection into QtFeature.cmake 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>
2023-08-28 14:49:24 +00:00
qt_internal_detect_dirty_features()
CMake: Don't setup deployment when building Qt without examples 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>
2022-11-29 13:40:25 +00:00
if(NOT QT_BUILD_EXAMPLES)
# Disable deployment setup to avoid warnings about missing patchelf with CMake < 3.21.
set(QT_SKIP_SETUP_DEPLOYMENT ON)
endif()
Add the description for the QT_ALLOW_DOWNLOAD option 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>
2023-05-31 10:09:34 +00:00
option(QT_ALLOW_DOWNLOAD "Allows files to be downloaded when building Qt." OFF)
Reference in New Issue Copy Permalink