AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
33f631920f
qt5base-lts/cmake/QtToolchainHelpers.cmake

269 lines
14 KiB
CMake
Raw Normal View History

CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
# Create a CMake toolchain file for convenient configuration of both internal Qt builds
# as well as CMake application projects.
# Expects various global variables to be set.
function(qt_internal_create_toolchain_file)
CMake: Clean up and improve QT_HOST_PATH_CMAKE_DIR computation Previously when one wanted to use a cross-compiled Qt with a host Qt installed in a non-default location, they'd have to provide both QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. This change will now try to first check if ${QT_HOST_PATH}/lib/cmake is a valid path on disk and use that. This is nicer to the user because they don't need to specify 2 paths anymore. Furthermore the path computation and sanity checks are now done after any extra toolchain cmake files are loaded, to give an opportunity to the files to set the paths first. Finally, both variables need to be added to __qt_toolchain_used_variables so they are passed along to try_compile calls if the variables are specified manually. Otherwise when the toolchain file is loaded by a try_compile project, it will error out saying no host path found (as long as the initial paths embedded in the toolchain are invalid). Amends 93fc3afe71467ca6aeffa41d7a6f4a170f82b62e and ec90f9013b4c6b63d7e03a964f66f97329be7885 Pick-to: 6.2 Change-Id: I433239b36b084f2d0a7a0dd043fdf87d77c138f3 Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-10-20 13:46:50 +00:00
set(qt_host_path_required FALSE)
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
CMake: Clean up and improve QT_HOST_PATH_CMAKE_DIR computation Previously when one wanted to use a cross-compiled Qt with a host Qt installed in a non-default location, they'd have to provide both QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. This change will now try to first check if ${QT_HOST_PATH}/lib/cmake is a valid path on disk and use that. This is nicer to the user because they don't need to specify 2 paths anymore. Furthermore the path computation and sanity checks are now done after any extra toolchain cmake files are loaded, to give an opportunity to the files to set the paths first. Finally, both variables need to be added to __qt_toolchain_used_variables so they are passed along to try_compile calls if the variables are specified manually. Otherwise when the toolchain file is loaded by a try_compile project, it will error out saying no host path found (as long as the initial paths embedded in the toolchain are invalid). Amends 93fc3afe71467ca6aeffa41d7a6f4a170f82b62e and ec90f9013b4c6b63d7e03a964f66f97329be7885 Pick-to: 6.2 Change-Id: I433239b36b084f2d0a7a0dd043fdf87d77c138f3 Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-10-20 13:46:50 +00:00
if(NOT "${QT_HOST_PATH}" STREQUAL "")
# If a QT_HOST_PATH is provided when configuring qtbase, we assume it's a cross build
# and thus we require the QT_HOST_PATH to be provided also when using the cross-built Qt.
# This tells the Qt toolchain file to do appropriate requirement checks.
set(qt_host_path_required TRUE)
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
CMake: Clean up and improve QT_HOST_PATH_CMAKE_DIR computation Previously when one wanted to use a cross-compiled Qt with a host Qt installed in a non-default location, they'd have to provide both QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. This change will now try to first check if ${QT_HOST_PATH}/lib/cmake is a valid path on disk and use that. This is nicer to the user because they don't need to specify 2 paths anymore. Furthermore the path computation and sanity checks are now done after any extra toolchain cmake files are loaded, to give an opportunity to the files to set the paths first. Finally, both variables need to be added to __qt_toolchain_used_variables so they are passed along to try_compile calls if the variables are specified manually. Otherwise when the toolchain file is loaded by a try_compile project, it will error out saying no host path found (as long as the initial paths embedded in the toolchain are invalid). Amends 93fc3afe71467ca6aeffa41d7a6f4a170f82b62e and ec90f9013b4c6b63d7e03a964f66f97329be7885 Pick-to: 6.2 Change-Id: I433239b36b084f2d0a7a0dd043fdf87d77c138f3 Reviewed-by: Craig Scott <craig.scott@qt.io>
2021-10-20 13:46:50 +00:00
# TODO: Figure out how to make the initial QT_HOST_PATH var relocatable in relation
# to the target CMAKE_INSTALL_DIR, if at all possible to do so in a reliable way.
get_filename_component(qt_host_path_absolute "${QT_HOST_PATH}" ABSOLUTE)
get_filename_component(qt_host_path_cmake_dir_absolute
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
"${Qt${PROJECT_VERSION_MAJOR}HostInfo_DIR}/.." ABSOLUTE)
endif()
if(CMAKE_TOOLCHAIN_FILE)
file(TO_CMAKE_PATH "${CMAKE_TOOLCHAIN_FILE}" __qt_chainload_toolchain_file)
set(init_original_toolchain_file
CMake: Get toolchain file path from EMSDK env for Wasm user projects Try to to chainload the emscripten CMake toolchain file from the EMSDK env var if it is set, instead of requiring the user to explicitly specify a path to the file via QT_CHAINLOAD_TOOLCHAIN_FILE. The order in which the toolchain file is chainloaded becomes is as follows: 1) The initial toolchain file path that was specified when configuring qtbase is set written as the initial value of __qt_chainload_toolchain_file in qt.toolchain.cmake 2) If EMSDK env var is set, it overrides the value from 1) 3) If QT_CHAINLOAD_TOOLCHAIN_FILE cache var is supplied it overrides the value from 2) Whichever value ends up in __qt_chainload_toolchain_file is checked too see if the file exists. If it exists it gets included, if it doesn't, a warning is issued. This checking logic is a bit crude and should be improved and unified with the Android chainload checking, but the current change already improves the behavior for users of Qt. Pick-to: 6.2 Task-number: QTBUG-96843 Change-Id: I5da58a329f659086aaaee765c9399d0369021b22 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-24 15:06:02 +00:00
"
set(__qt_initially_configured_toolchain_file \"${__qt_chainload_toolchain_file}\")
set(__qt_chainload_toolchain_file \"\${__qt_initially_configured_toolchain_file}\")
")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
endif()
if(VCPKG_CHAINLOAD_TOOLCHAIN_FILE)
CMake: output VCPKG_CHAINLOAD_TOOLCHAIN_FILE with cmake paths Change-Id: Ibde8890c30b9024aca589e892590d071b547c361 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-17 12:42:16 +00:00
file(TO_CMAKE_PATH "${VCPKG_CHAINLOAD_TOOLCHAIN_FILE}" VCPKG_CHAINLOAD_TOOLCHAIN_FILE)
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
list(APPEND init_vcpkg
"set(VCPKG_CHAINLOAD_TOOLCHAIN_FILE \"${VCPKG_CHAINLOAD_TOOLCHAIN_FILE}\")")
endif()
if(VCPKG_TARGET_TRIPLET)
list(APPEND init_vcpkg
"set(VCPKG_TARGET_TRIPLET \"${VCPKG_TARGET_TRIPLET}\" CACHE STRING \"\")")
endif()
Add instructions for Windows 10 on Arm config Task-number: QTQAINFRA-3966 Change-Id: Ib8ac80a5b8aa5c88d9e5d0eaad9ba550cc2442f8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Fathi Boudra
2021-01-12 09:19:30 +00:00
if(CMAKE_SYSTEM_NAME STREQUAL "Windows" AND CMAKE_SYSTEM_PROCESSOR STREQUAL "arm64" AND CMAKE_SYSTEM_VERSION STREQUAL "10")
list(APPEND init_platform "set(CMAKE_SYSTEM_NAME Windows CACHE STRING \"\")")
list(APPEND init_platform "set(CMAKE_SYSTEM_VERSION 10 CACHE STRING \"\")")
list(APPEND init_platform "set(CMAKE_SYSTEM_PROCESSOR arm64 CACHE STRING \"\")")
endif()
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
# By default we don't want to allow mixing compilers for building different repositories, so we
# embed the initially chosen compilers into the toolchain.
# This is because on Windows compilers aren't easily mixed.
# We want to avoid that qtbase is built using cl.exe for example, and then for another repo
# gcc is picked up from %PATH%.
# The same goes when using a custom compiler on other platforms, such as ICC.
#
# There are a few exceptions though.
#
# When crosscompiling using Boot2Qt, the environment setup shell script sets up the CXX env var,
# which is used by CMake to determine the initial compiler that should be used.
# Unfortunately, the CXX env var contains not only the compiler name, but also a few required
# arch-specific compiler flags. This means that when building qtsvg, if the Qt created toolchain
# file sets the CMAKE_CXX_COMPILER variable, the CXX env var is ignored and thus the extra
# arch specific compiler flags are not picked up anymore, leading to a configuration failure.
#
# To avoid this issue, disable automatic embedding of the compilers into the qt toolchain when
# cross compiling. This is merely a heuristic, becacuse we don't have enough data to decide
# when to do it or not.
# For example on Linux one might want to allow mixing of clang and gcc (maybe).
#
# To allow such use cases when the default is wrong, one can provide a flag to explicitly opt-in
# or opt-out of the compiler embedding into the Qt toolchain.
#
# Passing -DQT_EMBED_TOOLCHAIN_COMPILER=ON will force embedding of the compilers.
# Passing -DQT_EMBED_TOOLCHAIN_COMPILER=OFF will disable embedding of the compilers.
set(__qt_embed_toolchain_compilers TRUE)
if(CMAKE_CROSSCOMPILING)
set(__qt_embed_toolchain_compilers FALSE)
endif()
if(DEFINED QT_EMBED_TOOLCHAIN_COMPILER)
if(QT_EMBED_TOOLCHAIN_COMPILER)
set(__qt_embed_toolchain_compilers TRUE)
else()
set(__qt_embed_toolchain_compilers FALSE)
endif()
endif()
if(__qt_embed_toolchain_compilers)
list(APPEND init_platform "
set(__qt_initial_c_compiler \"${CMAKE_C_COMPILER}\")
set(__qt_initial_cxx_compiler \"${CMAKE_CXX_COMPILER}\")
if(NOT DEFINED CMAKE_C_COMPILER AND EXISTS \"\${__qt_initial_c_compiler}\")
set(CMAKE_C_COMPILER \"\${__qt_initial_c_compiler}\" CACHE STRING \"\")
endif()
if(NOT DEFINED CMAKE_CXX_COMPILER AND EXISTS \"\${__qt_initial_cxx_compiler}\")
set(CMAKE_CXX_COMPILER \"\${__qt_initial_cxx_compiler}\" CACHE STRING \"\")
endif()")
endif()
CMake: Fix usage of cache variables in qt.toolchain.cmake We have some cache variables that are used in our qt.toolchain.cmake toolchain file, for example QT_CHAINLOAD_TOOLCHAIN_FILE. When CMake runs a configure test with try_compile, our toolchain file is included again, but only a restricted set of variables is available. Add the variables that are used in our internal toolchain file to CMAKE_TRY_COMPILE_PLATFORM_VARIABLES. This makes them visible for try_compile calls operating on source files. Also pass the variables via the environment to support try_compile calls that operate on whole projects. Fixes: QTBUG-87873 Change-Id: Iebca9e23686bec5072194b15482e1782b9367a0e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-04 13:39:52 +00:00
unset(init_additional_used_variables)
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
if(APPLE)
CMake: Fix building iOS projects with a single-arch Qt build Automatically set the CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES values with the ones Qt was configured with, when configuring a user project with the Xcode generator and a single arch / sdk Qt build. This ensures that calling xcodebuild from the command line chooses the correct architecture and SDK when building the project. Allow to opt out of this behavior by passing QT_NO_SET_OSX_ARCHITECTURES and QT_NO_SET_OSX_SYSROOT. Amends 55a15a1c1b93d36d705fc69e44b5c806b807dd55 Amends a6a3b82ffb3d7f1ea13293206401ed360a51e9cd Pick-to: 6.2 Task-number: QTBUG-95838 Change-Id: Ifab16e9eee3100a9b80a2a14b3ea29ba8d9aa6fc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 07:47:45 +00:00
# For an iOS simulator_and_device build, we should not explicitly set the sysroot, but let
# CMake do it's universal build magic to use one sysroot / sdk per-arch.
# For a single arch / sysroot iOS build, try to use the initially configured sysroot
# path if it exists, otherwise just set the name of the sdk to be used.
# The latter "name" part is important for user projects so that running 'xcodebuild' from
# the command line chooses the correct sdk.
# Also allow to opt out just in case.
#
# TODO: Figure out if the same should apply to universal macOS builds.
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
list(LENGTH CMAKE_OSX_ARCHITECTURES _qt_osx_architectures_count)
if(CMAKE_OSX_SYSROOT AND NOT _qt_osx_architectures_count GREATER 1 AND UIKIT)
list(APPEND init_platform "
CMake: Fix building iOS projects with a single-arch Qt build Automatically set the CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES values with the ones Qt was configured with, when configuring a user project with the Xcode generator and a single arch / sdk Qt build. This ensures that calling xcodebuild from the command line chooses the correct architecture and SDK when building the project. Allow to opt out of this behavior by passing QT_NO_SET_OSX_ARCHITECTURES and QT_NO_SET_OSX_SYSROOT. Amends 55a15a1c1b93d36d705fc69e44b5c806b807dd55 Amends a6a3b82ffb3d7f1ea13293206401ed360a51e9cd Pick-to: 6.2 Task-number: QTBUG-95838 Change-Id: Ifab16e9eee3100a9b80a2a14b3ea29ba8d9aa6fc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 07:47:45 +00:00
set(__qt_uikit_sdk \"${QT_UIKIT_SDK}\")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
set(__qt_initial_cmake_osx_sysroot \"${CMAKE_OSX_SYSROOT}\")
if(NOT DEFINED CMAKE_OSX_SYSROOT AND EXISTS \"\${__qt_initial_cmake_osx_sysroot}\")
set(CMAKE_OSX_SYSROOT \"\${__qt_initial_cmake_osx_sysroot}\" CACHE PATH \"\")
CMake: Fix building iOS projects with a single-arch Qt build Automatically set the CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES values with the ones Qt was configured with, when configuring a user project with the Xcode generator and a single arch / sdk Qt build. This ensures that calling xcodebuild from the command line chooses the correct architecture and SDK when building the project. Allow to opt out of this behavior by passing QT_NO_SET_OSX_ARCHITECTURES and QT_NO_SET_OSX_SYSROOT. Amends 55a15a1c1b93d36d705fc69e44b5c806b807dd55 Amends a6a3b82ffb3d7f1ea13293206401ed360a51e9cd Pick-to: 6.2 Task-number: QTBUG-95838 Change-Id: Ifab16e9eee3100a9b80a2a14b3ea29ba8d9aa6fc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 07:47:45 +00:00
elseif(NOT DEFINED CMAKE_OSX_SYSROOT AND NOT QT_NO_SET_OSX_SYSROOT)
set(CMAKE_OSX_SYSROOT \"\${__qt_uikit_sdk}\" CACHE PATH \"\")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
endif()")
endif()
if(CMAKE_OSX_DEPLOYMENT_TARGET)
list(APPEND init_platform
"set(CMAKE_OSX_DEPLOYMENT_TARGET \"${CMAKE_OSX_DEPLOYMENT_TARGET}\" CACHE STRING \"\")")
endif()
CMake: Fix default architecture selection for macOS and iOS Before this change, we created a CMake toolchain file for iOS and macOS universal which propagated the initially configured CMAKE_OSX_ARCHITECTURES values to user projects. So if Qt was configured with 2 arches, configuring a CMake user project using the generated toolchain file would also build the user project targeting those 2 arches. The reason for this that the same toolchain file is used for configuring both Qt and users projects and we needed to ensure that other Qt repos are built with the same set of arches. That unfortunately led the multiple arches to carry over into user projects. This is different from qmake behavior which configured user projects with 1 arch only. Instead of the toolchain file explicitly setting CMAKE_OSX_ARCHITECTURES for all projects, save the initial list of arches into QT_OSX_ARCHITECTURES. Then if the toolchain file detects that we're building a Qt repo (by checking for the presence of QT_REPO_MODULE_VERSION) set CMAKE_OSX_ARCHITECTURES to QT_OSX_ARCHITECTURES to propagate the initial list of arches. For user projects we want to have some sensible defaults. For macOS projects, leave the decision of the architecture to build to CMake. For iOS Xcode projects, leave the decision to Xcode. For iOS Ninja projects, set the architecture to the first value of the architectures used when configuring Qt. As a side note this fixes an issue in our CI where we configured macOS Qt with 2 architectures and then tried to run CMake build tests for both architectures on a machine that doesn't have the universal SDK. This led to build failures. Because the CMake build tests act as regular user projects, now they are configured with a single architecture that is automtically detected by CMake. Pick-to: 6.1 Task-number: QTBUG-85447 Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-04-13 15:16:44 +00:00
# Save list of initial architectures Qt was configured with.
set(_qt_osx_architectures_escaped "${CMAKE_OSX_ARCHITECTURES}")
string(REPLACE ";" "LITERAL_SEMICOLON"
_qt_osx_architectures_escaped "${_qt_osx_architectures_escaped}")
set(docstring "List of architectures Qt was built with")
list(APPEND init_platform
"set(QT_OSX_ARCHITECTURES \"${_qt_osx_architectures_escaped}\" CACHE STRING \"${docstring}\")")
list(APPEND init_platform "")
# When building another qt repo, ensure the same list of architectures is used by default.
# Detection of a qt repo is done by checking for QT_REPO_MODULE_VERSION which is set in
# the repo's .cmake.conf file.
CMake: Don't build cmake build tests as macOS universal We want standalone tests added by qt_internal_add_test to be built as universal executables, so we can build them on an intel machine and run them on an ARM machine. But CMake build tests will be built on the final machine that runs the tests and it might lack a universal SDK. That's why they should be built only targeting the architecture of the machine they're running on. Change the generated qt.tooclhain.cmake file to allow opting in or out of building projects with the same architectures as Qt was configured with. Now standalone tests will be multi-arch, but CMake build tests will be single-arch. Amends e379147f9571af8c3af5768b9040e0180819a855 Task-number: QTBUG-85447 Task-number: QTBUG-87580 Task-number: QTBUG-92933 Change-Id: I41ab047983115f84eb2333cc9ac2d19ca08d621f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-07 14:25:27 +00:00
# Most standalone tests will also be built with multiple architectures.
# Certain tests will be built with a single arch only (like tests/auto/cmake) to avoid
# issues in the CI when trying to build them on VMs that do not have a universal macOS
CMake: Fix default architecture selection for macOS and iOS Before this change, we created a CMake toolchain file for iOS and macOS universal which propagated the initially configured CMAKE_OSX_ARCHITECTURES values to user projects. So if Qt was configured with 2 arches, configuring a CMake user project using the generated toolchain file would also build the user project targeting those 2 arches. The reason for this that the same toolchain file is used for configuring both Qt and users projects and we needed to ensure that other Qt repos are built with the same set of arches. That unfortunately led the multiple arches to carry over into user projects. This is different from qmake behavior which configured user projects with 1 arch only. Instead of the toolchain file explicitly setting CMAKE_OSX_ARCHITECTURES for all projects, save the initial list of arches into QT_OSX_ARCHITECTURES. Then if the toolchain file detects that we're building a Qt repo (by checking for the presence of QT_REPO_MODULE_VERSION) set CMAKE_OSX_ARCHITECTURES to QT_OSX_ARCHITECTURES to propagate the initial list of arches. For user projects we want to have some sensible defaults. For macOS projects, leave the decision of the architecture to build to CMake. For iOS Xcode projects, leave the decision to Xcode. For iOS Ninja projects, set the architecture to the first value of the architectures used when configuring Qt. As a side note this fixes an issue in our CI where we configured macOS Qt with 2 architectures and then tried to run CMake build tests for both architectures on a machine that doesn't have the universal SDK. This led to build failures. Because the CMake build tests act as regular user projects, now they are configured with a single architecture that is automtically detected by CMake. Pick-to: 6.1 Task-number: QTBUG-85447 Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-04-13 15:16:44 +00:00
# SDK.
CMake: Don't build cmake build tests as macOS universal We want standalone tests added by qt_internal_add_test to be built as universal executables, so we can build them on an intel machine and run them on an ARM machine. But CMake build tests will be built on the final machine that runs the tests and it might lack a universal SDK. That's why they should be built only targeting the architecture of the machine they're running on. Change the generated qt.tooclhain.cmake file to allow opting in or out of building projects with the same architectures as Qt was configured with. Now standalone tests will be multi-arch, but CMake build tests will be single-arch. Amends e379147f9571af8c3af5768b9040e0180819a855 Task-number: QTBUG-85447 Task-number: QTBUG-87580 Task-number: QTBUG-92933 Change-Id: I41ab047983115f84eb2333cc9ac2d19ca08d621f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-07 14:25:27 +00:00
list(APPEND init_platform
"# Only build multiple architectures when building Qt itself. Can be explicitly enabled or disabled.")
list(APPEND init_platform "if((QT_REPO_MODULE_VERSION AND NOT QT_FORCE_SINGLE_QT_OSX_ARCHITECTURE) OR QT_FORCE_ALL_QT_OSX_ARCHITECTURES)")
CMake: Fix default architecture selection for macOS and iOS Before this change, we created a CMake toolchain file for iOS and macOS universal which propagated the initially configured CMAKE_OSX_ARCHITECTURES values to user projects. So if Qt was configured with 2 arches, configuring a CMake user project using the generated toolchain file would also build the user project targeting those 2 arches. The reason for this that the same toolchain file is used for configuring both Qt and users projects and we needed to ensure that other Qt repos are built with the same set of arches. That unfortunately led the multiple arches to carry over into user projects. This is different from qmake behavior which configured user projects with 1 arch only. Instead of the toolchain file explicitly setting CMAKE_OSX_ARCHITECTURES for all projects, save the initial list of arches into QT_OSX_ARCHITECTURES. Then if the toolchain file detects that we're building a Qt repo (by checking for the presence of QT_REPO_MODULE_VERSION) set CMAKE_OSX_ARCHITECTURES to QT_OSX_ARCHITECTURES to propagate the initial list of arches. For user projects we want to have some sensible defaults. For macOS projects, leave the decision of the architecture to build to CMake. For iOS Xcode projects, leave the decision to Xcode. For iOS Ninja projects, set the architecture to the first value of the architectures used when configuring Qt. As a side note this fixes an issue in our CI where we configured macOS Qt with 2 architectures and then tried to run CMake build tests for both architectures on a machine that doesn't have the universal SDK. This led to build failures. Because the CMake build tests act as regular user projects, now they are configured with a single architecture that is automtically detected by CMake. Pick-to: 6.1 Task-number: QTBUG-85447 Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-04-13 15:16:44 +00:00
list(APPEND init_platform " set(__qt_toolchain_building_qt_repo TRUE)")
list(APPEND init_platform " set(CMAKE_OSX_ARCHITECTURES \"\${QT_OSX_ARCHITECTURES}\" CACHE STRING \"\")")
list(APPEND init_platform "endif()")
list(APPEND init_platform "")
# For macOS user projects, default to not specifying any architecture. This means CMake will
# not pass an -arch flag to the compiler and the compiler will choose the default
# architecture to build for.
# On Apple Silicon, CMake will introspect whether it's running under Rosetta and will
# pass the detected architecture (x86_64 under Rosetta or arm64 natively) to the compiler.
# This is line with default CMake behavior for user projects.
#
# For iOS, we provide a bit more convenience.
CMake: Fix building iOS projects with a single-arch Qt build Automatically set the CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES values with the ones Qt was configured with, when configuring a user project with the Xcode generator and a single arch / sdk Qt build. This ensures that calling xcodebuild from the command line chooses the correct architecture and SDK when building the project. Allow to opt out of this behavior by passing QT_NO_SET_OSX_ARCHITECTURES and QT_NO_SET_OSX_SYSROOT. Amends 55a15a1c1b93d36d705fc69e44b5c806b807dd55 Amends a6a3b82ffb3d7f1ea13293206401ed360a51e9cd Pick-to: 6.2 Task-number: QTBUG-95838 Change-Id: Ifab16e9eee3100a9b80a2a14b3ea29ba8d9aa6fc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 07:47:45 +00:00
# When the user project is built using the Xcode generator, we only specify the architecture
# if this is a single architecture Qt for iOS build. If we wouldn't, invoking just
# xcodebuild from the command line would try to build with the wrong architecture. Also
# provide an opt-out option just in case.
#
# For a multi-architecture build (so simulator_and_device) we don't set an explicit
CMake: Fix default architecture selection for macOS and iOS Before this change, we created a CMake toolchain file for iOS and macOS universal which propagated the initially configured CMAKE_OSX_ARCHITECTURES values to user projects. So if Qt was configured with 2 arches, configuring a CMake user project using the generated toolchain file would also build the user project targeting those 2 arches. The reason for this that the same toolchain file is used for configuring both Qt and users projects and we needed to ensure that other Qt repos are built with the same set of arches. That unfortunately led the multiple arches to carry over into user projects. This is different from qmake behavior which configured user projects with 1 arch only. Instead of the toolchain file explicitly setting CMAKE_OSX_ARCHITECTURES for all projects, save the initial list of arches into QT_OSX_ARCHITECTURES. Then if the toolchain file detects that we're building a Qt repo (by checking for the presence of QT_REPO_MODULE_VERSION) set CMAKE_OSX_ARCHITECTURES to QT_OSX_ARCHITECTURES to propagate the initial list of arches. For user projects we want to have some sensible defaults. For macOS projects, leave the decision of the architecture to build to CMake. For iOS Xcode projects, leave the decision to Xcode. For iOS Ninja projects, set the architecture to the first value of the architectures used when configuring Qt. As a side note this fixes an issue in our CI where we configured macOS Qt with 2 architectures and then tried to run CMake build tests for both architectures on a machine that doesn't have the universal SDK. This led to build failures. Because the CMake build tests act as regular user projects, now they are configured with a single architecture that is automtically detected by CMake. Pick-to: 6.1 Task-number: QTBUG-85447 Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-04-13 15:16:44 +00:00
# architecture and let Xcode and the developer handle it.
CMake: Fix building iOS projects with a single-arch Qt build Automatically set the CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES values with the ones Qt was configured with, when configuring a user project with the Xcode generator and a single arch / sdk Qt build. This ensures that calling xcodebuild from the command line chooses the correct architecture and SDK when building the project. Allow to opt out of this behavior by passing QT_NO_SET_OSX_ARCHITECTURES and QT_NO_SET_OSX_SYSROOT. Amends 55a15a1c1b93d36d705fc69e44b5c806b807dd55 Amends a6a3b82ffb3d7f1ea13293206401ed360a51e9cd Pick-to: 6.2 Task-number: QTBUG-95838 Change-Id: Ifab16e9eee3100a9b80a2a14b3ea29ba8d9aa6fc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 07:47:45 +00:00
#
CMake: Fix default architecture selection for macOS and iOS Before this change, we created a CMake toolchain file for iOS and macOS universal which propagated the initially configured CMAKE_OSX_ARCHITECTURES values to user projects. So if Qt was configured with 2 arches, configuring a CMake user project using the generated toolchain file would also build the user project targeting those 2 arches. The reason for this that the same toolchain file is used for configuring both Qt and users projects and we needed to ensure that other Qt repos are built with the same set of arches. That unfortunately led the multiple arches to carry over into user projects. This is different from qmake behavior which configured user projects with 1 arch only. Instead of the toolchain file explicitly setting CMAKE_OSX_ARCHITECTURES for all projects, save the initial list of arches into QT_OSX_ARCHITECTURES. Then if the toolchain file detects that we're building a Qt repo (by checking for the presence of QT_REPO_MODULE_VERSION) set CMAKE_OSX_ARCHITECTURES to QT_OSX_ARCHITECTURES to propagate the initial list of arches. For user projects we want to have some sensible defaults. For macOS projects, leave the decision of the architecture to build to CMake. For iOS Xcode projects, leave the decision to Xcode. For iOS Ninja projects, set the architecture to the first value of the architectures used when configuring Qt. As a side note this fixes an issue in our CI where we configured macOS Qt with 2 architectures and then tried to run CMake build tests for both architectures on a machine that doesn't have the universal SDK. This led to build failures. Because the CMake build tests act as regular user projects, now they are configured with a single architecture that is automtically detected by CMake. Pick-to: 6.1 Task-number: QTBUG-85447 Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-04-13 15:16:44 +00:00
# When using the Ninja generator, specify the first architecture from QT_OSX_ARCHITECTURES
# (even with a simulator_and_device Qt build). This ensures that the default configuration
# at least tries to build something.
if(UIKIT)
qt_internal_get_first_osx_arch(osx_first_arch)
CMake: Fix building iOS projects with a single-arch Qt build Automatically set the CMAKE_OSX_SYSROOT and CMAKE_OSX_ARCHITECTURES values with the ones Qt was configured with, when configuring a user project with the Xcode generator and a single arch / sdk Qt build. This ensures that calling xcodebuild from the command line chooses the correct architecture and SDK when building the project. Allow to opt out of this behavior by passing QT_NO_SET_OSX_ARCHITECTURES and QT_NO_SET_OSX_SYSROOT. Amends 55a15a1c1b93d36d705fc69e44b5c806b807dd55 Amends a6a3b82ffb3d7f1ea13293206401ed360a51e9cd Pick-to: 6.2 Task-number: QTBUG-95838 Change-Id: Ifab16e9eee3100a9b80a2a14b3ea29ba8d9aa6fc Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 07:47:45 +00:00
list(APPEND init_platform
"if((NOT CMAKE_GENERATOR STREQUAL \"Xcode\" AND NOT __qt_toolchain_building_qt_repo)
OR (CMAKE_GENERATOR STREQUAL \"Xcode\" AND __qt_uikit_sdk AND NOT QT_NO_SET_OSX_ARCHITECTURES))")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
list(APPEND init_platform
CMake: Fix default architecture selection for macOS and iOS Before this change, we created a CMake toolchain file for iOS and macOS universal which propagated the initially configured CMAKE_OSX_ARCHITECTURES values to user projects. So if Qt was configured with 2 arches, configuring a CMake user project using the generated toolchain file would also build the user project targeting those 2 arches. The reason for this that the same toolchain file is used for configuring both Qt and users projects and we needed to ensure that other Qt repos are built with the same set of arches. That unfortunately led the multiple arches to carry over into user projects. This is different from qmake behavior which configured user projects with 1 arch only. Instead of the toolchain file explicitly setting CMAKE_OSX_ARCHITECTURES for all projects, save the initial list of arches into QT_OSX_ARCHITECTURES. Then if the toolchain file detects that we're building a Qt repo (by checking for the presence of QT_REPO_MODULE_VERSION) set CMAKE_OSX_ARCHITECTURES to QT_OSX_ARCHITECTURES to propagate the initial list of arches. For user projects we want to have some sensible defaults. For macOS projects, leave the decision of the architecture to build to CMake. For iOS Xcode projects, leave the decision to Xcode. For iOS Ninja projects, set the architecture to the first value of the architectures used when configuring Qt. As a side note this fixes an issue in our CI where we configured macOS Qt with 2 architectures and then tried to run CMake build tests for both architectures on a machine that doesn't have the universal SDK. This led to build failures. Because the CMake build tests act as regular user projects, now they are configured with a single architecture that is automtically detected by CMake. Pick-to: 6.1 Task-number: QTBUG-85447 Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-04-13 15:16:44 +00:00
" set(CMAKE_OSX_ARCHITECTURES \"${osx_first_arch}\" CACHE STRING \"\")")
list(APPEND init_platform "endif()")
list(APPEND init_platform "")
CMake: Fix building multi-arch universal macOS Qt Use the same approach we use for iOS, which is to set multiple CMAKE_OSX_ARCHITECTURES values and let the clang front end deal with lipo-ing the final libraries. For now, Qt can be configured to build universal macOS libraries by passing 2 architectures to CMake, either via: -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" or -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" Currently we recommend specifying the intel x86_64 arch as the first one, to get an intel slice configuration that is comparable to a non-universal intel build. Specifying the arm64 slice first could pessimize optimizations and reduce the feature set for the intel slice due to the limitation that we run configure tests only once. The first specified architecture is the one used to do all the configure tests. It 'mostly' defines the common feature set of both architecture slices, with the excepion of some special handling for sse2 and neon instructions. In the future we might want to run at least the Qt architecture config test for all specified architectures, so that we can extract all the supported sub-arches and instruction sets in a reliable way. For now, we use the same sse2 hack as for iOS simulator_and_device builds, otherwise QtGui fails to link due to missing qt_memfill32_sse2 and other symbols. The hack is somewhat augmented to ensure that reconfiguration still succeeds (same issue happened with iOS). Previously the sse2 feature condition was broken due to force setting the feature to be ON. Now the condition also checks for a special QT_FORCE_FEATURE_sse2 variable which we set internally. Note that we shouldn't build for arm64e, because the binaries get killed when running on AS with the following message: kernel: exec_mach_imgact: not running binary built against preview arm64e ABI. Aslo, by default, we disable the arm64 slice for qt sql plugins, mostly because the CI provisioned sql libraries that we depend on only contain x86_64 slices, and trying to build the sql plugins for both slices will fail with linker errors. This behavior can be disabled for all targets marked by qt_internal_force_macos_intel_arch, by setting the QT_FORCE_MACOS_ALL_ARCHES CMake option to ON. To disble it per-target one can set QT_FORCE_MACOS_ALL_ARCHES_${target} to ON. Task-number: QTBUG-85447 Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-03-24 15:03:35 +00:00
endif()
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
CMake: Fix building multi-arch universal macOS Qt Use the same approach we use for iOS, which is to set multiple CMAKE_OSX_ARCHITECTURES values and let the clang front end deal with lipo-ing the final libraries. For now, Qt can be configured to build universal macOS libraries by passing 2 architectures to CMake, either via: -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" or -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" Currently we recommend specifying the intel x86_64 arch as the first one, to get an intel slice configuration that is comparable to a non-universal intel build. Specifying the arm64 slice first could pessimize optimizations and reduce the feature set for the intel slice due to the limitation that we run configure tests only once. The first specified architecture is the one used to do all the configure tests. It 'mostly' defines the common feature set of both architecture slices, with the excepion of some special handling for sse2 and neon instructions. In the future we might want to run at least the Qt architecture config test for all specified architectures, so that we can extract all the supported sub-arches and instruction sets in a reliable way. For now, we use the same sse2 hack as for iOS simulator_and_device builds, otherwise QtGui fails to link due to missing qt_memfill32_sse2 and other symbols. The hack is somewhat augmented to ensure that reconfiguration still succeeds (same issue happened with iOS). Previously the sse2 feature condition was broken due to force setting the feature to be ON. Now the condition also checks for a special QT_FORCE_FEATURE_sse2 variable which we set internally. Note that we shouldn't build for arm64e, because the binaries get killed when running on AS with the following message: kernel: exec_mach_imgact: not running binary built against preview arm64e ABI. Aslo, by default, we disable the arm64 slice for qt sql plugins, mostly because the CI provisioned sql libraries that we depend on only contain x86_64 slices, and trying to build the sql plugins for both slices will fail with linker errors. This behavior can be disabled for all targets marked by qt_internal_force_macos_intel_arch, by setting the QT_FORCE_MACOS_ALL_ARCHES CMake option to ON. To disble it per-target one can set QT_FORCE_MACOS_ALL_ARCHES_${target} to ON. Task-number: QTBUG-85447 Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-03-24 15:03:35 +00:00
if(UIKIT)
list(APPEND init_platform
"set(CMAKE_SYSTEM_NAME \"${CMAKE_SYSTEM_NAME}\" CACHE STRING \"\")")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
list(APPEND init_platform "if(CMAKE_GENERATOR STREQUAL \"Xcode\" AND NOT QT_NO_XCODE_EMIT_EPN)")
list(APPEND init_platform " set_property(GLOBAL PROPERTY XCODE_EMIT_EFFECTIVE_PLATFORM_NAME OFF)")
list(APPEND init_platform "endif()")
endif()
elseif(ANDROID)
Make possible to set android SDK/NDK roots from environment Read the ANDROID_<SDK|NDK>_ROOT environment variables in qt toolchain file and use them to chainload the android toolchain file. Pick-to: 6.2 6.3 Change-Id: I1940ffbaa557974fc26005f4d051030f2cc5c7e0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-01 14:17:55 +00:00
list(APPEND init_platform
"# Detect Android SDK/NDK from environment before loading the Android platform toolchain file."
"if(NOT DEFINED ANDROID_SDK_ROOT)"
" if(NOT \"\$ENV{ANDROID_SDK_ROOT}\" STREQUAL \"\")"
" set(ANDROID_SDK_ROOT \"\$ENV{ANDROID_SDK_ROOT}\" CACHE STRING \"Path to the Android SDK\")"
" endif()"
"endif()"
"if(NOT DEFINED ANDROID_NDK_ROOT)"
" if(NOT \"\$ENV{ANDROID_NDK_ROOT}\" STREQUAL \"\")"
" set(ANDROID_NDK_ROOT \"\$ENV{ANDROID_NDK_ROOT}\" CACHE STRING \"Path to the Android NDK\")"
" endif()"
"endif()"
)
CMake:Android: Use ANDROID_PLATFORM instead of ANDROID_NATIVE_API_LEVEL ANDROID_NATIVE_API_LEVEL is an alias for ANDROID_PLATFORM and the Android's CMake docs [1] uses directly ANDROID_PLATFORM so let's use that as well. Also, NDK r23b seems to have removed the part of code from android.toolchain.cmake that handles ANDROID_NATIVE_API_LEVEL to set the correct value to ANDROID_PLATFORM. With this change, CMake will pass the value from the configure argument -android-ndk-platform as -DANDROID_PLATFORM instead of -DANDROID_NATIVE_API_LEVEL. Otherwise, if if -DANDROID_NATIVE_API_LEVEL is passed directly to CMake, it should work as before. [1] https://developer.android.com/ndk/guides/cmake#build-command Pick-to: 6.3 Task-number: QTQAINFRA-4837 Change-Id: I5c21af53ac91e11a27c4b033313d22d1115c1abc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-08 13:08:00 +00:00
foreach(var ANDROID_PLATFORM ANDROID_NATIVE_API_LEVEL ANDROID_STL
ANDROID_ABI ANDROID_SDK_ROOT ANDROID_NDK_ROOT)
CMake: Fix usage of cache variables in qt.toolchain.cmake We have some cache variables that are used in our qt.toolchain.cmake toolchain file, for example QT_CHAINLOAD_TOOLCHAIN_FILE. When CMake runs a configure test with try_compile, our toolchain file is included again, but only a restricted set of variables is available. Add the variables that are used in our internal toolchain file to CMAKE_TRY_COMPILE_PLATFORM_VARIABLES. This makes them visible for try_compile calls operating on source files. Also pass the variables via the environment to support try_compile calls that operate on whole projects. Fixes: QTBUG-87873 Change-Id: Iebca9e23686bec5072194b15482e1782b9367a0e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-04 13:39:52 +00:00
list(APPEND init_additional_used_variables
"list(APPEND __qt_toolchain_used_variables ${var})")
endforeach()
CMake:Android: Use ANDROID_PLATFORM instead of ANDROID_NATIVE_API_LEVEL ANDROID_NATIVE_API_LEVEL is an alias for ANDROID_PLATFORM and the Android's CMake docs [1] uses directly ANDROID_PLATFORM so let's use that as well. Also, NDK r23b seems to have removed the part of code from android.toolchain.cmake that handles ANDROID_NATIVE_API_LEVEL to set the correct value to ANDROID_PLATFORM. With this change, CMake will pass the value from the configure argument -android-ndk-platform as -DANDROID_PLATFORM instead of -DANDROID_NATIVE_API_LEVEL. Otherwise, if if -DANDROID_NATIVE_API_LEVEL is passed directly to CMake, it should work as before. [1] https://developer.android.com/ndk/guides/cmake#build-command Pick-to: 6.3 Task-number: QTQAINFRA-4837 Change-Id: I5c21af53ac91e11a27c4b033313d22d1115c1abc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-08 13:08:00 +00:00
list(APPEND init_platform
"if(NOT DEFINED ANDROID_PLATFORM AND NOT DEFINED ANDROID_NATIVE_API_LEVEL)")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
list(APPEND init_platform
CMake:Android: Use ANDROID_PLATFORM instead of ANDROID_NATIVE_API_LEVEL ANDROID_NATIVE_API_LEVEL is an alias for ANDROID_PLATFORM and the Android's CMake docs [1] uses directly ANDROID_PLATFORM so let's use that as well. Also, NDK r23b seems to have removed the part of code from android.toolchain.cmake that handles ANDROID_NATIVE_API_LEVEL to set the correct value to ANDROID_PLATFORM. With this change, CMake will pass the value from the configure argument -android-ndk-platform as -DANDROID_PLATFORM instead of -DANDROID_NATIVE_API_LEVEL. Otherwise, if if -DANDROID_NATIVE_API_LEVEL is passed directly to CMake, it should work as before. [1] https://developer.android.com/ndk/guides/cmake#build-command Pick-to: 6.3 Task-number: QTQAINFRA-4837 Change-Id: I5c21af53ac91e11a27c4b033313d22d1115c1abc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-08 13:08:00 +00:00
" set(ANDROID_PLATFORM \"${ANDROID_PLATFORM}\" CACHE STRING \"\")")
list(APPEND init_platform "endif()")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
list(APPEND init_platform "set(ANDROID_STL \"${ANDROID_STL}\" CACHE STRING \"\")")
list(APPEND init_platform "set(ANDROID_ABI \"${ANDROID_ABI}\" CACHE STRING \"\")")
list(APPEND init_platform "if (NOT DEFINED ANDROID_SDK_ROOT)")
file(TO_CMAKE_PATH "${ANDROID_SDK_ROOT}" __qt_android_sdk_root)
list(APPEND init_platform
" set(ANDROID_SDK_ROOT \"${__qt_android_sdk_root}\" CACHE STRING \"\")")
list(APPEND init_platform "endif()")
CMake: allow using ANDORID_NDK_ROOT for user projects Allow CMake for Android to use ANDROID_NDK_ROOT to deduce the path for QT_CHAINLOAD_TOOLCHAIN_FILE instead of the user providing it manually. Change-Id: Ida728011d5ca8d5a723d341ea77b173e8f105f8c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-26 19:50:36 +00:00
list(APPEND init_platform "if(NOT \"$\{ANDROID_NDK_ROOT\}\" STREQUAL \"\")")
list(APPEND init_platform
" set(__qt_toolchain_file_candidate \"$\{ANDROID_NDK_ROOT\}/build/cmake/android.toolchain.cmake\")")
list(APPEND init_platform " if(EXISTS \"$\{__qt_toolchain_file_candidate\}\")")
list(APPEND init_platform
" message(STATUS \"Android toolchain file within NDK detected: $\{__qt_toolchain_file_candidate\}\")")
list(APPEND init_platform " set(__qt_chainload_toolchain_file \"$\{__qt_toolchain_file_candidate\}\")")
list(APPEND init_platform " else()")
list(APPEND init_platform
" message(FATAL_ERROR \"Cannot find the toolchain file '$\{__qt_toolchain_file_candidate\}'. \"")
list(APPEND init_platform
" \"Please specify the toolchain file with -DQT_CHAINLOAD_TOOLCHAIN_FILE=<file>.\")")
list(APPEND init_platform " endif()")
list(APPEND init_platform "endif()")
CMake: Get toolchain file path from EMSDK env for Wasm user projects Try to to chainload the emscripten CMake toolchain file from the EMSDK env var if it is set, instead of requiring the user to explicitly specify a path to the file via QT_CHAINLOAD_TOOLCHAIN_FILE. The order in which the toolchain file is chainloaded becomes is as follows: 1) The initial toolchain file path that was specified when configuring qtbase is set written as the initial value of __qt_chainload_toolchain_file in qt.toolchain.cmake 2) If EMSDK env var is set, it overrides the value from 1) 3) If QT_CHAINLOAD_TOOLCHAIN_FILE cache var is supplied it overrides the value from 2) Whichever value ends up in __qt_chainload_toolchain_file is checked too see if the file exists. If it exists it gets included, if it doesn't, a warning is issued. This checking logic is a bit crude and should be improved and unified with the Android chainload checking, but the current change already improves the behavior for users of Qt. Pick-to: 6.2 Task-number: QTBUG-96843 Change-Id: I5da58a329f659086aaaee765c9399d0369021b22 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-24 15:06:02 +00:00
elseif(EMSCRIPTEN)
list(APPEND init_platform
"include(\${CMAKE_CURRENT_LIST_DIR}/QtPublicWasmToolchainHelpers.cmake)
if(DEFINED ENV{EMSDK} AND NOT \"\$ENV{EMSDK}\" STREQUAL \"\")
__qt_internal_get_emroot_path_suffix_from_emsdk_env(__qt_toolchain_emroot_path)
__qt_internal_get_emscripten_cmake_toolchain_file_path_from_emsdk_env(
\"\${__qt_toolchain_emroot_path}\" _qt_candidate_emscripten_toolchain_path)
set(__qt_chainload_toolchain_file \"\${_qt_candidate_emscripten_toolchain_path}\")
endif()
CMake: Show error in user projects if wasm toolchain file not found Rather than fail with obscure can't find Qt packages errors when the Webassembly CMake toolchain file can not be found, error out with a clear error on how to ensure it is found. Pick-to: 6.2 Task-number: QTBUG-96843 Change-Id: I0f34cdcde05efb25c93017f3fd365186335ed52c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-27 10:27:23 +00:00
")
list(APPEND init_post_chainload_toolchain "
if(NOT __qt_chainload_toolchain_file_included)
__qt_internal_show_error_no_emscripten_toolchain_file_found_when_using_qt()
endif()
CMake: Get toolchain file path from EMSDK env for Wasm user projects Try to to chainload the emscripten CMake toolchain file from the EMSDK env var if it is set, instead of requiring the user to explicitly specify a path to the file via QT_CHAINLOAD_TOOLCHAIN_FILE. The order in which the toolchain file is chainloaded becomes is as follows: 1) The initial toolchain file path that was specified when configuring qtbase is set written as the initial value of __qt_chainload_toolchain_file in qt.toolchain.cmake 2) If EMSDK env var is set, it overrides the value from 1) 3) If QT_CHAINLOAD_TOOLCHAIN_FILE cache var is supplied it overrides the value from 2) Whichever value ends up in __qt_chainload_toolchain_file is checked too see if the file exists. If it exists it gets included, if it doesn't, a warning is issued. This checking logic is a bit crude and should be improved and unified with the Android chainload checking, but the current change already improves the behavior for users of Qt. Pick-to: 6.2 Task-number: QTBUG-96843 Change-Id: I5da58a329f659086aaaee765c9399d0369021b22 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-24 15:06:02 +00:00
")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
endif()
CMake: Fix usage of cache variables in qt.toolchain.cmake We have some cache variables that are used in our qt.toolchain.cmake toolchain file, for example QT_CHAINLOAD_TOOLCHAIN_FILE. When CMake runs a configure test with try_compile, our toolchain file is included again, but only a restricted set of variables is available. Add the variables that are used in our internal toolchain file to CMAKE_TRY_COMPILE_PLATFORM_VARIABLES. This makes them visible for try_compile calls operating on source files. Also pass the variables via the environment to support try_compile calls that operate on whole projects. Fixes: QTBUG-87873 Change-Id: Iebca9e23686bec5072194b15482e1782b9367a0e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-04 13:39:52 +00:00
string(REPLACE ";" "\n" init_additional_used_variables
"${init_additional_used_variables}")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
string(REPLACE ";" "\n" init_vcpkg "${init_vcpkg}")
CMake: Show error in user projects if wasm toolchain file not found Rather than fail with obscure can't find Qt packages errors when the Webassembly CMake toolchain file can not be found, error out with a clear error on how to ensure it is found. Pick-to: 6.2 Task-number: QTBUG-96843 Change-Id: I0f34cdcde05efb25c93017f3fd365186335ed52c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-27 10:27:23 +00:00
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
string(REPLACE ";" "\n" init_platform "${init_platform}")
string(REPLACE "LITERAL_SEMICOLON" ";" init_platform "${init_platform}")
CMake: Show error in user projects if wasm toolchain file not found Rather than fail with obscure can't find Qt packages errors when the Webassembly CMake toolchain file can not be found, error out with a clear error on how to ensure it is found. Pick-to: 6.2 Task-number: QTBUG-96843 Change-Id: I0f34cdcde05efb25c93017f3fd365186335ed52c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-27 10:27:23 +00:00
string(REPLACE ";" "\n" init_post_chainload_toolchain "${init_post_chainload_toolchain}")
string(REPLACE "LITERAL_SEMICOLON" ";" init_post_chainload_toolchain
"${init_post_chainload_toolchain}")
CMake: Split QtBaseGlobalTargets.cmake into multiple files And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-12 08:55:18 +00:00
qt_compute_relative_path_from_cmake_config_dir_to_prefix()
configure_file(
"${CMAKE_CURRENT_SOURCE_DIR}/cmake/qt.toolchain.cmake.in"
"${__GlobalConfig_build_dir}/qt.toolchain.cmake" @ONLY)
qt_install(FILES "${__GlobalConfig_build_dir}/qt.toolchain.cmake"
DESTINATION "${__GlobalConfig_install_dir}" COMPONENT Devel)
endfunction()
Reference in New Issue Copy Permalink