AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
5f28d367d9
qt5base-lts/CMakeLists.txt

201 lines
7.5 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: Enable NEW policies by CMake version with a global default When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-30 07:46:49 +00:00
# Need an explicit call at the top level. This is the absolute minimum version
# needed to configure the project with any combination of enabled features.
# The call to qt_build_repo_begin() will upgrade policies further.
CMake: Bump min required CMake version for shared Qt builds to 3.16 Building a shared library Qt configuration already required a minimum CMake version of 3.16, because we depend on CMake's Autogen.json files which are used for metatype.json file generation. If a lower version was used, a FATAL_ERROR was issued in qt6_extract_metatypes. This change is essentially moving the check to happen earlier in the qtbase configure process. User projects will now /also/ officially require a minimum of 3.16 (up from 3.14). As a consequence, the min/max version policy range that is set in the public QtFooConfig.cmake files is changed from 3.14..3.19 to 3.16..3.20 The upper bound is raised because building and using Qt works fine with all CMake 3.20 policies set to NEW. [ChangeLog][CMake] Building Qt as shared libraries now requires CMake version 3.16 or later. Building user projects with CMake using that Qt installation also requires a CMake version of 3.16 or later. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: I77d2829370f1dfc90b4071bebc8a3ade654e59e6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-06 15:55:30 +00:00
#
# The absolute minimum version for building Qt is 3.16 because for metatype.json generation, we
# depend on being able to find the location of json files created by AUTOMOC/moc.
CMake: Enable NEW policies by CMake version with a global default When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-30 07:46:49 +00:00
cmake_minimum_required(VERSION 3.16)
CMake: Bump the minimum required CMake version to build Qt to 3.18 Add a new function that returns the minimum CMake version required to build Qt. Pass that value to cmake_minimum_required() when building qtbase and its standalone tests. The minimum supported CMake version is read from qtbase/.cmake.conf and its value should be updated when the need arises. It's the main source of truth for all repos. Provide a way to lower the minimum CMake version at configure time by passing a value via QT_FORCE_MIN_CMAKE_VERSION. This is not an officially supported way of building Qt. If the specified version is lower than Qt's supported minimum, show a warning. Nevertheless the option is useful for testing how Qt builds with a different minimum CMake version due to different policies being enabled by default. Issue warnings for CMake versions that are higher than the minimum version but are known to cause issues when building Qt. A counterpart change is needed in qt5 to ensure the minimum CMake version is set at the proper time for top-level builds. Ideally we would use the same 'check the CMake minimum version` code in all our repositories, but that will cause lots of duplication because we can't really find_package() the code and doing something like include(../qtbase/foo.cmake) hardcodes assumptions about repo locations. So for now we don't bump the minimum version in child repo cmake_minimum_required calls (qtsvg, qtdeclarative, etc). Instead we record both the minimum supported version and the computed minimum version (in case a different version was forced) in QtBuildInternalsExtra.cmake. Then we require qtbase's computed min version in qt_build_repo_begin(). This won't set policies as cmake_minimum_required would, but at least it propagates what minimum CMake version should be used for child repos. We might still have to bump the versions in child repos at some point. Task-number: QTBUG-88086 Change-Id: Ida1c0d5d3e0fbb15d2aee9b68abab7a1648774b9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-30 16:42:34 +00:00
CMake: Enable NEW policies by CMake version with a global default When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-30 07:46:49 +00:00
# Get the repo version and CMake policy details
include(.cmake.conf)
Be more helpful about the symlinked build directory problem - Explain why a symlinked build dir won't work - Add another workaround suggestion that works well in my case Change-Id: I3f7eaeac2974e037587941f6f761fbcb262c4631 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-14 12:48:19 +00:00
# Bail out if any part of the build directory's path is symlinked.
Use IS_SYMLINK condition instead of REALPATH when checking BINARY_DIR For case-insensitive file systems, the REALPATH file component may return file paths in a different case than ABSOULEPATH. We use REALPATH to detect symlinks. In case-sensitive file systems there still might be the situation when /path/to/Build is a symlink to the /path/to/build, so we cannot make the comparison case-insensitive. Use the IS_SYMLINK check instead. Pick-to: 6.2 6.3 Fixes: QTBUG-99416 Change-Id: Idf998b9e09837a834139553fb822e05b2a0a1949 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-23 12:20:21 +00:00
function(qt_internal_check_if_path_has_symlinks path)
get_filename_component(dir "${path}" ABSOLUTE)
Use REALPATH based check for symbolic links on Windows Windows mount points are marked as symbolic links by CMake. So switch back to the REALPATH based check for Windows hosts. Amends dcc2704d17bda08e6dc7783559ccbfd864dd4339 Pick-to: 6.2 6.3 Task-number: QTBUG-99416 Change-Id: Ic996db1fac5c0b5edc18728535240e272dd435e0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-01-05 11:38:22 +00:00
set(is_symlink FALSE)
if(CMAKE_HOST_WIN32)
# CMake marks Windows mount points as symbolic links, so use simplified REALPATH check
# on Windows platforms instead of IS_SYMLINK.
get_filename_component(dir_realpath "${dir}" REALPATH)
if(NOT dir STREQUAL dir_realpath)
set(is_symlink TRUE)
Use IS_SYMLINK condition instead of REALPATH when checking BINARY_DIR For case-insensitive file systems, the REALPATH file component may return file paths in a different case than ABSOULEPATH. We use REALPATH to detect symlinks. In case-sensitive file systems there still might be the situation when /path/to/Build is a symlink to the /path/to/build, so we cannot make the comparison case-insensitive. Use the IS_SYMLINK check instead. Pick-to: 6.2 6.3 Fixes: QTBUG-99416 Change-Id: Idf998b9e09837a834139553fb822e05b2a0a1949 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-23 12:20:21 +00:00
endif()
Use REALPATH based check for symbolic links on Windows Windows mount points are marked as symbolic links by CMake. So switch back to the REALPATH based check for Windows hosts. Amends dcc2704d17bda08e6dc7783559ccbfd864dd4339 Pick-to: 6.2 6.3 Task-number: QTBUG-99416 Change-Id: Ic996db1fac5c0b5edc18728535240e272dd435e0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-01-05 11:38:22 +00:00
else()
while(TRUE)
if(IS_SYMLINK "${dir}")
set(is_symlink TRUE)
break()
endif()
Use IS_SYMLINK condition instead of REALPATH when checking BINARY_DIR For case-insensitive file systems, the REALPATH file component may return file paths in a different case than ABSOULEPATH. We use REALPATH to detect symlinks. In case-sensitive file systems there still might be the situation when /path/to/Build is a symlink to the /path/to/build, so we cannot make the comparison case-insensitive. Use the IS_SYMLINK check instead. Pick-to: 6.2 6.3 Fixes: QTBUG-99416 Change-Id: Idf998b9e09837a834139553fb822e05b2a0a1949 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-23 12:20:21 +00:00
Use REALPATH based check for symbolic links on Windows Windows mount points are marked as symbolic links by CMake. So switch back to the REALPATH based check for Windows hosts. Amends dcc2704d17bda08e6dc7783559ccbfd864dd4339 Pick-to: 6.2 6.3 Task-number: QTBUG-99416 Change-Id: Ic996db1fac5c0b5edc18728535240e272dd435e0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-01-05 11:38:22 +00:00
set(prev_dir "${dir}")
get_filename_component(dir "${dir}" DIRECTORY)
if("${dir}" STREQUAL "${prev_dir}")
return()
endif()
endwhile()
endif()
if(is_symlink)
message(FATAL_ERROR "The path \"${path}\" contains symlinks. \
This is not supported. Possible solutions:
- map directories using a transparent mechanism such as mount --bind
- pass the real path of the build directory to CMake, e.g. using \
cd $(realpath <path>) before invoking cmake <source_dir>.")
endif()
Use IS_SYMLINK condition instead of REALPATH when checking BINARY_DIR For case-insensitive file systems, the REALPATH file component may return file paths in a different case than ABSOULEPATH. We use REALPATH to detect symlinks. In case-sensitive file systems there still might be the situation when /path/to/Build is a symlink to the /path/to/build, so we cannot make the comparison case-insensitive. Use the IS_SYMLINK check instead. Pick-to: 6.2 6.3 Fixes: QTBUG-99416 Change-Id: Idf998b9e09837a834139553fb822e05b2a0a1949 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-23 12:20:21 +00:00
endfunction()
qt_internal_check_if_path_has_symlinks("${CMAKE_BINARY_DIR}")
CMake: Bail out if the build dir is symlinked Building Qt in a symlinked build directory leads to all kind of issues, like unnecessary rebuilds, strange compilation errors or already errors at configure time. Detect this situation and bail out early with an informative error message. Task-number: QTBUG-88418 Task-number: QTBUG-89559 Change-Id: I70c16e11a7eede7a183f6f56b73ea93f985312f3 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io>
2020-12-17 12:41:38 +00:00
CMake: Do not run auto-detection in top-level builds The top-level CMakeLists.txt already does that to ensure that QtAutoDetect is included before any project command, meaning before any toolchain file is loaded. Task-number: QTBUG-87309 Change-Id: I60a998bdf999b6f751e4ebec2d13491fb206b132 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-09 09:48:23 +00:00
# Run auto detection routines, but not when doing standalone tests. In that case, the detection
# results are taken from either QtBuildInternals or the qt.toolchain.cmake file. Also, inhibit
# auto-detection in a top-level build, because the top-level project file already includes it.
Fix double inclusion of QtAutoDetect.cmake in top-level build The variable we need to check is called QT_SUPERBUILD, not QT_SUPER_BUILD. Pick-to: 6.1 6.0 Change-Id: I8487f491a0a4cebdf08f579519e99e6afe3db8c2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-03-04 09:42:34 +00:00
if(NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_SUPERBUILD)
CMake: Protect against Qt toolchain file recursive inclusion Three different people have encountered the issue that calling calling qt-cmake on a project prints 1000 inclusion lines of the same qt toolchain file, and then CMake bails out saying can't find the CMAKE_MAKE_PROGRAM Ninja. This happened because people accidentally called qt-cmake to configure qtbase (instead of just cmake), which created a toolchain file that chainloads itself recursively. Error out when configuring qtbase, and when using the generated toolchain file in the case when it would try to include itself. The solution is to remove the qtbase CMakeCache.txt file, and configure qtbase again, so it generates a proper qt.toolchain.cmake file. If somebody feels enthusiastic, they can move the check into the qt-cmake and qt-cmake-private shell scripts, and error out before the qtbase/CMakeCache.txt is polluted with the wrong toolchain file. That is left for people that feel more comfortable with bash and batch scripting. Change-Id: If518c94791fe7c30731e6e462e347f26a5213c64 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-06-02 16:06:37 +00:00
include(${CMAKE_CURRENT_SOURCE_DIR}/cmake/QtAutoDetect.cmake)
endif()
Add support for vcpkg default target triplets As per vcpkg documentation, this is a tweak that allows respecting the vcpkg default target triplet environment variable, which simplifies the command line slightly. In order to make this also work for modules other than qtbase, we're going to need to consider the creation of a toolchain file. Change-Id: I2573f6644d671c710fd823df83e2205dbbfe19e6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-06-20 11:23:19 +00:00
CMake: Bump min required CMake version for static Qt builds to 3.20 Building a static library Qt configuration will now require a minimum CMake version of 3.20. Qt builders and packagers can still opt out of the mentioned minimum required version by configuring Qt with QT_FORCE_MIN_CMAKE_VERSION. Such a Qt configuration is /NOT SUPPORTED/. To facilitate these changes, the minimum version check has been moved to happen after the BUILD_SHARED_LIBS option is computed by either QtAutoDetect.cmake or set by a user provided cmake toolchain file. Introduce a new QT_MIN_SUPPORTED_CMAKE_VERSION_FOR_STATIC_QT variable in .cmake.conf to mark the minimum version for a static Qt build. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: Idc1875729f26a7c635b6bd26ac0c1be973917c13 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-07-06 15:55:30 +00:00
# This call will load any provided cmake toolchain file.
CMake: fix android target build not picking the correct sysroot This previous way caused target builds under Linux to pick the host packages like udev and mtdev and build for them which they will fail during the build. Task-number: QTBUG-86028 Change-Id: Ic029f0a3e71b50c694473a110922f0ef11e5b0bf Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-13 10:05:13 +00:00
project(QtBase
VERSION "${QT_REPO_MODULE_VERSION}"
DESCRIPTION "Qt Base Libraries"
HOMEPAGE_URL "https://qt.io/"
LANGUAGES CXX C ASM
)
CMake: Bump min required CMake version for static Qt builds to 3.20 Building a static library Qt configuration will now require a minimum CMake version of 3.20. Qt builders and packagers can still opt out of the mentioned minimum required version by configuring Qt with QT_FORCE_MIN_CMAKE_VERSION. Such a Qt configuration is /NOT SUPPORTED/. To facilitate these changes, the minimum version check has been moved to happen after the BUILD_SHARED_LIBS option is computed by either QtAutoDetect.cmake or set by a user provided cmake toolchain file. Introduce a new QT_MIN_SUPPORTED_CMAKE_VERSION_FOR_STATIC_QT variable in .cmake.conf to mark the minimum version for a static Qt build. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: Idc1875729f26a7c635b6bd26ac0c1be973917c13 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-07-06 15:55:30 +00:00
# Should this Qt be static or dynamically linked?
option(BUILD_SHARED_LIBS "Build Qt statically or dynamically" ON)
set(QT_BUILD_SHARED_LIBS ${BUILD_SHARED_LIBS})
# This variable is also set in Qt6CoreConfigExtras.cmake, but it's not loaded when building
# qtbase. Set it here so qt_add_plugin can compute the proper plugin flavor.
set(QT6_IS_SHARED_LIBS_BUILD ${BUILD_SHARED_LIBS})
# BUILD_SHARED_LIBS influences the minimum required CMake version. The value is set either by:
# a cache variable provided on the configure command line
# or set by QtAutoDetect.cmake depending on the platform
# or specified via a toolchain file that is loaded by the project() call
# or set by the option() call above
include("${CMAKE_CURRENT_SOURCE_DIR}/cmake/QtCMakeVersionHelpers.cmake")
CMake: Enforce minimum CMake version in user projects This change introduces new behavior to error out when configuring user projects if the CMake version used is too old for Qt to work with. The main motivator is the requirement of new CMake features to ensure object libraries are placed in the proper place on the link line in static builds. The minimum CMake version is computed based on whether Qt was configured as shared or static libraries. At the moment the required versions for building and using Qt are the same. The minimum versions are defined in qtbase/.cmake.conf in the following variables QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_STATIC QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_STATIC Qt Packagers can disable the version check when configuring Qt by setting QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT and QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT. In this case it is the packagers responsibility to ensure such a Qt works correctly with the specified CMake version. User projects can also set QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT to disable the version check. Then it's the project's developer responsibility to ensure such a Qt works correctly. No official support is provided for these cases. Implementation notes. The versions required to build Qt are stored in QtBuildInternalsExtra.cmake whereas the versions required to use Qt are stored in a new QtConfigExtras.cmake. Also the policy range variables stored in QtBuildInternalsExtra.cmake are now regular variables instead of cache variables, to properly allow overrides per-repository. Some renaming of functions and variables was done for a bit more clarity and easier grep-ability. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: I4279f2e10b6d3977319237ba21e2f4ed676aa48b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-22 14:23:51 +00:00
include("${CMAKE_CURRENT_SOURCE_DIR}/cmake/QtPublicCMakeVersionHelpers.cmake")
qt_internal_check_and_warn_about_unsuitable_cmake_version()
CMake: Bump min required CMake version for static Qt builds to 3.20 Building a static library Qt configuration will now require a minimum CMake version of 3.20. Qt builders and packagers can still opt out of the mentioned minimum required version by configuring Qt with QT_FORCE_MIN_CMAKE_VERSION. Such a Qt configuration is /NOT SUPPORTED/. To facilitate these changes, the minimum version check has been moved to happen after the BUILD_SHARED_LIBS option is computed by either QtAutoDetect.cmake or set by a user provided cmake toolchain file. Introduce a new QT_MIN_SUPPORTED_CMAKE_VERSION_FOR_STATIC_QT variable in .cmake.conf to mark the minimum version for a static Qt build. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: Idc1875729f26a7c635b6bd26ac0c1be973917c13 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-07-06 15:55:30 +00:00
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(NOT QT_BUILD_STANDALONE_TESTS)
## Add some paths to check for cmake modules:
list(PREPEND CMAKE_MODULE_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/3rdparty/extra-cmake-modules/find-modules"
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/3rdparty/kwin"
)
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(MACOS)
cmake: Add default Info.plist for macOS with some important keys The default Info.plist shipped with CMake lacks an NSPrincipalClass entry, which is crucial for making macOS apps run in full resolution on retina screens. We make sure the file is only picked up on macOS, not iOS and friends, since those platforms require another principal class. If needed we can extract the value out as a CMake variable and use the same file for all Apple platforms. Doing so would assume all keys are single-platform only, so if that's not the case we need platform-specific files. We should probably extract the package type out as a variable too, so that the file can be used for both apps, plugins, and frameworks, but doing so requires setting up that variable somewhere based on the target type, which CMake doesn't allow in an easy way. The file itself is based on the file CMake ships, combined with keys inherited from Qt's existing plist templates for qmake, and adjusted to match what Xcode generates by default these days. Change-Id: I3f5109e5fff63cdbd109a99d4008948d4bd2102b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-11 20:45:50 +00:00
# Add module directory to pick up custom Info.plist template
list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/macos")
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
elseif(IOS)
# Add module directory to pick up custom Info.plist template
list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/ios")
cmake: Add default Info.plist for macOS with some important keys The default Info.plist shipped with CMake lacks an NSPrincipalClass entry, which is crucial for making macOS apps run in full resolution on retina screens. We make sure the file is only picked up on macOS, not iOS and friends, since those platforms require another principal class. If needed we can extract the value out as a CMake variable and use the same file for all Apple platforms. Doing so would assume all keys are single-platform only, so if that's not the case we need platform-specific files. We should probably extract the package type out as a variable too, so that the file can be used for both apps, plugins, and frameworks, but doing so requires setting up that variable somewhere based on the target type, which CMake doesn't allow in an easy way. The file itself is based on the file CMake ships, combined with keys inherited from Qt's existing plist templates for qmake, and adjusted to match what Xcode generates by default these days. Change-Id: I3f5109e5fff63cdbd109a99d4008948d4bd2102b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-11 20:45:50 +00:00
endif()
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
## Find the build internals package.
set(QT_BUILD_INTERNALS_SKIP_CMAKE_MODULE_PATH_ADDITION TRUE)
list(PREPEND CMAKE_PREFIX_PATH
"${CMAKE_CURRENT_SOURCE_DIR}/cmake"
)
find_package(QtBuildInternals CMAKE_FIND_ROOT_PATH_BOTH)
unset(QT_BUILD_INTERNALS_SKIP_CMAKE_MODULE_PATH_ADDITION)
else()
# When building standalone tests, an istalled BuildInternals package already exists.
find_package(Qt6 REQUIRED COMPONENTS BuildInternals CMAKE_FIND_ROOT_PATH_BOTH)
endif()
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
Introduce the qt_internal_project_setup macro The macro sets the required CMake variables and policies and should be called right after the find_package(Qt6 COMPONENTS BuildInternals... call to make sure that the subsequent code adopt all the required policies. Pick-to: 6.5 Task-number: QTBUG-112685 Change-Id: I9f93f728ee4d8ae7743db9fffafa26025c76dcf2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-04-12 13:04:14 +00:00
qt_internal_project_setup()
Include QtPlatformSupport as part of find_package(Qt6BuildInternals) This is needed because the ported over requires() clauses from qmake to CMake are executed before qt_repo_build(), which means that all the custom platform variables that we set (like LINUX, APPLE_OSX) need to be available immediately after finding BuildInternals. Change-Id: I7345b69edf72c266508846766e64f42c99862d1d Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-26 15:58:53 +00:00
qt_build_repo_begin()
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
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(NOT QT_BUILD_STANDALONE_TESTS)
## Should this Qt be built with Werror?
option(WARNINGS_ARE_ERRORS "Build Qt with warnings as errors" ${FEATURE_developer_build})
Fix usage of BUILD_SHARED_LIBS in configure.cmake Feature conditions that used BUILD_SHARED_LIBS evaluated to false, e.g. FEATURE_framework. The options must be declared before the configuration files are included. Change-Id: I1ccda8234b334371d22e19f7f6d4fba3a1e7b857 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-07 07:51:03 +00:00
CMake: add an option to enable or disable versioned hard link The option is called QT_CREATE_VERSIONED_HARD_LINK. By default, it is set to ON. Users can set this option to OFF to disable versioned hard link. Pick-to: 6.1 Fixes: QTBUG-93636 Change-Id: I0ffa1ee1c6bae1950df332fcce3152a861b33db0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-12 12:03:57 +00:00
## Should this Qt create versioned hard link for some tools?
option(QT_CREATE_VERSIONED_HARD_LINK "Enable the use of versioned hard link" 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
## QtBase specific configure tests:
include(QtBaseConfigureTests)
CMake: Add option to run cmake build tests Use "cmake -DBUILD_CMAKE_TESTING=ON" to enable running cmake build system tests with ctest. Change-Id: I0a32e2d1771c9bbb0df013d0d955a9b58b1d4b79 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
2018-11-14 12:37:52 +00:00
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
## Build System tests:
include(QtBaseCMakeTesting)
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
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
## Targets for global features, etc.:
include(QtBaseGlobalTargets)
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
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
## Set language standards after QtBaseGlobalTargets, because that's when the relevant
## feature variables are available.
qt_set_language_standards()
Export tool config and target files for each relevant module CMake will now generate config and target files for each module that provides tools. As a result, namespaced global targets such as Qt5::moc or Qt5::rcc can be made available. Third party projects that require just these tools, and not the Qt modules themselves, should specify CMAKE_PREFIX_PATH pointing to the installed Qt location, and call find_package(Qt5CoreTools), find_package(Qt5GuiTools), etc. It is also possible to call find_package(Qt5Tools REQUIRED Core Widgets) where the last option is a list of modules whose tools should be imported. Note that all the tools are in the Qt5:: namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools:: namespace. This commit also changes the behavior regarding when to build tools while building Qt itself. When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when -DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will always be searched for and not built. In this case the user has to specify the CMake variable QT_HOST_PATH pointing to an installed host Qt location. When not cross compiling, tools added by add_qt_tool are built from source. When building leaf modules (like qtsvg) that require some tool that was built in qtbase (like moc), the module project should contain a find_package(Qt5ToolsCore) call and specify an appropriate CMAKE_PREFIX_PATH so that the tool package is found. Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH, the ensure syncqt code was changed to make it work properly with both qtbase and qtsvg. Here's a list of tools and their module associations: qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools qvkgen -> GuiTools uic -> WidgetTools dbus related tools -> DBusTools Task-number: QTBUG-74134 Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2019-04-10 17:21:22 +00:00
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
#include CoreMacros() for qt6_generate_meta_types()
CMake: Fix tst_moc to build when tests are built as part of Qt tree tst_moc uses qt_wrap_cpp, which tries to dispatch to qt6_wrap_cpp depending on the value of QT_DEFAULT_MAJOR_VERSION. That value is only set in Qt6CoreConfigExtras.cmake.in, which is not loaded as part of the qtbase build unless something does find_package(Qt6Core). Set the QT_DEFAULT_MAJOR_VERSION to 6 before including the Qt6CoreMacros in the qtbase top-level project. Change-Id: I7b81d89d965f755e51727007e68771ac3931ac55 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-21 14:59:17 +00:00
set(QT_DEFAULT_MAJOR_VERSION 6)
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
include(src/corelib/Qt6CoreMacros.cmake)
CMake: Split out some Android functions into a public API file To fix CMake Qt For Android projects to configure, we need to move some functions from a private CMake API file only, to a public one. Add Qt6AndroidMacros.cmake which will be loaded by Qt6Core package. We'll have to decide how we proceed with Qt5AndroidSupport.cmake, because that file automatically runs code when included in Qt5, and we usually don't want to do it. We'll also have to decide how to handle the define_property() calls that are still left in the private QtPlatformAndroid.cmake file. With this fix, Qt example CMake projects that use add_qt_gui_executable should now be buildable. An APK can be created with 'ninja apk'. Unfortunately Qt Creator 4.13 does not currently seem to support opening and building CMake Qt For Android projects properly. While the build succeeds after fiddling with the Kit settings, the APK deploy step fails to run (at least on my machine). So the simplest way to run the built APK is to open the android-build dir with Android Studio and launch the example application from there. Task-number: QTBUG-85399 Change-Id: I77f246331de7a6e9e6d4ba7d973730190138f136 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 15:53:37 +00:00
# Needed when building qtbase for android.
CMake: Fix global 'apk' target to actually build all apks This means calling 'ninja apk' in a user project with multiple android applications will build all their respective apks. For user projects, make the 'apk' target part of the global 'ALL' target, so that a regular 'ninja' call implies the 'apk' target. We don't do it currently for Qt builds, because certain test executable apks fail to build. Add a QT_NO_GLOBAL_APK_TARGET_PART_OF_ALL variable to allow removing the global apk target from the 'all' target. Pick-to: 6.1 Task-number: QTBUG-94264 Change-Id: I171b9da50eb7d670176704bd26dc1c492118b434 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-06-07 15:14:39 +00:00
if(ANDROID)
include(src/corelib/Qt6AndroidMacros.cmake)
Add _make_aab target Add target triggering AAB creation. Since the _make_aab target is not added to the ALL set, we may avoid dependency check for it and admit that the target is "always out of date". [ChangeLog][Android][Platform Specific Changes] Add the extra _make_aab targets for each executable target, that can be used to generate android app bundles. Also add aab metatarget to build all _make_aab targets that are created in the project. Pick-to: 6.2 Fixes: QTBUG-96710 Change-Id: I3b0c7fbb5a7dd493ca7a124c4e4b91fd857386bd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-18 09:27:47 +00:00
_qt_internal_create_global_android_targets()
CMake: Fix global 'apk' target to actually build all apks This means calling 'ninja apk' in a user project with multiple android applications will build all their respective apks. For user projects, make the 'apk' target part of the global 'ALL' target, so that a regular 'ninja' call implies the 'apk' target. We don't do it currently for Qt builds, because certain test executable apks fail to build. Add a QT_NO_GLOBAL_APK_TARGET_PART_OF_ALL variable to allow removing the global apk target from the 'all' target. Pick-to: 6.1 Task-number: QTBUG-94264 Change-Id: I171b9da50eb7d670176704bd26dc1c492118b434 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-06-07 15:14:39 +00:00
endif()
CMake: Split out some Android functions into a public API file To fix CMake Qt For Android projects to configure, we need to move some functions from a private CMake API file only, to a public one. Add Qt6AndroidMacros.cmake which will be loaded by Qt6Core package. We'll have to decide how we proceed with Qt5AndroidSupport.cmake, because that file automatically runs code when included in Qt5, and we usually don't want to do it. We'll also have to decide how to handle the define_property() calls that are still left in the private QtPlatformAndroid.cmake file. With this fix, Qt example CMake projects that use add_qt_gui_executable should now be buildable. An APK can be created with 'ninja apk'. Unfortunately Qt Creator 4.13 does not currently seem to support opening and building CMake Qt For Android projects properly. While the build succeeds after fiddling with the Kit settings, the APK deploy step fails to run (at least on my machine). So the simplest way to run the built APK is to open the android-build dir with Android Studio and launch the example application from there. Task-number: QTBUG-85399 Change-Id: I77f246331de7a6e9e6d4ba7d973730190138f136 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-14 15:53:37 +00:00
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 08:29:41 +00:00
if(WASM)
# Needed when building for WebAssembly.
include(cmake/QtWasmHelpers.cmake)
Include Qt6WasmMacros in WASM build This fixes the issue where WASM could not even be configured with autotests enabled. Change-Id: I0890d52754de92fa84be170906fcb0478e90304e Pick-to: 6.3 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
2022-01-03 09:22:08 +00:00
include(src/corelib/Qt6WasmMacros.cmake)
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 08:29:41 +00:00
qt_internal_setup_wasm_target_properties(Platform)
endif()
CMake: Refactor optimization flag handling and add optimize_full Introduce a bunch of helper functions to manipulate compiler flags and linker flags for the CMAKE_<LANG>_FLAGS_<CONFIG> and CMAKE_<LINK_TYPE>_LINKER_FLAGS_<CONFIG> CMake variables. These variables can be assigned and modified either in the cache or for a specific subdirectory scope, which will apply the flags only to targets in that scope. Add qt_internal_add_optimize_full_flags() function which mimics qmake's CONFIG += optimize_full behavior. Calling it will force usage of the '-O3' optimization flag on supported platforms (falling back '-O2' where not supported). Use the function for the Core and Gui subdirectories, to enable full optimization for the respective Qt modules as it is done in the qmake projects. To ensure that the global qmake-like compiler flags are assigned eveywhere, qt_internal_set_up_config_optimizations_like_in_qmake() needs to be called after Qt global features like optimize_size and optimize_full are available. This means that qtbase and its standalone tests need some special handling in regards to when to call that function. Task-number: QTBUG-86866 Change-Id: Ic7ac23de0265561cb06a0ba55089b6c0d3347441 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-02 13:38:47 +00:00
# Set up optimization flags like in qmake.
# This function must be called after the global QT_FEATURE_xxx variables have been set up,
# aka after QtBaseGlobalTargets is processed.
# It also has to be called /before/ adding add_subdirectory(src), so that per-directory
# modifications can still be applied if necessary (like in done in Core and Gui).
qt_internal_set_up_config_optimizations_like_in_qmake()
Add custom targets for documentation Adds custom targets which take care of generating and installing documentation files. Every module has a global set of targets suffixed with the module name in order for them to be unique when we implement super builds. The targets are the same as the list below, but replace ${target} with the module's name. Eg.: docs_qtbase. For every target which has an qt_add_docs() call, we now create the following set of custom targets: * docs_${target} * html_docs_${target} * qch_docs_${target} * prepare_docs_${target} * generate_docs_${target} * install_docs_${target} * install_html_docs_${target} * install_qch_docs_${target} Fixes: QTBUG-75859 Change-Id: Ie84cb9a2dedbe7333d9a84f4d73383442deca477 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-09-19 07:38:09 +00:00
## Setup documentation
add_subdirectory(doc)
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
## Visit all the directories:
add_subdirectory(src)
endif()
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
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
if(QT_BUILD_TESTS)
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
add_subdirectory(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
if(NOT QT_BUILD_TESTS_BY_DEFAULT)
Add support for -nomake-tests and -nomake-examples equivalents A developer can pass either -DQT_NO_MAKE_TESTS=ON or -DQT_NO_MAKE_EXAMPLES=ON to exclude tests or examples from being built as part the default make target (when you write just make or ninja). With ninja, tests and examples can be built separately one by one, by typing $ ninja tst_foo or $ ninja example_bar Same can be done with the Makefile generator. $ make tst_foo All tests / examples can be built in one go by typing $ ninja tests/all or $ ninja examples/all With the Makefile generator unfortunately it's not as nice and is most likely an implementation detail, but it can still be done by running something like $ make -f CMakeFiles/Makefile2 tests/all or $ make -f CMakeFiles/Makefile2 examples/all Change-Id: I34f168b3ab41e952a21d3ace5634e25a9f41922e Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-04 13:43:39 +00:00
set_property(DIRECTORY tests PROPERTY EXCLUDE_FROM_ALL TRUE)
endif()
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
endif()
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(NOT QT_BUILD_STANDALONE_TESTS)
Fix build without features.settings Change-Id: Id13980fd5124afe1ee2d378590eb7a4e11b7a4fb Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-04-15 00:46:40 +00:00
if(QT_WILL_BUILD_TOOLS AND QT_FEATURE_settings)
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
add_subdirectory(qmake)
endif()
# As long as we use the mkspecs (for qplatformdefs.h), we need to always
# install it, especially when cross-compiling.
Add INSTALL_MKSPECSDIR to the install locations Linux distributions may want to install mkspecs files into a different subdir in order to make Qt6 co-installable with older versions. Contributes to QTBUG-81289 Change-Id: Ie4a64370d742948d5ca4f2eaed6ea550d2676707 Reviewed-by: Qt CMake Build Bot Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-01-15 22:01:16 +00:00
set(mkspecs_install_dir "${INSTALL_MKSPECSDIR}")
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
qt_path_join(mkspecs_install_dir ${QT_INSTALL_DIR} ${mkspecs_install_dir})
Add INSTALL_MKSPECSDIR to the install locations Linux distributions may want to install mkspecs files into a different subdir in order to make Qt6 co-installable with older versions. Contributes to QTBUG-81289 Change-Id: Ie4a64370d742948d5ca4f2eaed6ea550d2676707 Reviewed-by: Qt CMake Build Bot Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-01-15 22:01:16 +00:00
file(GLOB mkspecs_subdirs
LIST_DIRECTORIES TRUE
"${PROJECT_SOURCE_DIR}/mkspecs/*")
CMake: Fix mkspec install commands If there is a file present in the globbed mkspecs_subdirs file list we run into an invalid argument error for the install(DIRECTORY) command. Change-Id: I0fe61a8f0a863854f55cf62a87417bcaec1d2c29 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-11 10:07:02 +00:00
foreach(entry IN LISTS mkspecs_subdirs)
if (IS_DIRECTORY ${entry})
qt_copy_or_install(DIRECTORY "${entry}"
CMake: Fix building examples targeting iOS simulator with qmake The makefile generated by qmake when building an iOS example tries to execute the mkspecs/features/uikit/devices.py python script to find a simulator ID. When installing the mkspecs, we didn't preserve the source file permissions which means that the executable bit was stripped. This causes the makefile to call xcodebuild with an invalid simulator id due to not being able to execute the python script. Make sure to install the mkspecs directories preserving the source file permissions. Fixes: QTBUG-87639 Change-Id: Iaa33b740c93187155025891104e8a21c6e7c98c8 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-15 14:39:44 +00:00
DESTINATION ${mkspecs_install_dir}
USE_SOURCE_PERMISSIONS)
CMake: Fix mkspec install commands If there is a file present in the globbed mkspecs_subdirs file list we run into an invalid argument error for the install(DIRECTORY) command. Change-Id: I0fe61a8f0a863854f55cf62a87417bcaec1d2c29 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-11 10:07:02 +00:00
else()
qt_copy_or_install(FILES "${entry}"
DESTINATION ${mkspecs_install_dir})
endif()
Add INSTALL_MKSPECSDIR to the install locations Linux distributions may want to install mkspecs files into a different subdir in order to make Qt6 co-installable with older versions. Contributes to QTBUG-81289 Change-Id: Ie4a64370d742948d5ca4f2eaed6ea550d2676707 Reviewed-by: Qt CMake Build Bot Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-01-15 22:01:16 +00:00
endforeach()
Skip the qmake build when cross-compiling Change-Id: I24da7eb9587235aa937a984e91a833284b4f28e5 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2019-02-15 12:16:35 +00:00
endif()
CMake: Add "BUILD_EXAMPLES" option to disable examples BUILD_EXAMPLES defaults to "ON". Change-Id: I5dfe926d8a23b610b45a5243deeb82483d998b90 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2019-01-17 09:22:59 +00:00
Fix linking of examples Provide add_qt_gui_executable() as function in our public API that takes care of automaticWinMain linkage. We can use this in the future to encapsulate similarplatform-specific behavior and adjustments, such as module generation onAndroid. In order for the examples to see the function in Qt5CoreMacros, three more additional fixes were required: * Do the build_repo_end() call _before_ attempting to build the examples, as we need the build_repo_end() to include QtPostProcess and complete the creation of all the target config files. Otherwise the find_package() calls in the examples see something incomplete. * Add more QT_NO_CREATE_TARGET guards * Always call find_dependency on the dependencies, regardless of the target creation mode. This way a find_package(Qt5 COMPONENTS Widgets) will still load Qt5CoreMacros. Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-11 13:46:31 +00:00
qt_build_repo_end()
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
if(NOT QT_BUILD_STANDALONE_TESTS AND QT_BUILD_EXAMPLES)
CMake: Add "BUILD_EXAMPLES" option to disable examples BUILD_EXAMPLES defaults to "ON". Change-Id: I5dfe926d8a23b610b45a5243deeb82483d998b90 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
2019-01-17 09:22:59 +00:00
add_subdirectory(examples)
endif()
Reference in New Issue Copy Permalink