AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
fe182c1541
qt5base-lts/cmake/QtBuildInternals/QtBuildInternalsConfig.cmake

1584 lines
67 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
# These values should be kept in sync with those in qtbase/.cmake.conf
Sync CMake Version with `.cmake.conf` As stated in `QtBuildInternalsConfig.cmake`, `cmake_minimum_required` versions should be synced with `qtbase/.cmake.conf`, but it wasn't at the moment. Change-Id: I8100370778707d46abe973b681fd4aba182a7513 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-24 09:13:46 +00:00
cmake_minimum_required(VERSION 3.16...3.21)
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
Fix error when re-configuring an already installed Qt repository When building and installing a Qt repo that provides plugins for a Qt module within a different repository (for example, qtimageformats providing imageformat plugins for QtGui), re-configuring that repository would result in configuration errors like "add_library cannot create ALIAS target "Qt6::QTgaPlugin" because another target with the same name already exists." This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled in the Qt6*PluginConfig.cmake files that create imported targets for the plugins we want to build. To fix this, when building Qt, we now load only plugins that are provided by repositories the currently building repository depends on. We read the repo dependencies from dependencies.yaml when the Qt6BuildInternals package is loaded, but only in static builds and only if we're currently building a Qt repository. To find out whether we're building a Qt repository, we check whether QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT, because that variable is not available for the first find_package calls in the repository's top-level project file. In each Qt6*PluginConfig.cmake file, we bail out if the plugin's repository is not one of the ones in QT_REPO_DEPENDENCIES. Fixes: QTBUG-86670 Fixes: QTBUG-91887 Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-22 19:43:25 +00:00
###############################################
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
#
Fix error when re-configuring an already installed Qt repository When building and installing a Qt repo that provides plugins for a Qt module within a different repository (for example, qtimageformats providing imageformat plugins for QtGui), re-configuring that repository would result in configuration errors like "add_library cannot create ALIAS target "Qt6::QTgaPlugin" because another target with the same name already exists." This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled in the Qt6*PluginConfig.cmake files that create imported targets for the plugins we want to build. To fix this, when building Qt, we now load only plugins that are provided by repositories the currently building repository depends on. We read the repo dependencies from dependencies.yaml when the Qt6BuildInternals package is loaded, but only in static builds and only if we're currently building a Qt repository. To find out whether we're building a Qt repository, we check whether QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT, because that variable is not available for the first find_package calls in the repository's top-level project file. In each Qt6*PluginConfig.cmake file, we bail out if the plugin's repository is not one of the ones in QT_REPO_DEPENDENCIES. Fixes: QTBUG-86670 Fixes: QTBUG-91887 Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-22 19:43:25 +00:00
# Macros and functions for building Qt modules
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
#
Fix error when re-configuring an already installed Qt repository When building and installing a Qt repo that provides plugins for a Qt module within a different repository (for example, qtimageformats providing imageformat plugins for QtGui), re-configuring that repository would result in configuration errors like "add_library cannot create ALIAS target "Qt6::QTgaPlugin" because another target with the same name already exists." This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled in the Qt6*PluginConfig.cmake files that create imported targets for the plugins we want to build. To fix this, when building Qt, we now load only plugins that are provided by repositories the currently building repository depends on. We read the repo dependencies from dependencies.yaml when the Qt6BuildInternals package is loaded, but only in static builds and only if we're currently building a Qt repository. To find out whether we're building a Qt repository, we check whether QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT, because that variable is not available for the first find_package calls in the repository's top-level project file. In each Qt6*PluginConfig.cmake file, we bail out if the plugin's repository is not one of the ones in QT_REPO_DEPENDENCIES. Fixes: QTBUG-86670 Fixes: QTBUG-91887 Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-22 19:43:25 +00:00
###############################################
# Recursively reads the dependencies section from dependencies.yaml in ${repo_dir} and returns the
# list of dependencies, including transitive ones, in out_var.
#
# The returned dependencies are topologically sorted.
#
Fix a mistake in the documentation of qt_internal_read_repo_dependencies If I understood the function correctly, then the example was not quite right. Change-Id: I6b6a4845c5ded2a058050dfbecf5db158d32d12a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-11-22 10:06:20 +00:00
# Example output for qtdeclarative:
# qtbase;qtimageformats;qtlanguageserver;qtshadertools;qtsvg
Fix error when re-configuring an already installed Qt repository When building and installing a Qt repo that provides plugins for a Qt module within a different repository (for example, qtimageformats providing imageformat plugins for QtGui), re-configuring that repository would result in configuration errors like "add_library cannot create ALIAS target "Qt6::QTgaPlugin" because another target with the same name already exists." This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled in the Qt6*PluginConfig.cmake files that create imported targets for the plugins we want to build. To fix this, when building Qt, we now load only plugins that are provided by repositories the currently building repository depends on. We read the repo dependencies from dependencies.yaml when the Qt6BuildInternals package is loaded, but only in static builds and only if we're currently building a Qt repository. To find out whether we're building a Qt repository, we check whether QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT, because that variable is not available for the first find_package calls in the repository's top-level project file. In each Qt6*PluginConfig.cmake file, we bail out if the plugin's repository is not one of the ones in QT_REPO_DEPENDENCIES. Fixes: QTBUG-86670 Fixes: QTBUG-91887 Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-22 19:43:25 +00:00
#
function(qt_internal_read_repo_dependencies out_var repo_dir)
set(seen ${ARGN})
set(dependencies "")
set(in_dependencies_section FALSE)
set(dependencies_file "${repo_dir}/dependencies.yaml")
if(EXISTS "${dependencies_file}")
file(STRINGS "${dependencies_file}" lines)
foreach(line IN LISTS lines)
if(line MATCHES "^([^ ]+):")
if(CMAKE_MATCH_1 STREQUAL "dependencies")
set(in_dependencies_section TRUE)
else()
set(in_dependencies_section FALSE)
endif()
elseif(in_dependencies_section AND line MATCHES "^ (.+):$")
set(dependency "${CMAKE_MATCH_1}")
set(dependency_repo_dir "${repo_dir}/${dependency}")
string(REGEX MATCH "[^/]+$" dependency "${dependency}")
if(NOT dependency IN_LIST seen)
qt_internal_read_repo_dependencies(subdeps "${dependency_repo_dir}"
${seen} ${dependency})
list(APPEND dependencies ${subdeps} ${dependency})
endif()
endif()
endforeach()
list(REMOVE_DUPLICATES dependencies)
endif()
set(${out_var} "${dependencies}" PARENT_SCOPE)
endfunction()
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
CMake: Make sure not to use the Qt prefix for standalone tests We don't want people accidentally installing tests into the Qt prefix. Change-Id: Ic99492559875f753897a83af162253cac846a8a5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-16 18:30:03 +00:00
set(QT_BACKUP_CMAKE_INSTALL_PREFIX_BEFORE_EXTRA_INCLUDE "${CMAKE_INSTALL_PREFIX}")
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
if(EXISTS "${CMAKE_CURRENT_LIST_DIR}/QtBuildInternalsExtra.cmake")
include(${CMAKE_CURRENT_LIST_DIR}/QtBuildInternalsExtra.cmake)
endif()
Fix invalid Qt prefix version when looking for HostInfo module In QtSetup.cmake the PROJECT_VERSION_MAJOR variable was used to identify prefix of 'Qt<version>HostInfoConfig.cmake'. Qt<version>HostInfo is not found, if project version differs from qtbase version. Move the 'INSTALL_CMAKE_NAMESPACE' and 'QT_CMAKE_EXPORT_NAMESPACE' variables to 'QtBuildInternalsConfig.cmake'. In this case variables will be exposed for a wider list of internal routines. Use the 'INSTALL_CMAKE_NAMESPACE' variable as prefix to find Qt<version>HostInfo module. Fixes: QTBUG-90345 Change-Id: Ic595d1c5beb74f34e69b58e18590a3afc2f346f7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-01-25 18:29:52 +00:00
# The variables might have already been set in QtBuildInternalsExtra.cmake if the file is included
# while building a new module and not QtBase. In that case, stop overriding the value.
if(NOT INSTALL_CMAKE_NAMESPACE)
set(INSTALL_CMAKE_NAMESPACE "Qt${PROJECT_VERSION_MAJOR}"
CACHE STRING "CMake namespace [Qt${PROJECT_VERSION_MAJOR}]")
endif()
if(NOT QT_CMAKE_EXPORT_NAMESPACE)
set(QT_CMAKE_EXPORT_NAMESPACE "Qt${PROJECT_VERSION_MAJOR}"
CACHE STRING "CMake namespace used when exporting targets [Qt${PROJECT_VERSION_MAJOR}]")
endif()
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
macro(qt_set_up_build_internals_paths)
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
# Set up the paths for the cmake modules located in the prefix dir. Prepend, so the paths are
Use $$source_path/qtbase/cmake modules when doing non-prefix builds This is similar to qmake, where the .prf files from the source location of qtbase/mkspecs are used in a non-prefix build. This means that if a developer changes the source QtBuild.cmake, and then runs make in qtdeclarative, cmake will reconfigure qtdeclarative because the timestamp of QtBuild.cmake changed. Before this change you first had to make && make install in the qtbase build directory, before qtdeclarative saw the modified QtBuild.cmake. This change also makes the module paths be prepended to CMAKE_MODULE_PATH instead of appended, which means they will take precedence to any path provided via command line. Change-Id: I9178d5183a95b3b67bfe1b1fe91d3d3371ffe5c5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-05 16:17:00 +00:00
# least important compared to the source dir ones, but more important than command line
# provided ones.
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
set(QT_CMAKE_MODULE_PATH "${QT_BUILD_INTERNALS_PATH}/../${QT_CMAKE_EXPORT_NAMESPACE}")
Use $$source_path/qtbase/cmake modules when doing non-prefix builds This is similar to qmake, where the .prf files from the source location of qtbase/mkspecs are used in a non-prefix build. This means that if a developer changes the source QtBuild.cmake, and then runs make in qtdeclarative, cmake will reconfigure qtdeclarative because the timestamp of QtBuild.cmake changed. Before this change you first had to make && make install in the qtbase build directory, before qtdeclarative saw the modified QtBuild.cmake. This change also makes the module paths be prepended to CMAKE_MODULE_PATH instead of appended, which means they will take precedence to any path provided via command line. Change-Id: I9178d5183a95b3b67bfe1b1fe91d3d3371ffe5c5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-05 16:17:00 +00:00
list(PREPEND CMAKE_MODULE_PATH "${QT_CMAKE_MODULE_PATH}")
Implement qtbase fixes for superbuilds Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-11-21 12:33:28 +00:00
# Prepend the qtbase source cmake directory to CMAKE_MODULE_PATH,
Use $$source_path/qtbase/cmake modules when doing non-prefix builds This is similar to qmake, where the .prf files from the source location of qtbase/mkspecs are used in a non-prefix build. This means that if a developer changes the source QtBuild.cmake, and then runs make in qtdeclarative, cmake will reconfigure qtdeclarative because the timestamp of QtBuild.cmake changed. Before this change you first had to make && make install in the qtbase build directory, before qtdeclarative saw the modified QtBuild.cmake. This change also makes the module paths be prepended to CMAKE_MODULE_PATH instead of appended, which means they will take precedence to any path provided via command line. Change-Id: I9178d5183a95b3b67bfe1b1fe91d3d3371ffe5c5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-05 16:17:00 +00:00
# so that if a change is done in cmake/QtBuild.cmake, it gets automatically picked up when
# building qtdeclarative, rather than having to build qtbase first (which will copy
# QtBuild.cmake to the build dir). This is similar to qmake non-prefix builds, where the
# source qtbase/mkspecs directory is used.
CMake: Fix picking of the binary_for_strip project location Fix binary_for_strip project not being found when the following conditions were met: - building a repo other than qtbase - qtbase sources are not available on the machine (usually happens in CI where only the current repo sources are available). The issue was that QT_CMAKE_DIR would always be defined, regardless of which repo was being built and the system would incorrectly assume the location of the project files. The fix is to always pick up the sources from qtbase's source dir if they are available (this time done with an appropriate check), otherwise use the installed files. Note that the behavior of always using the qtbase sources if available is not exactly the best, but it is a more general issue that affects other code too. In the name of consistency, make it so for the binary_for_strip project as well, but add TODOs in code to address the situation in a separate change. Amends 39f657032b5e65bfcb93472201f6607c0388ba37 Pick-to: 6.2 6.3 Fixes: QTBUG-102064 Task-number: QTBUG-88090 Task-number: QTBUG-101653 Change-Id: I0649f945e9ff0ab1f597c51bb5ab389fa665c021 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-28 14:59:20 +00:00
# TODO: Clean this up, together with qt_internal_try_compile_binary_for_strip to only use the
# the qtbase sources when building qtbase. And perhaps also when doing a non-prefix
# developer-build.
Implement qtbase fixes for superbuilds Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-11-21 12:33:28 +00:00
if(EXISTS "${QT_SOURCE_TREE}/cmake")
Use $$source_path/qtbase/cmake modules when doing non-prefix builds This is similar to qmake, where the .prf files from the source location of qtbase/mkspecs are used in a non-prefix build. This means that if a developer changes the source QtBuild.cmake, and then runs make in qtdeclarative, cmake will reconfigure qtdeclarative because the timestamp of QtBuild.cmake changed. Before this change you first had to make && make install in the qtbase build directory, before qtdeclarative saw the modified QtBuild.cmake. This change also makes the module paths be prepended to CMAKE_MODULE_PATH instead of appended, which means they will take precedence to any path provided via command line. Change-Id: I9178d5183a95b3b67bfe1b1fe91d3d3371ffe5c5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-05 16:17:00 +00:00
list(PREPEND CMAKE_MODULE_PATH "${QT_SOURCE_TREE}/cmake")
endif()
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
# If the repo has its own cmake modules, include those in the module path.
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
Use $$source_path/qtbase/cmake modules when doing non-prefix builds This is similar to qmake, where the .prf files from the source location of qtbase/mkspecs are used in a non-prefix build. This means that if a developer changes the source QtBuild.cmake, and then runs make in qtdeclarative, cmake will reconfigure qtdeclarative because the timestamp of QtBuild.cmake changed. Before this change you first had to make && make install in the qtbase build directory, before qtdeclarative saw the modified QtBuild.cmake. This change also makes the module paths be prepended to CMAKE_MODULE_PATH instead of appended, which means they will take precedence to any path provided via command line. Change-Id: I9178d5183a95b3b67bfe1b1fe91d3d3371ffe5c5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-05 16:17:00 +00:00
list(PREPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
endif()
cmake: Include repo-specific setup files This is useful for providing private CMake API which is not part of QtBase. Also, fix the setup files to be included when building standalone tests. The old ${PROJECT_NAME}Setup.cmake file inclusion will be removed once all usages are adjusted. Prompted-by: Alexandru Croitor <alexandru.croitor@qt.io> Change-Id: I5bc2bca7371660c00b0301e94d025a29b68d6975 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-09-20 13:20:57 +00:00
# Find the cmake files when doing a standalone tests build.
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/../cmake")
list(PREPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../cmake")
endif()
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
endmacro()
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
# Set up the build internal paths unless explicitly requested not to.
if(NOT QT_BUILD_INTERNALS_SKIP_CMAKE_MODULE_PATH_ADDITION)
qt_set_up_build_internals_paths()
endif()
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
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
# Define some constants to check for certain platforms, etc.
# Needs to be loaded before qt_repo_build() to handle require() clauses before even starting a repo
# build.
include(QtPlatformSupport)
CMake: Handle INPUT_foo values when detecting dirty builds Before this change, the dirty feature code only checked for differences between FEATURE_foo and QT_FEATURE_foo, without taking into account modified INPUT_foo values that might passed via the configure script. This led to issues in certain scenarios when reconfiguring with the configure script. For example configuring with -gui / -DINPUT_gui=ON and then with -no-gui / -DINPUT_gui=OFF would fail saying 'Feature "widgets": Forcing to "ON" breaks its condition' This happens because the widgets feature depends on gui being available, but because INPUT_gui modifications don't trigger the dirty feature re-eval code, we don't recompute the value of widgets. Extract the code that takes into account the INPUT_foo variables into a separate function, and use it both when computing feature values and also when detecting dirty features. This means any non-matching INPUT_foo variables will now also trigger dirty feature checking. Use the same function to replace the duplicate code we have to early initialize the developer-build, no-prefix and pkg-config features. Pick-to: 6.6 Task-number: QTBUG-112957 Change-Id: I775cf70b48291a659b0fecf7cb9570ec12735bca Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-25 16:20:01 +00:00
# Set FEATURE_${feature} if INPUT_${feature} is set in certain circumstances.
CMake: Fix reconfiguration when -no-opengl is specified In a previous change, we ensured that all INPUT_foo cache variables are unset at the end of configuration, so they don't influence feature re-evaluation in case if a command line flag like -no-gui is not specified upon second reconfiguration and a FEATURE_foo is manually toggled in the CMakeCache.txt, effectively getting rid of stale INPUT_foo values. Unfortunately that causes an issue when configuring with -no-opengl and then trying to reconfigure with 'cmake .' Specifically various feature options like ENABLE / DISABLE use INPUT_foo variables in their expressions. qt_configure_add_report_entry CONDITIONs also use them. These expect the INPUT_foo variables to be persisted, and if they are removed, the expressions might be re-evaluated to a different value, and cause re-configuration to fail or unexpectedly toggle features. To support both cases described above, instead of removing all INPUT variables when configuration ends, only unset those INPUT variables whose corresponding FEATURE_foo variable has been manually toggled in CMakeCache.txt or via an IDE. Toggling a FEATURE_foo manually is intentional, which means the INPUT_foo value should be discarded. Whereas pre-existing INPUT_bar variables will persist, thus not breaking cases like the -no-opengl report CONDITION. Amends 2799391703e44a34b6557e234462e425a61785f2 Pick-to: 6.6 Fixes: QTBUG-116973 Task-number: QTBUG-112957 Change-Id: I5851255bfa41a9a1d116630a5d9f7b9a74aa93ed Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-09-12 14:57:56 +00:00
# Set FEATURE_${feature}_computed_from_input to TRUE or FALSE depending on whether the
# INPUT_${feature} value has overridden the FEATURE_${feature} variable.
CMake: Handle INPUT_foo values when detecting dirty builds Before this change, the dirty feature code only checked for differences between FEATURE_foo and QT_FEATURE_foo, without taking into account modified INPUT_foo values that might passed via the configure script. This led to issues in certain scenarios when reconfiguring with the configure script. For example configuring with -gui / -DINPUT_gui=ON and then with -no-gui / -DINPUT_gui=OFF would fail saying 'Feature "widgets": Forcing to "ON" breaks its condition' This happens because the widgets feature depends on gui being available, but because INPUT_gui modifications don't trigger the dirty feature re-eval code, we don't recompute the value of widgets. Extract the code that takes into account the INPUT_foo variables into a separate function, and use it both when computing feature values and also when detecting dirty features. This means any non-matching INPUT_foo variables will now also trigger dirty feature checking. Use the same function to replace the duplicate code we have to early initialize the developer-build, no-prefix and pkg-config features. Pick-to: 6.6 Task-number: QTBUG-112957 Change-Id: I775cf70b48291a659b0fecf7cb9570ec12735bca Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-25 16:20:01 +00:00
#
# Needs to be in QtBuildInternalsConfig.cmake instead of QtFeature.cmake because it's used in
# qt_build_internals_disable_pkg_config_if_needed.
function(qt_internal_compute_feature_value_from_possible_input feature)
# If FEATURE_ is not defined try to use the INPUT_ variable to enable/disable feature.
# If FEATURE_ is defined and the configure script is being used (so
# QT_INTERNAL_CALLED_FROM_CONFIGURE is TRUE), ignore the FEATURE_ variable, and take into
# account the INPUT_ variable instead, because a command line argument takes priority over
# a pre-cached FEATURE_ variable.
if((NOT DEFINED FEATURE_${feature} OR QT_INTERNAL_CALLED_FROM_CONFIGURE)
AND DEFINED INPUT_${feature}
AND NOT "${INPUT_${feature}}" STREQUAL "undefined"
AND NOT "${INPUT_${feature}}" STREQUAL "")
if(INPUT_${feature})
set(FEATURE_${feature} ON)
else()
set(FEATURE_${feature} OFF)
endif()
set(FEATURE_${feature} "${FEATURE_${feature}}" PARENT_SCOPE)
CMake: Fix reconfiguration when -no-opengl is specified In a previous change, we ensured that all INPUT_foo cache variables are unset at the end of configuration, so they don't influence feature re-evaluation in case if a command line flag like -no-gui is not specified upon second reconfiguration and a FEATURE_foo is manually toggled in the CMakeCache.txt, effectively getting rid of stale INPUT_foo values. Unfortunately that causes an issue when configuring with -no-opengl and then trying to reconfigure with 'cmake .' Specifically various feature options like ENABLE / DISABLE use INPUT_foo variables in their expressions. qt_configure_add_report_entry CONDITIONs also use them. These expect the INPUT_foo variables to be persisted, and if they are removed, the expressions might be re-evaluated to a different value, and cause re-configuration to fail or unexpectedly toggle features. To support both cases described above, instead of removing all INPUT variables when configuration ends, only unset those INPUT variables whose corresponding FEATURE_foo variable has been manually toggled in CMakeCache.txt or via an IDE. Toggling a FEATURE_foo manually is intentional, which means the INPUT_foo value should be discarded. Whereas pre-existing INPUT_bar variables will persist, thus not breaking cases like the -no-opengl report CONDITION. Amends 2799391703e44a34b6557e234462e425a61785f2 Pick-to: 6.6 Fixes: QTBUG-116973 Task-number: QTBUG-112957 Change-Id: I5851255bfa41a9a1d116630a5d9f7b9a74aa93ed Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-09-12 14:57:56 +00:00
set(FEATURE_${feature}_computed_from_input TRUE PARENT_SCOPE)
else()
set(FEATURE_${feature}_computed_from_input FALSE PARENT_SCOPE)
CMake: Handle INPUT_foo values when detecting dirty builds Before this change, the dirty feature code only checked for differences between FEATURE_foo and QT_FEATURE_foo, without taking into account modified INPUT_foo values that might passed via the configure script. This led to issues in certain scenarios when reconfiguring with the configure script. For example configuring with -gui / -DINPUT_gui=ON and then with -no-gui / -DINPUT_gui=OFF would fail saying 'Feature "widgets": Forcing to "ON" breaks its condition' This happens because the widgets feature depends on gui being available, but because INPUT_gui modifications don't trigger the dirty feature re-eval code, we don't recompute the value of widgets. Extract the code that takes into account the INPUT_foo variables into a separate function, and use it both when computing feature values and also when detecting dirty features. This means any non-matching INPUT_foo variables will now also trigger dirty feature checking. Use the same function to replace the duplicate code we have to early initialize the developer-build, no-prefix and pkg-config features. Pick-to: 6.6 Task-number: QTBUG-112957 Change-Id: I775cf70b48291a659b0fecf7cb9570ec12735bca Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-25 16:20:01 +00:00
endif()
endfunction()
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
function(qt_build_internals_disable_pkg_config_if_needed)
CMake: Turn off pkg_config_enabled if pkg_config is not found The qt_build_internals_disable_pkg_config_if_needed function didn't actually check if the pkg-config executable is available when turning the pkg-config feature on. This broke certain configurations like Android (on some hosts). Try to find the executable and take that into account when computing the value of the feature. Task-number: QTBUG-85399 Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-26 16:48:01 +00:00
# pkg-config should not be used by default on Darwin and Windows platforms (and QNX), as defined
# in the qtbase/configure.json. Unfortunately by the time the feature is evaluated there are
# already a few find_package() calls that try to use the FindPkgConfig module.
# Thus, we have to duplicate the condition logic here and disable pkg-config for those platforms
# by default.
# We also need to check if the pkg-config executable exists, to mirror the condition test in
# configure.json. We do that by trying to find the executable ourselves, and not delegating to
# the FindPkgConfig module because that has more unwanted side-effects.
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
#
# Note that on macOS, if the pkg-config feature is enabled by the user explicitly, we will also
# tell CMake to consider paths like /usr/local (Homebrew) as system paths when looking for
# packages.
# We have to do that because disabling these paths but keeping pkg-config
# enabled won't enable finding all system libraries via pkg-config alone, many libraries can
# only be found via FooConfig.cmake files which means /usr/local should be in the system prefix
# path.
CMake: Turn off pkg_config_enabled if pkg_config is not found The qt_build_internals_disable_pkg_config_if_needed function didn't actually check if the pkg-config executable is available when turning the pkg-config feature on. This broke certain configurations like Android (on some hosts). Try to find the executable and take that into account when computing the value of the feature. Task-number: QTBUG-85399 Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-26 16:48:01 +00:00
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
set(pkg_config_enabled ON)
CMake: Turn off pkg_config_enabled if pkg_config is not found The qt_build_internals_disable_pkg_config_if_needed function didn't actually check if the pkg-config executable is available when turning the pkg-config feature on. This broke certain configurations like Android (on some hosts). Try to find the executable and take that into account when computing the value of the feature. Task-number: QTBUG-85399 Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-26 16:48:01 +00:00
qt_build_internals_find_pkg_config_executable()
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(APPLE OR WIN32 OR QNX OR ANDROID OR WASM OR (NOT PKG_CONFIG_EXECUTABLE))
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
set(pkg_config_enabled OFF)
endif()
CMake: Turn off pkg_config_enabled if pkg_config is not found The qt_build_internals_disable_pkg_config_if_needed function didn't actually check if the pkg-config executable is available when turning the pkg-config feature on. This broke certain configurations like Android (on some hosts). Try to find the executable and take that into account when computing the value of the feature. Task-number: QTBUG-85399 Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-26 16:48:01 +00:00
Make -pkg-config configure option actually work The QtBuildInternals config package file gets processed before feature evaluation occurs. That means INPUT_pkg_config may be defined, but the corresponding FEATURE_pkg_config variable won't have been set/updated yet. Do this check locally because the availability of a number of features is conditional on whether pkg-config is available. Change-Id: I6030eb380ee0c630ffbe5db5eed397a46227c7f6 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-01-14 04:12:06 +00:00
# Features won't have been evaluated yet if this is the first run, have to evaluate this here
CMake: Handle INPUT_foo values when detecting dirty builds Before this change, the dirty feature code only checked for differences between FEATURE_foo and QT_FEATURE_foo, without taking into account modified INPUT_foo values that might passed via the configure script. This led to issues in certain scenarios when reconfiguring with the configure script. For example configuring with -gui / -DINPUT_gui=ON and then with -no-gui / -DINPUT_gui=OFF would fail saying 'Feature "widgets": Forcing to "ON" breaks its condition' This happens because the widgets feature depends on gui being available, but because INPUT_gui modifications don't trigger the dirty feature re-eval code, we don't recompute the value of widgets. Extract the code that takes into account the INPUT_foo variables into a separate function, and use it both when computing feature values and also when detecting dirty features. This means any non-matching INPUT_foo variables will now also trigger dirty feature checking. Use the same function to replace the duplicate code we have to early initialize the developer-build, no-prefix and pkg-config features. Pick-to: 6.6 Task-number: QTBUG-112957 Change-Id: I775cf70b48291a659b0fecf7cb9570ec12735bca Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-25 16:20:01 +00:00
qt_internal_compute_feature_value_from_possible_input(pkg_config)
Make -pkg-config configure option actually work The QtBuildInternals config package file gets processed before feature evaluation occurs. That means INPUT_pkg_config may be defined, but the corresponding FEATURE_pkg_config variable won't have been set/updated yet. Do this check locally because the availability of a number of features is conditional on whether pkg-config is available. Change-Id: I6030eb380ee0c630ffbe5db5eed397a46227c7f6 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-01-14 04:12:06 +00:00
CMake: Turn off pkg_config_enabled if pkg_config is not found The qt_build_internals_disable_pkg_config_if_needed function didn't actually check if the pkg-config executable is available when turning the pkg-config feature on. This broke certain configurations like Android (on some hosts). Try to find the executable and take that into account when computing the value of the feature. Task-number: QTBUG-85399 Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-26 16:48:01 +00:00
# If user explicitly specified a value for the feature, honor it, even if it might break
# the build.
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
if(DEFINED FEATURE_pkg_config)
if(FEATURE_pkg_config)
set(pkg_config_enabled ON)
else()
set(pkg_config_enabled OFF)
endif()
endif()
CMake: Turn off pkg_config_enabled if pkg_config is not found The qt_build_internals_disable_pkg_config_if_needed function didn't actually check if the pkg-config executable is available when turning the pkg-config feature on. This broke certain configurations like Android (on some hosts). Try to find the executable and take that into account when computing the value of the feature. Task-number: QTBUG-85399 Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-26 16:48:01 +00:00
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
set(FEATURE_pkg_config "${pkg_config_enabled}" CACHE STRING "Using pkg-config")
if(NOT pkg_config_enabled)
qt_build_internals_disable_pkg_config()
else()
unset(PKG_CONFIG_EXECUTABLE CACHE)
endif()
endfunction()
CMake: Turn off pkg_config_enabled if pkg_config is not found The qt_build_internals_disable_pkg_config_if_needed function didn't actually check if the pkg-config executable is available when turning the pkg-config feature on. This broke certain configurations like Android (on some hosts). Try to find the executable and take that into account when computing the value of the feature. Task-number: QTBUG-85399 Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-26 16:48:01 +00:00
# This is a copy of the first few lines in FindPkgConfig.cmake.
function(qt_build_internals_find_pkg_config_executable)
# find pkg-config, use PKG_CONFIG if set
if((NOT PKG_CONFIG_EXECUTABLE) AND (NOT "$ENV{PKG_CONFIG}" STREQUAL ""))
set(PKG_CONFIG_EXECUTABLE "$ENV{PKG_CONFIG}" CACHE FILEPATH "pkg-config executable")
endif()
find_program(PKG_CONFIG_EXECUTABLE NAMES pkg-config DOC "pkg-config executable")
mark_as_advanced(PKG_CONFIG_EXECUTABLE)
endfunction()
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
function(qt_build_internals_disable_pkg_config)
# Disable pkg-config by setting an empty executable path. There's no documented way to
CMake: Turn off pkg_config_enabled if pkg_config is not found The qt_build_internals_disable_pkg_config_if_needed function didn't actually check if the pkg-config executable is available when turning the pkg-config feature on. This broke certain configurations like Android (on some hosts). Try to find the executable and take that into account when computing the value of the feature. Task-number: QTBUG-85399 Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-26 16:48:01 +00:00
# mark the package as not found, but we can force all pkg_check_modules calls to do nothing
# by setting the variable to an empty value.
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
set(PKG_CONFIG_EXECUTABLE "" CACHE STRING "Disabled pkg-config usage." FORCE)
endfunction()
if(NOT QT_BUILD_INTERNALS_SKIP_PKG_CONFIG_ADJUSTMENT)
qt_build_internals_disable_pkg_config_if_needed()
endif()
macro(qt_build_internals_find_pkg_config)
# Find package config once before any system prefix modifications.
find_package(PkgConfig QUIET)
endmacro()
if(NOT QT_BUILD_INTERNALS_SKIP_FIND_PKG_CONFIG)
qt_build_internals_find_pkg_config()
endif()
function(qt_build_internals_set_up_system_prefixes)
if(APPLE AND NOT FEATURE_pkg_config)
# Remove /usr/local and other paths like that which CMake considers as system prefixes on
# darwin platforms. CMake considers them as system prefixes, but in qmake / Qt land we only
# consider the SDK path as a system prefix.
# 3rd party libraries in these locations should not be picked up when building Qt,
# unless opted-in via the pkg-config feature, which in turn will disable this behavior.
#
# Note that we can't remove /usr as a system prefix path, because many programs won't be
# found then (e.g. perl).
set(QT_CMAKE_SYSTEM_PREFIX_PATH_BACKUP "${CMAKE_SYSTEM_PREFIX_PATH}" PARENT_SCOPE)
set(QT_CMAKE_SYSTEM_FRAMEWORK_PATH_BACKUP "${CMAKE_SYSTEM_FRAMEWORK_PATH}" PARENT_SCOPE)
list(REMOVE_ITEM CMAKE_SYSTEM_PREFIX_PATH
"/usr/local" # Homebrew
CMake: Don't consider /opt/homebrew as a system path for arm64 macOS Homebrew introduced a new default prefix for Apple Silicon machines, so that both arm64 and x86_64 packages can be co-installed on a single system. The intel packages are installed into /usr/local and the arm64 packages are installed into /opt/homebrew. For Qt building purposes, we don't want to find packages in any of homebrew's prefixes unless explicitly requested by the user Currently our arm64 macOS CI config does pick up system libs under new prefix. Remove the new path from the system prefixes. Amends f3c7d22dd04afe8d889585fb5d6426f3d4591e74 Task-number: QTBUG-85447 Change-Id: I381d31c95bcdab26147a331444ba40c7af9d0a95 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-04-15 11:11:00 +00:00
"/opt/homebrew" # Apple Silicon Homebrew
CMake: Don't use libraries in /usr/local by default on macOS qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2020-06-25 16:02:52 +00:00
"/usr/X11R6"
"/usr/pkg"
"/opt"
"/sw" # Fink
"/opt/local" # MacPorts
)
if(_CMAKE_INSTALL_DIR)
list(REMOVE_ITEM CMAKE_SYSTEM_PREFIX_PATH "${_CMAKE_INSTALL_DIR}")
endif()
list(REMOVE_ITEM CMAKE_SYSTEM_FRAMEWORK_PATH "~/Library/Frameworks")
set(CMAKE_SYSTEM_PREFIX_PATH "${CMAKE_SYSTEM_PREFIX_PATH}" PARENT_SCOPE)
set(CMAKE_SYSTEM_FRAMEWORK_PATH "${CMAKE_SYSTEM_FRAMEWORK_PATH}" PARENT_SCOPE)
# Also tell qt_find_package() not to use PATH when looking for packages.
# We can't simply set CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH to OFF because that will break
# find_program(), and for instance ccache won't be found.
# That's why we set a different variable which is used by qt_find_package.
set(QT_NO_USE_FIND_PACKAGE_SYSTEM_ENVIRONMENT_PATH "ON" PARENT_SCOPE)
endif()
endfunction()
if(NOT QT_BUILD_INTERNALS_SKIP_SYSTEM_PREFIX_ADJUSTMENT)
qt_build_internals_set_up_system_prefixes()
endif()
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
# The macro sets all the necessary pre-conditions and setup consistent environment for building
# the Qt repository. It has to be called right after the find_package(Qt6 COMPONENTS BuildInternals)
# call. Otherwise we cannot make sure that all the required policies will be applied to the Qt
# components that are involved in build procedure.
macro(qt_internal_project_setup)
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
# Check for the minimum CMake version.
include(QtCMakeVersionHelpers)
qt_internal_require_suitable_cmake_version()
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
qt_internal_upgrade_cmake_policies()
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
endmacro()
macro(qt_build_internals_set_up_private_api)
# TODO: this call needs to be removed once all repositories got the qtbase update
qt_internal_project_setup()
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
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
# Qt specific setup common for all modules:
include(QtSetup)
include(FeatureSummary)
Optionally include ${repo}Setup.cmake file in qt_build_repo_begin This is meant to keep repo specific functions and macros that should not pollute QtSetup.cmake. For example QtDeclarativeSetup.cmake will automatically be included when building qtdeclarative. Change-Id: I4d26cbb1a7ffafb153a888fc918af337000d5e41 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-05-28 11:33:42 +00:00
# Optionally include a repo specific Setup module.
include(${PROJECT_NAME}Setup OPTIONAL)
cmake: Include repo-specific setup files This is useful for providing private CMake API which is not part of QtBase. Also, fix the setup files to be included when building standalone tests. The old ${PROJECT_NAME}Setup.cmake file inclusion will be removed once all usages are adjusted. Prompted-by: Alexandru Croitor <alexandru.croitor@qt.io> Change-Id: I5bc2bca7371660c00b0301e94d025a29b68d6975 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-09-20 13:20:57 +00:00
include(QtRepoSetup OPTIONAL)
Automatically find apple frameworks when building a repo Instead of doing it just in qtbase/src, we need to do it for all repos before building ./src. Change-Id: I57f226b849cd5370ffbbbea8a694697d400957a4 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io>
2019-06-13 13:55:38 +00:00
# Find Apple frameworks if needed.
qt_find_apple_system_frameworks()
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
# Decide whether tools will be built.
qt_check_if_tools_will_be_built()
CMake: Provide script to configure and build one or more tests Before this patch there were a few ways to build tests - Configure all tests as part of the repo build - Configure all tests as part of the repo build, but don't build tests by default (-DQT_NO_MAKE_TESTS=ON) - Configure all tests as a standalone project in a separate build dir using -QT_BUILD_STANDALONE_TESTS=ON All of the above incur some time overhead due to the necessity of configuring all tests. Sometimes you just want to build ONE test (or a few). To facilitate that use case, a new shell script called bin/qt-cmake-standalone-test(.bat) can now be used to configure and build one or more tests. The script takes one single argument pointing to the desired test project path and configures a generic template project that sets up all the necessary Qt CMake private API, afterwards calling add_subdirectory on the passed in project. Example $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon or $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image After that, simply run 'ninja && ctest' to build and run the test(s). This is the CMake equivalent of calling qmake on a test .pro file (or on a tests SUBDIRS .pro file) There are 3 details worth mentioning. Due to the add_subdirectory call, the built artifacts will not be in the top-level build dir, but rather in a nested build_dir. The script currently can't handle more than one argument (the path to the project), so you can't pass additional -DFoo=bar arguments. If a test uses a 3rd party library (like Threads::Threads) which was not a public dependency for any of the Qt modules, configuration will fail saying that the target was not found. Perhaps we should consider recording these packages when generating the StandaloneConfig.cmake files. Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-18 18:09:00 +00:00
endmacro()
Toplevel builds: Add utility toplevel targets for each module Add a target for each level-1 subdirectory in a module. Ninja already generates phony targets such as "qtbase/src/all", but those are not available in e.g. IDE integrations of CMake. With this addition, targets like qtbase, qtbase_src, and qtbase_tests are available in IDEs. Pick-to: 6.0 6.0.0 Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 23:36:44 +00:00
# find all targets defined in $subdir by recursing through all added subdirectories
# populates $qt_repo_targets with a ;-list of non-UTILITY targets
macro(qt_build_internals_get_repo_targets subdir)
Fix top-level build repository targets The directory-level targets missed the first level of sub-targets. E.g. `qtbase_qmake` did not have a dependency to `qmake`. Fix qt_build_internals_get_repo_targets to first grab all targets of the subdirectory and then recurse. Pick-to: 6.1 6.0 Change-Id: I3604000caec22fac9a4cc5f5aaf651d550d16793 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-16 14:31:25 +00:00
get_directory_property(_targets DIRECTORY "${subdir}" BUILDSYSTEM_TARGETS)
if(_targets)
foreach(_target IN LISTS _targets)
get_target_property(_type ${_target} TYPE)
Add INTERFACE_LIBRARIES to dependencies of repo targets Building repo targets may be incomplete as we skip adding INTERFACE_LIBRARIES as dependencies. This leads to the missing artifacts belonging to HEADER_MODULES. It seems reasonable and safe to include INTERFACE_LIBRARIES in the list of dependencies of the repo targets. Pick-to: 6.4 6.2 Task-number: QTBUG-108815 Change-Id: I83f44018f42dcf2fb1e3299461e17ef53e79c2e5 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-11-24 11:28:34 +00:00
if(NOT ${_type} STREQUAL "UTILITY")
Fix top-level build repository targets The directory-level targets missed the first level of sub-targets. E.g. `qtbase_qmake` did not have a dependency to `qmake`. Fix qt_build_internals_get_repo_targets to first grab all targets of the subdirectory and then recurse. Pick-to: 6.1 6.0 Change-Id: I3604000caec22fac9a4cc5f5aaf651d550d16793 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-16 14:31:25 +00:00
list(APPEND qt_repo_targets "${_target}")
endif()
endforeach()
endif()
Toplevel builds: Add utility toplevel targets for each module Add a target for each level-1 subdirectory in a module. Ninja already generates phony targets such as "qtbase/src/all", but those are not available in e.g. IDE integrations of CMake. With this addition, targets like qtbase, qtbase_src, and qtbase_tests are available in IDEs. Pick-to: 6.0 6.0.0 Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 23:36:44 +00:00
get_directory_property(_directories DIRECTORY "${subdir}" SUBDIRECTORIES)
if (_directories)
foreach(_directory IN LISTS _directories)
qt_build_internals_get_repo_targets("${_directory}")
endforeach()
endif()
endmacro()
# add toplevel targets for each subdirectory, e.g. qtbase_src
function(qt_build_internals_add_toplevel_targets)
set(qt_repo_target_all "")
get_directory_property(directories DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}" SUBDIRECTORIES)
foreach(directory IN LISTS directories)
set(qt_repo_targets "")
get_filename_component(qt_repo_target_basename ${directory} NAME)
qt_build_internals_get_repo_targets("${directory}")
if (qt_repo_targets)
set(qt_repo_target_name "${qt_repo_targets_name}_${qt_repo_target_basename}")
message(DEBUG "${qt_repo_target_name} depends on ${qt_repo_targets}")
add_custom_target("${qt_repo_target_name}"
CMake: Fix Ninja Multi-Config dependency issues for top-level targets When building qtsvg examples as external projects on Windows with Ninja Multi-Config in a prefix build on the CI, the build would fail with an error message like: ninja: error: 'C:/Users/qt/work/qt/qtsvg/lib/Qt6SvgWidgets.lib', needed by 'RelWithDebInfo/svgviewer.exe', missing and no known rule to make it This can be reproduced locally on Windows if one calls 'ninja svgviewer' instead of just 'ninja'. I wasn't able to reproduce it on macOS, although I have seen some peculiarities in the dependencies there as well. External project examples depend on the ${repo_name}_src custom target to ensure all Qt modules are built, so one would expect that dependency to be sufficient. While trying to figure out what's going wrong, I noticed that running 'ninja -t query qtsvg_src:Debug' showed dependencies on Release libraries, which should not happen. The :Release target looked fine though. I'm still not quite sure why the Release libraries are not built on the first ninja run, despite the example having a proper dependency on qtsvg:Release. Running 'ninja svgviewer' a few more times ends up succeeding at one point, because the SvgWidgets Release library does get built in parallel with the failing example, and the next rebuild would succeed. While trying to fix the :Debug target to have proper dependencies, I noticed that we add dependencies to the ${repo_name}_src custom target via the DEPENDS option of add_custom_target(). That is incorrect, that option should only be used for file level dependencies. For target dependencies, add_dependencies should be used. Doing that fixed both the :Debug dependencies as well as the Windows issue, which is good enough for me. Amends 08f46bb40075778e89ba9aed3cef53d990852022 Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I1888681e2e9362d3237acbdacc83222d6a60b48e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-03 13:22:50 +00:00
COMMENT "Building everything in ${qt_repo_targets_name}/${qt_repo_target_basename}")
add_dependencies("${qt_repo_target_name}" ${qt_repo_targets})
Toplevel builds: Add utility toplevel targets for each module Add a target for each level-1 subdirectory in a module. Ninja already generates phony targets such as "qtbase/src/all", but those are not available in e.g. IDE integrations of CMake. With this addition, targets like qtbase, qtbase_src, and qtbase_tests are available in IDEs. Pick-to: 6.0 6.0.0 Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 23:36:44 +00:00
list(APPEND qt_repo_target_all "${qt_repo_target_name}")
CMake: Work around AUTOUIC Ninja Multi-Config issue with EP examples AUTOUIC doesn't handle relative paths to .ui files in parent directories when using Ninja Multi-Config. The designer tool in qttools has such a ui file. This leads to the following error when trying to build qttools together with examples as ExternalProjects and Ninja Multi-Config: ninja: error: 'src/designer/src/designer/designer_autogen/ include_Debug/ui_preferencesdialog.h', needed by 'src/designer/src/designer/designer_autogen:Debug', missing and no known rule to make it Until cmake is fixed, we can work around the issue by not adding designer as a dependency when building EP examples, because no example tries to use the app. We can't exclude all apps from example dependencies because some modules use qt_internal_add_app for tools as well, which are called from public CMake API and also examples. An example of this is qtapplicationmanager. Given that we can't exclude all apps, introduce a function to allow skipping single targets when building EP examples. This will allow excluding designer specifically. The examples will now depend on a new ${repo}_src_for_examples target rather than ${repo}_src, which will exclude skipped targets. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Task-number: QTBUG-110369 Change-Id: I2f900253bbf7bac917f2293ef604ab3ea8f298e1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-01-19 17:55:58 +00:00
# Create special dependency target for External Project examples excluding targets
# marked as skipped.
CMake: Don't create superfluous qtrepo_XXX_for_examples targets Only create a qtrepo_src_for_examples target that examples, built as external projects, can depend on. Change-Id: I334bc67b9b78f49d5c345cb256132f42dc2c5f5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-18 11:53:44 +00:00
if(qt_repo_target_basename STREQUAL "src")
set(qt_repo_target_name
"${qt_repo_targets_name}_${qt_repo_target_basename}_for_examples")
add_custom_target("${qt_repo_target_name}")
set(unskipped_targets "")
foreach(target IN LISTS qt_repo_targets)
if(TARGET "${target}")
qt_internal_is_target_skipped_for_examples("${target}" is_skipped)
if(NOT is_skipped)
list(APPEND unskipped_targets "${target}")
endif()
CMake: Work around AUTOUIC Ninja Multi-Config issue with EP examples AUTOUIC doesn't handle relative paths to .ui files in parent directories when using Ninja Multi-Config. The designer tool in qttools has such a ui file. This leads to the following error when trying to build qttools together with examples as ExternalProjects and Ninja Multi-Config: ninja: error: 'src/designer/src/designer/designer_autogen/ include_Debug/ui_preferencesdialog.h', needed by 'src/designer/src/designer/designer_autogen:Debug', missing and no known rule to make it Until cmake is fixed, we can work around the issue by not adding designer as a dependency when building EP examples, because no example tries to use the app. We can't exclude all apps from example dependencies because some modules use qt_internal_add_app for tools as well, which are called from public CMake API and also examples. An example of this is qtapplicationmanager. Given that we can't exclude all apps, introduce a function to allow skipping single targets when building EP examples. This will allow excluding designer specifically. The examples will now depend on a new ${repo}_src_for_examples target rather than ${repo}_src, which will exclude skipped targets. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Task-number: QTBUG-110369 Change-Id: I2f900253bbf7bac917f2293ef604ab3ea8f298e1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-01-19 17:55:58 +00:00
endif()
CMake: Don't create superfluous qtrepo_XXX_for_examples targets Only create a qtrepo_src_for_examples target that examples, built as external projects, can depend on. Change-Id: I334bc67b9b78f49d5c345cb256132f42dc2c5f5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-18 11:53:44 +00:00
endforeach()
if(unskipped_targets)
add_dependencies("${qt_repo_target_name}" ${unskipped_targets})
CMake: Work around AUTOUIC Ninja Multi-Config issue with EP examples AUTOUIC doesn't handle relative paths to .ui files in parent directories when using Ninja Multi-Config. The designer tool in qttools has such a ui file. This leads to the following error when trying to build qttools together with examples as ExternalProjects and Ninja Multi-Config: ninja: error: 'src/designer/src/designer/designer_autogen/ include_Debug/ui_preferencesdialog.h', needed by 'src/designer/src/designer/designer_autogen:Debug', missing and no known rule to make it Until cmake is fixed, we can work around the issue by not adding designer as a dependency when building EP examples, because no example tries to use the app. We can't exclude all apps from example dependencies because some modules use qt_internal_add_app for tools as well, which are called from public CMake API and also examples. An example of this is qtapplicationmanager. Given that we can't exclude all apps, introduce a function to allow skipping single targets when building EP examples. This will allow excluding designer specifically. The examples will now depend on a new ${repo}_src_for_examples target rather than ${repo}_src, which will exclude skipped targets. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Task-number: QTBUG-110369 Change-Id: I2f900253bbf7bac917f2293ef604ab3ea8f298e1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-01-19 17:55:58 +00:00
endif()
endif()
Toplevel builds: Add utility toplevel targets for each module Add a target for each level-1 subdirectory in a module. Ninja already generates phony targets such as "qtbase/src/all", but those are not available in e.g. IDE integrations of CMake. With this addition, targets like qtbase, qtbase_src, and qtbase_tests are available in IDEs. Pick-to: 6.0 6.0.0 Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 23:36:44 +00:00
endif()
CMake: Work around AUTOUIC Ninja Multi-Config issue with EP examples AUTOUIC doesn't handle relative paths to .ui files in parent directories when using Ninja Multi-Config. The designer tool in qttools has such a ui file. This leads to the following error when trying to build qttools together with examples as ExternalProjects and Ninja Multi-Config: ninja: error: 'src/designer/src/designer/designer_autogen/ include_Debug/ui_preferencesdialog.h', needed by 'src/designer/src/designer/designer_autogen:Debug', missing and no known rule to make it Until cmake is fixed, we can work around the issue by not adding designer as a dependency when building EP examples, because no example tries to use the app. We can't exclude all apps from example dependencies because some modules use qt_internal_add_app for tools as well, which are called from public CMake API and also examples. An example of this is qtapplicationmanager. Given that we can't exclude all apps, introduce a function to allow skipping single targets when building EP examples. This will allow excluding designer specifically. The examples will now depend on a new ${repo}_src_for_examples target rather than ${repo}_src, which will exclude skipped targets. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Task-number: QTBUG-110369 Change-Id: I2f900253bbf7bac917f2293ef604ab3ea8f298e1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-01-19 17:55:58 +00:00
Toplevel builds: Add utility toplevel targets for each module Add a target for each level-1 subdirectory in a module. Ninja already generates phony targets such as "qtbase/src/all", but those are not available in e.g. IDE integrations of CMake. With this addition, targets like qtbase, qtbase_src, and qtbase_tests are available in IDEs. Pick-to: 6.0 6.0.0 Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 23:36:44 +00:00
endforeach()
if (qt_repo_target_all)
CMake: Fix Ninja Multi-Config dependency issues for top-level targets When building qtsvg examples as external projects on Windows with Ninja Multi-Config in a prefix build on the CI, the build would fail with an error message like: ninja: error: 'C:/Users/qt/work/qt/qtsvg/lib/Qt6SvgWidgets.lib', needed by 'RelWithDebInfo/svgviewer.exe', missing and no known rule to make it This can be reproduced locally on Windows if one calls 'ninja svgviewer' instead of just 'ninja'. I wasn't able to reproduce it on macOS, although I have seen some peculiarities in the dependencies there as well. External project examples depend on the ${repo_name}_src custom target to ensure all Qt modules are built, so one would expect that dependency to be sufficient. While trying to figure out what's going wrong, I noticed that running 'ninja -t query qtsvg_src:Debug' showed dependencies on Release libraries, which should not happen. The :Release target looked fine though. I'm still not quite sure why the Release libraries are not built on the first ninja run, despite the example having a proper dependency on qtsvg:Release. Running 'ninja svgviewer' a few more times ends up succeeding at one point, because the SvgWidgets Release library does get built in parallel with the failing example, and the next rebuild would succeed. While trying to fix the :Debug target to have proper dependencies, I noticed that we add dependencies to the ${repo_name}_src custom target via the DEPENDS option of add_custom_target(). That is incorrect, that option should only be used for file level dependencies. For target dependencies, add_dependencies should be used. Doing that fixed both the :Debug dependencies as well as the Windows issue, which is good enough for me. Amends 08f46bb40075778e89ba9aed3cef53d990852022 Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I1888681e2e9362d3237acbdacc83222d6a60b48e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-03 13:22:50 +00:00
# Note qt_repo_targets_name is different from qt_repo_target_name that is used above.
Toplevel builds: Add utility toplevel targets for each module Add a target for each level-1 subdirectory in a module. Ninja already generates phony targets such as "qtbase/src/all", but those are not available in e.g. IDE integrations of CMake. With this addition, targets like qtbase, qtbase_src, and qtbase_tests are available in IDEs. Pick-to: 6.0 6.0.0 Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 23:36:44 +00:00
add_custom_target("${qt_repo_targets_name}"
COMMENT "Building everything in ${qt_repo_targets_name}")
CMake: Fix Ninja Multi-Config dependency issues for top-level targets When building qtsvg examples as external projects on Windows with Ninja Multi-Config in a prefix build on the CI, the build would fail with an error message like: ninja: error: 'C:/Users/qt/work/qt/qtsvg/lib/Qt6SvgWidgets.lib', needed by 'RelWithDebInfo/svgviewer.exe', missing and no known rule to make it This can be reproduced locally on Windows if one calls 'ninja svgviewer' instead of just 'ninja'. I wasn't able to reproduce it on macOS, although I have seen some peculiarities in the dependencies there as well. External project examples depend on the ${repo_name}_src custom target to ensure all Qt modules are built, so one would expect that dependency to be sufficient. While trying to figure out what's going wrong, I noticed that running 'ninja -t query qtsvg_src:Debug' showed dependencies on Release libraries, which should not happen. The :Release target looked fine though. I'm still not quite sure why the Release libraries are not built on the first ninja run, despite the example having a proper dependency on qtsvg:Release. Running 'ninja svgviewer' a few more times ends up succeeding at one point, because the SvgWidgets Release library does get built in parallel with the failing example, and the next rebuild would succeed. While trying to fix the :Debug target to have proper dependencies, I noticed that we add dependencies to the ${repo_name}_src custom target via the DEPENDS option of add_custom_target(). That is incorrect, that option should only be used for file level dependencies. For target dependencies, add_dependencies should be used. Doing that fixed both the :Debug dependencies as well as the Windows issue, which is good enough for me. Amends 08f46bb40075778e89ba9aed3cef53d990852022 Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I1888681e2e9362d3237acbdacc83222d6a60b48e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-03 13:22:50 +00:00
add_dependencies("${qt_repo_targets_name}" ${qt_repo_target_all})
message(DEBUG "${qt_repo_targets_name} depends on ${qt_repo_target_all}")
Toplevel builds: Add utility toplevel targets for each module Add a target for each level-1 subdirectory in a module. Ninja already generates phony targets such as "qtbase/src/all", but those are not available in e.g. IDE integrations of CMake. With this addition, targets like qtbase, qtbase_src, and qtbase_tests are available in IDEs. Pick-to: 6.0 6.0.0 Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 23:36:44 +00:00
endif()
endfunction()
CMake: Adjust PCH support for multi-arch iOS builds Starting with CMake 3.18, there is PCH support for darwin multi-arch builds, like iOS simulator_and_device builds. Also enable PCH for Objective-C++ files when the support is there. To enable PCH for Objective-C++, we need to do enable the OBJCXX language as well, but conditionally, because on non-darwin platforms the language is probably not available. Introduce the qt_enable_cmake_languages() macro which is called automatically by qt_build_repo_begin(). Change-Id: I0e7f44be6577ac54ce940470036626409920e272 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-03 12:23:18 +00:00
macro(qt_enable_cmake_languages)
set(__qt_required_language_list C CXX)
CMake: Don't use check_language for Objective-C/C++ The check_language macro spawns a new cmake subprocess to detect availability of a language. We use that to detect availability of the Objective-C/C++ languages when targeting Apple platforms. That's problematic because the parent process CFLAGS / LDFLAGS env vars influences the result of the subprocess compiler detection, and in some cases that can fail the detection. An example of that is passing iOS specific flags which then get mixed with the default macOS flags added by CMake, resulting in a linker failure. Instead of using check_language, explicitly enable the Objective-C and C++ languages when targeting Apple platforms because we know that we need them for compiling Qt. This avoids the issue because enable_language is not spawning a separate cmake sub-process and thus passes more information to the underlying try_compile project to ensure a successful check. The change also means that CMake will error out earlier in case if the Objective-C compiler is not found, which was not the case before. Pick-to: 6.5 6.6 Fixes: QTBUG-114470 Change-Id: I1a16c1e5828dfe10b2d7da27cc9a8c787517ab8e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-06-27 13:25:50 +00:00
set(__qt_platform_required_language_list )
CMake: Autodetect Objective-C support only on macOS On Android, check_language() reports that the languages are supported, but enable_language fails afterwards. On Linux it causes issues with the PCH. The PCH file might contain a Clang pragma, even though the C++ compiler is GCC. Presumably due to finding a Clang Objective-C compiler. Change-Id: I1b4c54459772c089e7f6350872c87af52ad72a37 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2020-04-06 13:52:48 +00:00
if(APPLE)
CMake: Don't use check_language for Objective-C/C++ The check_language macro spawns a new cmake subprocess to detect availability of a language. We use that to detect availability of the Objective-C/C++ languages when targeting Apple platforms. That's problematic because the parent process CFLAGS / LDFLAGS env vars influences the result of the subprocess compiler detection, and in some cases that can fail the detection. An example of that is passing iOS specific flags which then get mixed with the default macOS flags added by CMake, resulting in a linker failure. Instead of using check_language, explicitly enable the Objective-C and C++ languages when targeting Apple platforms because we know that we need them for compiling Qt. This avoids the issue because enable_language is not spawning a separate cmake sub-process and thus passes more information to the underlying try_compile project to ensure a successful check. The change also means that CMake will error out earlier in case if the Objective-C compiler is not found, which was not the case before. Pick-to: 6.5 6.6 Fixes: QTBUG-114470 Change-Id: I1a16c1e5828dfe10b2d7da27cc9a8c787517ab8e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-06-27 13:25:50 +00:00
list(APPEND __qt_platform_required_language_list OBJC OBJCXX)
CMake: Autodetect Objective-C support only on macOS On Android, check_language() reports that the languages are supported, but enable_language fails afterwards. On Linux it causes issues with the PCH. The PCH file might contain a Clang pragma, even though the C++ compiler is GCC. Presumably due to finding a Clang Objective-C compiler. Change-Id: I1b4c54459772c089e7f6350872c87af52ad72a37 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2020-04-06 13:52:48 +00:00
endif()
CMake: Adjust PCH support for multi-arch iOS builds Starting with CMake 3.18, there is PCH support for darwin multi-arch builds, like iOS simulator_and_device builds. Also enable PCH for Objective-C++ files when the support is there. To enable PCH for Objective-C++, we need to do enable the OBJCXX language as well, but conditionally, because on non-darwin platforms the language is probably not available. Introduce the qt_enable_cmake_languages() macro which is called automatically by qt_build_repo_begin(). Change-Id: I0e7f44be6577ac54ce940470036626409920e272 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-03 12:23:18 +00:00
foreach(__qt_lang ${__qt_required_language_list})
enable_language(${__qt_lang})
endforeach()
CMake: Don't use check_language for Objective-C/C++ The check_language macro spawns a new cmake subprocess to detect availability of a language. We use that to detect availability of the Objective-C/C++ languages when targeting Apple platforms. That's problematic because the parent process CFLAGS / LDFLAGS env vars influences the result of the subprocess compiler detection, and in some cases that can fail the detection. An example of that is passing iOS specific flags which then get mixed with the default macOS flags added by CMake, resulting in a linker failure. Instead of using check_language, explicitly enable the Objective-C and C++ languages when targeting Apple platforms because we know that we need them for compiling Qt. This avoids the issue because enable_language is not spawning a separate cmake sub-process and thus passes more information to the underlying try_compile project to ensure a successful check. The change also means that CMake will error out earlier in case if the Objective-C compiler is not found, which was not the case before. Pick-to: 6.5 6.6 Fixes: QTBUG-114470 Change-Id: I1a16c1e5828dfe10b2d7da27cc9a8c787517ab8e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-06-27 13:25:50 +00:00
foreach(__qt_lang ${__qt_platform_required_language_list})
enable_language(${__qt_lang})
CMake: Adjust PCH support for multi-arch iOS builds Starting with CMake 3.18, there is PCH support for darwin multi-arch builds, like iOS simulator_and_device builds. Also enable PCH for Objective-C++ files when the support is there. To enable PCH for Objective-C++, we need to do enable the OBJCXX language as well, but conditionally, because on non-darwin platforms the language is probably not available. Introduce the qt_enable_cmake_languages() macro which is called automatically by qt_build_repo_begin(). Change-Id: I0e7f44be6577ac54ce940470036626409920e272 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-03 12:23:18 +00:00
endforeach()
CMake: Adjust compiler flag optimizations to qmake mkspec ones There are inconsistencies in the default optimization flags added by CMake across configurations like Release and RelWithDebInfo. In particular Release uses -O3, whereas RelWithDebInfo uses -O2, as well as usage of /INCREMENTAL in release configs with MSVC, etc. To make sure that the Qt 6 binaries built with CMake are consistent across configs, as well as consistent with the flags we used when building Qt 5 with qmake, add a horrible search and replace mechanism to replaces the CMake flags with what our mkspecs indicate to use. Ideally this would be done by providing custom CMake toolchain files for each platform we support, and we might revisit that later if the need really arises. To implement the replacing, we first need the flags that should be added. Port the QMAKE_CFLAGS_OPTIMIZE variables to CMake, which is done in QtCompilerOptimization.cmake. Then a new function called qt_internal_set_up_config_optimizations_like_in_qmake will look for any kind of optimization flags set in the CMAKE_<LANG>_FLAGS_<CONFIG> style variables, remove them, and add the appropriate flags that qmake mkspecs provide. On some platforms (like Windows MSVC) the function also alters the linker CMAKE_${TYPE}_LINKER_FLAGS_<CONFIG> style variables. The mechanism allows opting out of this replacing by setting the QT_USE_DEFAULT_CMAKE_OPTIMIZATION_FLAGS value. It also allows opting into removal of flags for custom configs by providing QT_ADDITIONAL_OPTIMIZATION_FLAG_CONFIGS. It's only removal, because we wouldn't know what kind of config it is, and thus what flags to add. The currently modified configs are: Release, RelWithDebInfo, MinSizeRel, Debug aka the usual default CMake provided ones. The mechanism is only applied to C-like languages. ASM is not handled to be on the safe side due to not knowing what kind of compiler flags the platform assembler might take. It's also important to skip RC on MSVC platforms. Task-number: QTBUG-85992 Change-Id: I3712d5cd5a34fceab54f56a6fa46b4e678952362 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-17 15:32:28 +00:00
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
# The qtbase call is handled in qtbase/CMakeLists.txt.
# This call is used for projects other than qtbase, including for other project's standalone
# tests.
# Because the function uses QT_FEATURE_foo values, it's important that find_package(Qt6Core) is
# called before this function. but that's usually the case for Qt repos.
CMake: Implement configure -optimize-debug Task-number: QTBUG-85373 Change-Id: I3aba1fcf96e36544dd75a5e6adc5f770a9a45726 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-20 08:19:32 +00:00
if(NOT PROJECT_NAME STREQUAL "QtBase")
qt_internal_set_up_config_optimizations_like_in_qmake()
endif()
CMake: Adjust PCH support for multi-arch iOS builds Starting with CMake 3.18, there is PCH support for darwin multi-arch builds, like iOS simulator_and_device builds. Also enable PCH for Objective-C++ files when the support is there. To enable PCH for Objective-C++, we need to do enable the OBJCXX language as well, but conditionally, because on non-darwin platforms the language is probably not available. Introduce the qt_enable_cmake_languages() macro which is called automatically by qt_build_repo_begin(). Change-Id: I0e7f44be6577ac54ce940470036626409920e272 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-03 12:23:18 +00:00
endmacro()
CMake: Allow sqldriver plugins to be built as standalone This patch allows all the sqldrivers to be built as a standalone project. It is not possible to build each plugin separately due to the configuration features definition being located in the sqldriver's folder CMakeLists.txt. In other words, the project needs to be generated from the src/plugins/sqldrivers/CMakeLists.txt file. Fixes: QTBUG-82962 Change-Id: If41c7e3827589391830a894a9c998d2e56239562 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-23 09:24:48 +00:00
# Minimum setup required to have any CMakeList.txt build as as a standalone
# project after importing BuildInternals
macro(qt_prepare_standalone_project)
qt_set_up_build_internals_paths()
qt_build_internals_set_up_private_api()
qt_enable_cmake_languages()
endmacro()
Add support for building and installing repo target sets Introduce the concept of repository target sets, which is a named set of targets within a Qt module repository. In a Qt repository, a repo target set 'qtfoo' can be defined in the top-level project file with qt_internal_define_repo_target_set(qtfoo DEPENDS Bar Baz) The DEPENDS argument specifies Qt components that need to be find_package'd when building the targets that belong to qtfoo. In subdirectory project files, use qt_internal_include_in_repo_target_set(qtfoo) to mark the file as belonging to the repo target set. To build and install a single repo target set, specify QT_BUILD_SINGLE_REPO_TARGET_SET=qtfoo when configuring the Qt repository. Change-Id: Ic9e6213e3225988fd561f315bc857ee44ff17420 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-06 14:27:48 +00:00
# Define a repo target set, and store accompanying information.
#
# A repo target set is a subset of targets in a Qt module repository. To build a repo target set,
# set QT_BUILD_SINGLE_REPO_TARGET_SET to the name of the repo target set.
#
# This function is to be called in the top-level project file of a repository,
# before qt_internal_prepare_single_repo_target_set_build()
#
# This function stores information in variables of the parent scope.
#
# Positional Arguments:
# name - The name of this repo target set.
#
# Named Arguments:
# DEPENDS - List of Qt6 COMPONENTS that are build dependencies of this repo target set.
function(qt_internal_define_repo_target_set name)
set(oneValueArgs DEPENDS)
set(prefix QT_REPO_TARGET_SET_)
cmake_parse_arguments(${prefix}${name} "" ${oneValueArgs} "" ${ARGN})
foreach(arg IN LISTS oneValueArgs)
set(${prefix}${name}_${arg} ${${prefix}${name}_${arg}} PARENT_SCOPE)
endforeach()
set(QT_REPO_KNOWN_TARGET_SETS "${QT_REPO_KNOWN_TARGET_SETS};${name}" PARENT_SCOPE)
endfunction()
# Setup a single repo target set build if QT_BUILD_SINGLE_REPO_TARGET_SET is defined.
#
# This macro must be called in the top-level project file of the repository after all repo target
# sets have been defined.
macro(qt_internal_prepare_single_repo_target_set_build)
if(DEFINED QT_BUILD_SINGLE_REPO_TARGET_SET)
if(NOT QT_BUILD_SINGLE_REPO_TARGET_SET IN_LIST QT_REPO_KNOWN_TARGET_SETS)
message(FATAL_ERROR
"Repo target set '${QT_BUILD_SINGLE_REPO_TARGET_SET}' is undefined.")
endif()
message(STATUS
"Preparing single repo target set build of ${QT_BUILD_SINGLE_REPO_TARGET_SET}")
if (NOT "${QT_REPO_TARGET_SET_${QT_BUILD_SINGLE_REPO_TARGET_SET}_DEPENDS}" STREQUAL "")
find_package(${INSTALL_CMAKE_NAMESPACE} ${PROJECT_VERSION} CONFIG REQUIRED
COMPONENTS ${QT_REPO_TARGET_SET_${QT_BUILD_SINGLE_REPO_TARGET_SET}_DEPENDS})
endif()
endif()
endmacro()
CMake: Provide script to configure and build one or more tests Before this patch there were a few ways to build tests - Configure all tests as part of the repo build - Configure all tests as part of the repo build, but don't build tests by default (-DQT_NO_MAKE_TESTS=ON) - Configure all tests as a standalone project in a separate build dir using -QT_BUILD_STANDALONE_TESTS=ON All of the above incur some time overhead due to the necessity of configuring all tests. Sometimes you just want to build ONE test (or a few). To facilitate that use case, a new shell script called bin/qt-cmake-standalone-test(.bat) can now be used to configure and build one or more tests. The script takes one single argument pointing to the desired test project path and configures a generic template project that sets up all the necessary Qt CMake private API, afterwards calling add_subdirectory on the passed in project. Example $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon or $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image After that, simply run 'ninja && ctest' to build and run the test(s). This is the CMake equivalent of calling qmake on a test .pro file (or on a tests SUBDIRS .pro file) There are 3 details worth mentioning. Due to the add_subdirectory call, the built artifacts will not be in the top-level build dir, but rather in a nested build_dir. The script currently can't handle more than one argument (the path to the project), so you can't pass additional -DFoo=bar arguments. If a test uses a 3rd party library (like Threads::Threads) which was not a public dependency for any of the Qt modules, configuration will fail saying that the target was not found. Perhaps we should consider recording these packages when generating the StandaloneConfig.cmake files. Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-18 18:09:00 +00:00
macro(qt_build_repo_begin)
CMake: Fix find_package(Qt6*Tools) in non-qtbase tests Tests in non-qtbase modules could not find_package their own Qt6*Tools packages, because add_subdirectory(tests) was called before the config files for Qt6*Tools were created. The creation of tools config files is done in QtPostProcess.cmake, which was included in qt_build_repo_end(). Move that include into its own macro, qt_build_repo_post_process() and remove it from qt_build_repo_end(). Call qt_build_repo_post_process() before the 'tests' directory is added in qt_build_repo(). Every call site of qt_build_repo_end() must now be adjusted and call qt_build_repo_post_process(). Task-number: QTBUG-88264 Change-Id: I80d60a1b5c0e9b715c298ef4934b562f815432d1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-18 13:48:21 +00:00
set(QT_INTERNAL_REPO_POST_PROCESS_CALLED FALSE)
Use CMAKE_MESSAGE_CONTEXT for Better CMake Output Messages Each module now identifies its actions during the configuration by a prefix, e.g., `[QtBase]`. In addition, - I have slightly modified some of the `message()` commands to get a more coherent output. - `syncqt.cpp` prints its output as WARNING if any Change-Id: I3922d75a668d94f402068f4121751b7fcb6522b4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-10-25 14:48:21 +00:00
list(APPEND CMAKE_MESSAGE_CONTEXT "${PROJECT_NAME}")
CMake: Provide script to configure and build one or more tests Before this patch there were a few ways to build tests - Configure all tests as part of the repo build - Configure all tests as part of the repo build, but don't build tests by default (-DQT_NO_MAKE_TESTS=ON) - Configure all tests as a standalone project in a separate build dir using -QT_BUILD_STANDALONE_TESTS=ON All of the above incur some time overhead due to the necessity of configuring all tests. Sometimes you just want to build ONE test (or a few). To facilitate that use case, a new shell script called bin/qt-cmake-standalone-test(.bat) can now be used to configure and build one or more tests. The script takes one single argument pointing to the desired test project path and configures a generic template project that sets up all the necessary Qt CMake private API, afterwards calling add_subdirectory on the passed in project. Example $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon or $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image After that, simply run 'ninja && ctest' to build and run the test(s). This is the CMake equivalent of calling qmake on a test .pro file (or on a tests SUBDIRS .pro file) There are 3 details worth mentioning. Due to the add_subdirectory call, the built artifacts will not be in the top-level build dir, but rather in a nested build_dir. The script currently can't handle more than one argument (the path to the project), so you can't pass additional -DFoo=bar arguments. If a test uses a 3rd party library (like Threads::Threads) which was not a public dependency for any of the Qt modules, configuration will fail saying that the target was not found. Perhaps we should consider recording these packages when generating the StandaloneConfig.cmake files. Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-18 18:09:00 +00:00
qt_build_internals_set_up_private_api()
Rework how installation is prevented in non-prefix builds In non-prefix builds, we want to prevent users from accidentally running "cmake --install". We did that by replacing cmake_install.cmake with an empty file. The responsible target remove_cmake_install is visible in IDEs, appears in the build output, and the approach is hacky. It's cleaner and easier to add bail out code at the top of cmake_install.cmake. This is now done when calling qt_build_repo_begin. As a bonus, print an informative message on installation. Change-Id: I022b36289358ba09cac8b79781f44cd7b93113f7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-08 07:30:11 +00:00
# Prevent installation in non-prefix builds.
# We need to associate targets with export names, and that is only possible to do with the
# install(TARGETS) command. But in a non-prefix build, we don't want to install anything.
# To make sure that developers don't accidentally run make install, add bail out code to
# cmake_install.cmake.
if(NOT QT_WILL_INSTALL)
# In a top-level build, print a message only in qtbase, which is the first repository.
if(NOT QT_SUPERBUILD OR (PROJECT_NAME STREQUAL "QtBase"))
install(CODE [[message(FATAL_ERROR
"Qt was configured as non-prefix build. "
"Installation is not supported for this arrangement.")]])
endif()
install(CODE [[return()]])
endif()
CMake: Adjust PCH support for multi-arch iOS builds Starting with CMake 3.18, there is PCH support for darwin multi-arch builds, like iOS simulator_and_device builds. Also enable PCH for Objective-C++ files when the support is there. To enable PCH for Objective-C++, we need to do enable the OBJCXX language as well, but conditionally, because on non-darwin platforms the language is probably not available. Introduce the qt_enable_cmake_languages() macro which is called automatically by qt_build_repo_begin(). Change-Id: I0e7f44be6577ac54ce940470036626409920e272 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-03 12:23:18 +00:00
qt_enable_cmake_languages()
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
CMake: Generate and use a wrapper script for stripping binaries MinGW 11.2.0 comes with a strip.exe that strips the ".gnu_debuglink" section in binaries, a section that is needed for the separate debug information feature. binutils version 2.34 mentions the feature for the first time: https://sourceware.org/binutils/docs-2.34/binutils/strip.html#strip To ensure the debuglink section is preserved, generate a shell wrapper that calls the original strip binary with an extra option to keep the required section. To determine if the option is supported, we build a real shared library on which strip will be called with the --keep-section option. If the option is not supported, a wrapper is not generated and the stock strip binary is used. This logic only applies when targeting Linux and MinGW + a shared library Qt. For other targets, the stock strip binary is used. Developers can opt out of this logic by passing -DQT_NO_STRIP_WRAPPER=TRUE when configuring each Qt repo. Pick-to: 6.2 6.3 Fixes: QTBUG-101653 Change-Id: Idd213d48d087d3c9600c853362aebaba348cde33 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-21 15:33:56 +00:00
qt_internal_generate_binary_strip_wrapper()
CMake: Add global / top-level docs targets Previously you could use either module-specific or repo-specific 'docs' targets. For example 'ninja html_docs_qtbase' or 'ninja html_docs_Core'. Now there's a global / top-level target called 'docs', so 'ninja docs' works. For super builds it will build the documentation of all configured repositories. For a single repo build, it's equivalent to calling 'ninja docs_repo_name'. Also for consistency, add the "docs_Core" target, which was missing before. So now a 'docs' target exsits for repo names AND targets. New global target names are - docs - prepare_docs - generate_docs - html_docs - qch_docs - install_html_docs_docs - install_qch_docs_docs - install_docs_docs Amends 0095ff4e0659906595d281b37c3b7f89e37250af Change-Id: I686be1e0962e40cbce860e8ac2cabb056b360ac2 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-18 15:07:44 +00:00
# Add global docs targets that will work both for per-repo builds, and super builds.
if(NOT TARGET docs)
add_custom_target(docs)
add_custom_target(prepare_docs)
add_custom_target(generate_docs)
add_custom_target(html_docs)
add_custom_target(qch_docs)
CMake: Re-work documentation targets The top-level prepare_docs target is supposed to run before the generate_docs target. The repository-level targets like prepare_docs_qtbase now also run before their respective generate targets. To achieve that, several intermediate targets had to be introduced. The dependencies for top-level generate_docs look like this: /--> generate_top_level_docs_Core --\ generate_docs ---> generate_top_level_docs_Gui -----> prepare_docs \--> ... --/ The dependencies for repo-level generate_docs_<repo> look like this: /--> generate_repo_docs_Core generate_docs_qtbase ---> generate_repo_docs_Gui \--> ... generate_repo_docs_Core --\ generate_repo_docs_Gui -----> prepare_docs_qtbase ... --/ Analoguous for qch_docs. And last but not least, the module-level generate_docs_<module> depends on prepare_docs_<module>, just like before. The strangely named top-level install targets have been renamed to install_html_docs, install_qch_docs and install_docs. The html_docs target is now merely an alias for generate_docs. Apart from prepare_docs, the top-level targets do not depend on the repository-level targets anymore. Targets that are just an alias (docs, install_docs, ...) have been re-defined to depend just on the respective top-level targets. Fixes: QTBUG-87758 Change-Id: I24466d3a252d518a30a2064bf876be881c46231f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-27 09:35:07 +00:00
add_custom_target(install_html_docs)
add_custom_target(install_qch_docs)
add_custom_target(install_docs)
add_dependencies(html_docs generate_docs)
add_dependencies(docs html_docs qch_docs)
add_dependencies(install_docs install_html_docs install_qch_docs)
CMake: Add global / top-level docs targets Previously you could use either module-specific or repo-specific 'docs' targets. For example 'ninja html_docs_qtbase' or 'ninja html_docs_Core'. Now there's a global / top-level target called 'docs', so 'ninja docs' works. For super builds it will build the documentation of all configured repositories. For a single repo build, it's equivalent to calling 'ninja docs_repo_name'. Also for consistency, add the "docs_Core" target, which was missing before. So now a 'docs' target exsits for repo names AND targets. New global target names are - docs - prepare_docs - generate_docs - html_docs - qch_docs - install_html_docs_docs - install_qch_docs_docs - install_docs_docs Amends 0095ff4e0659906595d281b37c3b7f89e37250af Change-Id: I686be1e0962e40cbce860e8ac2cabb056b360ac2 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-18 15:07:44 +00:00
endif()
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
Replace the syncqt.pl script with syncqt tool syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-15 16:29:41 +00:00
if(NOT TARGET sync_headers)
add_custom_target(sync_headers)
endif()
Fix external header support in qtsync We should sync external headers for 3rdpary projects like freetype and harfbuzz-ng and keep the directory structure. Fixes: QTBUG-113416 Pick-to: 6.6 6.5 Change-Id: Ie66edb9a21cff37ca6c8c68b6d225de6d8bbad81 Reviewed-by: Michal Klocek <michal.klocek@qt.io>
2023-06-08 14:20:47 +00:00
# The special target that we use to sync 3rd-party headers before the gn run when building
# qtwebengine in top-level builds.
if(NOT TARGET thirdparty_sync_headers)
add_custom_target(thirdparty_sync_headers)
endif()
CMake: Add convenience custom targets to build Qt plugins Add 3 new convenience custom targets: 'qt_plugins', 'qpa_plugins' and 'qpa_default_plugins'. Additionally, if we detect that an internal executable / test links against Gui, add a dependency on the 'qpa_default_plugins' custom target, so that if a developer configures Qt for the first time and then calls ninja 'tst_foo_check', we ensure the test will launch successfully because the default QPA plugin will also be built. Change-Id: If6dd70844b5effdf8a293f65f8785855cc85b132 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-19 17:34:53 +00:00
# Add global qt_plugins, qpa_plugins and qpa_default_plugins convenience custom targets.
# Internal executables will add a dependency on the qpa_default_plugins target,
# so that building and running a test ensures it won't fail at runtime due to a missing qpa
# plugin.
if(NOT TARGET qt_plugins)
add_custom_target(qt_plugins)
add_custom_target(qpa_plugins)
add_custom_target(qpa_default_plugins)
endif()
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
string(TOLOWER ${PROJECT_NAME} project_name_lower)
CMake: Relax example dependencies to be per-repo When doing a top-level build with ExternalProject examples, it doesn't make sense to make qtbase examples depend on e.g. qtdeclarative plugins. Instead the qtbase example should only depend on plugins built in qtbase. Create per-repo custom targets that depend on all plugins built within that particular repo. Create an additional per-repo target which depends on all plugins built in that repo, as well as plugins from dependent repos. Use the latter as a dependency for examples built as part of the current repo. Repo dependencies are parsed from dependencies.yaml. Pick-to: 6.5 Fixes: QTBUG-110913 Change-Id: I149860cc549caf53271c9ea296eb7bac2a663715 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-02-06 15:51:40 +00:00
# Target to build all plugins that are part of the current repo.
set(qt_repo_plugins "qt_plugins_${project_name_lower}")
if(NOT TARGET ${qt_repo_plugins})
add_custom_target(${qt_repo_plugins})
endif()
# Target to build all plugins that are part of the current repo and the current repo's
# dependencies plugins. Used for external project example dependencies.
set(qt_repo_plugins_recursive "${qt_repo_plugins}_recursive")
if(NOT TARGET ${qt_repo_plugins_recursive})
add_custom_target(${qt_repo_plugins_recursive})
add_dependencies(${qt_repo_plugins_recursive} "${qt_repo_plugins}")
endif()
qt_internal_read_repo_dependencies(qt_repo_deps "${PROJECT_SOURCE_DIR}")
if(qt_repo_deps)
foreach(qt_repo_dep IN LISTS qt_repo_deps)
if(TARGET qt_plugins_${qt_repo_dep})
message(DEBUG
"${qt_repo_plugins_recursive} depends on qt_plugins_${qt_repo_dep}")
add_dependencies(${qt_repo_plugins_recursive} "qt_plugins_${qt_repo_dep}")
endif()
endforeach()
endif()
Toplevel builds: Add utility toplevel targets for each module Add a target for each level-1 subdirectory in a module. Ninja already generates phony targets such as "qtbase/src/all", but those are not available in e.g. IDE integrations of CMake. With this addition, targets like qtbase, qtbase_src, and qtbase_tests are available in IDEs. Pick-to: 6.0 6.0.0 Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-17 23:36:44 +00:00
set(qt_repo_targets_name ${project_name_lower})
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
set(qt_docs_target_name docs_${project_name_lower})
set(qt_docs_prepare_target_name prepare_docs_${project_name_lower})
set(qt_docs_generate_target_name generate_docs_${project_name_lower})
set(qt_docs_html_target_name html_docs_${project_name_lower})
set(qt_docs_qch_target_name qch_docs_${project_name_lower})
set(qt_docs_install_html_target_name install_html_docs_${project_name_lower})
set(qt_docs_install_qch_target_name install_qch_docs_${project_name_lower})
set(qt_docs_install_target_name install_docs_${project_name_lower})
add_custom_target(${qt_docs_target_name})
add_custom_target(${qt_docs_prepare_target_name})
add_custom_target(${qt_docs_generate_target_name})
add_custom_target(${qt_docs_qch_target_name})
add_custom_target(${qt_docs_html_target_name})
add_custom_target(${qt_docs_install_html_target_name})
add_custom_target(${qt_docs_install_qch_target_name})
add_custom_target(${qt_docs_install_target_name})
add_dependencies(${qt_docs_generate_target_name} ${qt_docs_prepare_target_name})
add_dependencies(${qt_docs_html_target_name} ${qt_docs_generate_target_name})
CMake: Re-work documentation targets The top-level prepare_docs target is supposed to run before the generate_docs target. The repository-level targets like prepare_docs_qtbase now also run before their respective generate targets. To achieve that, several intermediate targets had to be introduced. The dependencies for top-level generate_docs look like this: /--> generate_top_level_docs_Core --\ generate_docs ---> generate_top_level_docs_Gui -----> prepare_docs \--> ... --/ The dependencies for repo-level generate_docs_<repo> look like this: /--> generate_repo_docs_Core generate_docs_qtbase ---> generate_repo_docs_Gui \--> ... generate_repo_docs_Core --\ generate_repo_docs_Gui -----> prepare_docs_qtbase ... --/ Analoguous for qch_docs. And last but not least, the module-level generate_docs_<module> depends on prepare_docs_<module>, just like before. The strangely named top-level install targets have been renamed to install_html_docs, install_qch_docs and install_docs. The html_docs target is now merely an alias for generate_docs. Apart from prepare_docs, the top-level targets do not depend on the repository-level targets anymore. Targets that are just an alias (docs, install_docs, ...) have been re-defined to depend just on the respective top-level targets. Fixes: QTBUG-87758 Change-Id: I24466d3a252d518a30a2064bf876be881c46231f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-27 09:35:07 +00:00
add_dependencies(${qt_docs_target_name} ${qt_docs_html_target_name} ${qt_docs_qch_target_name})
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
add_dependencies(${qt_docs_install_target_name} ${qt_docs_install_html_target_name} ${qt_docs_install_qch_target_name})
CMake: Add global / top-level docs targets Previously you could use either module-specific or repo-specific 'docs' targets. For example 'ninja html_docs_qtbase' or 'ninja html_docs_Core'. Now there's a global / top-level target called 'docs', so 'ninja docs' works. For super builds it will build the documentation of all configured repositories. For a single repo build, it's equivalent to calling 'ninja docs_repo_name'. Also for consistency, add the "docs_Core" target, which was missing before. So now a 'docs' target exsits for repo names AND targets. New global target names are - docs - prepare_docs - generate_docs - html_docs - qch_docs - install_html_docs_docs - install_qch_docs_docs - install_docs_docs Amends 0095ff4e0659906595d281b37c3b7f89e37250af Change-Id: I686be1e0962e40cbce860e8ac2cabb056b360ac2 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-18 15:07:44 +00:00
CMake: Re-work documentation targets The top-level prepare_docs target is supposed to run before the generate_docs target. The repository-level targets like prepare_docs_qtbase now also run before their respective generate targets. To achieve that, several intermediate targets had to be introduced. The dependencies for top-level generate_docs look like this: /--> generate_top_level_docs_Core --\ generate_docs ---> generate_top_level_docs_Gui -----> prepare_docs \--> ... --/ The dependencies for repo-level generate_docs_<repo> look like this: /--> generate_repo_docs_Core generate_docs_qtbase ---> generate_repo_docs_Gui \--> ... generate_repo_docs_Core --\ generate_repo_docs_Gui -----> prepare_docs_qtbase ... --/ Analoguous for qch_docs. And last but not least, the module-level generate_docs_<module> depends on prepare_docs_<module>, just like before. The strangely named top-level install targets have been renamed to install_html_docs, install_qch_docs and install_docs. The html_docs target is now merely an alias for generate_docs. Apart from prepare_docs, the top-level targets do not depend on the repository-level targets anymore. Targets that are just an alias (docs, install_docs, ...) have been re-defined to depend just on the respective top-level targets. Fixes: QTBUG-87758 Change-Id: I24466d3a252d518a30a2064bf876be881c46231f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-27 09:35:07 +00:00
# Make top-level prepare_docs target depend on the repository-level prepare_docs_<repo> target.
CMake: Add global / top-level docs targets Previously you could use either module-specific or repo-specific 'docs' targets. For example 'ninja html_docs_qtbase' or 'ninja html_docs_Core'. Now there's a global / top-level target called 'docs', so 'ninja docs' works. For super builds it will build the documentation of all configured repositories. For a single repo build, it's equivalent to calling 'ninja docs_repo_name'. Also for consistency, add the "docs_Core" target, which was missing before. So now a 'docs' target exsits for repo names AND targets. New global target names are - docs - prepare_docs - generate_docs - html_docs - qch_docs - install_html_docs_docs - install_qch_docs_docs - install_docs_docs Amends 0095ff4e0659906595d281b37c3b7f89e37250af Change-Id: I686be1e0962e40cbce860e8ac2cabb056b360ac2 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-18 15:07:44 +00:00
add_dependencies(prepare_docs ${qt_docs_prepare_target_name})
CMake: Add meta-target host_tools to easily build just the tools A developer could write 'ninja host_tools' to build the qtbase tools and their dependencies, and then configure another cross-compiling build dir pointing to the previous host build. This shortens the workflow for cross-building when working in qtbase. Change-Id: I69e70d23ce9df8669bcadf326d0586f097e5cb21 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-06-26 13:06:00 +00:00
CMake: Fix top-level documentation install targets The following targets did not do any actual installation: install_docs, install_html_docs, install_qch_docs, plus their repository-level counterparts. Add the following dependencies: install_html_docs --> install_html_docs_<repo> --> install_html_docs_<module> Analogous for qch. The install_docs target already triggers install_html_docs and install_qch_docs. Analogous for install_docs_<repo>. Fixes: QTBUG-86738 Change-Id: I3468e000e050e2787a859e61d40161f5459cb351 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-05 09:32:30 +00:00
# Make top-level install_*_docs targets depend on the repository-level install_*_docs targets.
add_dependencies(install_html_docs ${qt_docs_install_html_target_name})
add_dependencies(install_qch_docs ${qt_docs_install_qch_target_name})
CMake: Add meta-target host_tools to easily build just the tools A developer could write 'ninja host_tools' to build the qtbase tools and their dependencies, and then configure another cross-compiling build dir pointing to the previous host build. This shortens the workflow for cross-building when working in qtbase. Change-Id: I69e70d23ce9df8669bcadf326d0586f097e5cb21 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-06-26 13:06:00 +00:00
# Add host_tools meta target, so that developrs can easily build only tools and their
# dependencies when working in qtbase.
if(NOT TARGET host_tools)
add_custom_target(host_tools)
add_custom_target(bootstrap_tools)
endif()
CMake: Add extra targets to run single benchmark using CMake generator Add custom targets with '_benchmark' suffixes to make run of benchmarks using generators possible, e.g.: $ ninja tst_bench_qudpsocket_benchmark Extend '-[no]make' option to pass benchmark. Rework '-[no]make' processing to unify these options processing. Also looks like it doesn't make sense to enable benchmarks without having test enabled. So '-DQT_BUILD_BENCHMARKS' enables test as own dependency automatically. Task-number: QTBUG-89076 Pick-to: 6.0 Change-Id: Ieee9eadaf6d75a1efec120242d6eb786ace1b071 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-03 18:13:08 +00:00
# Add benchmark meta target. It's collection of all benchmarks added/registered by
# 'qt_internal_add_benchmark' helper.
if(NOT TARGET benchmark)
add_custom_target(benchmark)
endif()
Replace the syncqt.pl script with syncqt tool syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-15 16:29:41 +00:00
if(QT_INTERNAL_SYNCED_MODULES)
set_property(GLOBAL PROPERTY _qt_synced_modules ${QT_INTERNAL_SYNCED_MODULES})
endif()
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 11:57:15 +00:00
endmacro()
CMake: Fix find_package(Qt6*Tools) in non-qtbase tests Tests in non-qtbase modules could not find_package their own Qt6*Tools packages, because add_subdirectory(tests) was called before the config files for Qt6*Tools were created. The creation of tools config files is done in QtPostProcess.cmake, which was included in qt_build_repo_end(). Move that include into its own macro, qt_build_repo_post_process() and remove it from qt_build_repo_end(). Call qt_build_repo_post_process() before the 'tests' directory is added in qt_build_repo(). Every call site of qt_build_repo_end() must now be adjusted and call qt_build_repo_post_process(). Task-number: QTBUG-88264 Change-Id: I80d60a1b5c0e9b715c298ef4934b562f815432d1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-18 13:48:21 +00:00
# Runs delayed actions on some of the Qt targets.
# Can be called either explicitly or as part of qt_build_repo_end().
macro(qt_build_repo_post_process)
CMake: Fix early exit in qt_build_repo_post_process() This is a macro. We cannot use return() here or we're skipping code at the call site. This commit amends b6849849392cf14ead014833976d1926504985d2. Task-number: QTBUG-88264 Change-Id: Icf6dd06338584239873bf4d66a4bbceef9071399 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
2023-08-24 09:32:53 +00:00
if(NOT QT_INTERNAL_REPO_POST_PROCESS_CALLED)
set(QT_INTERNAL_REPO_POST_PROCESS_CALLED TRUE)
if(NOT QT_BUILD_STANDALONE_TESTS)
include(QtPostProcess)
endif()
CMake: Fix find_package(Qt6*Tools) in non-qtbase tests Tests in non-qtbase modules could not find_package their own Qt6*Tools packages, because add_subdirectory(tests) was called before the config files for Qt6*Tools were created. The creation of tools config files is done in QtPostProcess.cmake, which was included in qt_build_repo_end(). Move that include into its own macro, qt_build_repo_post_process() and remove it from qt_build_repo_end(). Call qt_build_repo_post_process() before the 'tests' directory is added in qt_build_repo(). Every call site of qt_build_repo_end() must now be adjusted and call qt_build_repo_post_process(). Task-number: QTBUG-88264 Change-Id: I80d60a1b5c0e9b715c298ef4934b562f815432d1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-18 13:48:21 +00:00
endif()
endmacro()
macro(qt_build_repo_end)
if(NOT QT_BUILD_STANDALONE_TESTS)
qt_build_repo_post_process()
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
# Install the repo-specific cmake find modules.
qt_path_join(__qt_repo_install_dir ${QT_CONFIG_INSTALL_DIR} ${INSTALL_CMAKE_NAMESPACE})
Copy Find*.cmake to ${QT_BUILD_DIR}/lib/cmake/Qt6 In top-level builds, when configuring qtsensors, the directory of FindWMF.cmake isn't in ${CMAKE_MODULE_PATH}, this makes CMake couldn't find WMF. On Windows, QtMultimedia requires WMF. If WMF couldn't be found, QtMultimedia will also be treated as NOT FOUND. QtSensors has an optional dependency to QtMultimedia. If QtMultimedia couldn't be found, CMake will warn. Copy Find*.cmake to ${QT_BUILD_DIR}/lib/cmake/Qt6, to make sure these files could be found by CMake. Fixes: QTBUG-95655 Pick-to: 6.2 Change-Id: I87d14c9a7becd0ec493e00c297b2e01fc0ad0f96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-10 13:19:53 +00:00
qt_path_join(__qt_repo_build_dir ${QT_CONFIG_BUILD_DIR} ${INSTALL_CMAKE_NAMESPACE})
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 PROJECT_NAME STREQUAL "QtBase")
Fix installation of Find*.cmake files in shadow per-repo builds In shadow per-repo builds we never hit the code that is supposed to install cmake/Find*.cmake files. This caused problems when statically building a Qt repo like qtshadertools against qtimageformats which provides such Find*.cmake files. Fixes: QTBUG-91538 Change-Id: I1147daee817ac71303d93e8bf368b2769afb0bb4 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-16 14:13:15 +00:00
if(IS_DIRECTORY "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
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_copy_or_install(DIRECTORY cmake/
DESTINATION "${__qt_repo_install_dir}"
FILES_MATCHING PATTERN "Find*.cmake"
)
Copy Find*.cmake to ${QT_BUILD_DIR}/lib/cmake/Qt6 In top-level builds, when configuring qtsensors, the directory of FindWMF.cmake isn't in ${CMAKE_MODULE_PATH}, this makes CMake couldn't find WMF. On Windows, QtMultimedia requires WMF. If WMF couldn't be found, QtMultimedia will also be treated as NOT FOUND. QtSensors has an optional dependency to QtMultimedia. If QtMultimedia couldn't be found, CMake will warn. Copy Find*.cmake to ${QT_BUILD_DIR}/lib/cmake/Qt6, to make sure these files could be found by CMake. Fixes: QTBUG-95655 Pick-to: 6.2 Change-Id: I87d14c9a7becd0ec493e00c297b2e01fc0ad0f96 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-10 13:19:53 +00:00
if(QT_SUPERBUILD AND QT_WILL_INSTALL)
file(COPY cmake/
DESTINATION "${__qt_repo_build_dir}"
FILES_MATCHING PATTERN "Find*.cmake"
)
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
endif()
cmake/ does not necessarily exist in a module E.g. qtsvg does not have a cmake/ folder Change-Id: I216776a4997709222064aa76195a32e7bdb6b080 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-05 14:26:42 +00:00
endif()
Automatically install repo specific cmake find modules Some qt modules need to find 3rd party packages for which there are no Config files. We need to write custom CMake Find modules to find those packages. These find modules need to be installed so that they are used when a user consumes the Qt packages. Automatically include and install these find modules if they exist, as part of qt_build_repo_end(). Change-Id: I14aad35ed2999cac8bdda65ca4aeaf74d04fdb71 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io>
2019-05-20 07:46:38 +00:00
Implement qtbase fixes for superbuilds Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-11-21 12:33:28 +00:00
if(NOT QT_SUPERBUILD)
qt_print_feature_summary()
endif()
Print build instructions when configuring qtbase This is similar to how we show the instructions when configuring in qmake land. Change-Id: Iabd28acc3d74fd0175eab812a412744dac89e6f6 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-17 14:05:50 +00:00
endif()
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
qt_build_internals_add_toplevel_targets()
Implement qtbase fixes for superbuilds Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-11-21 12:33:28 +00:00
if(NOT QT_SUPERBUILD)
qt_print_build_instructions()
Print build instructions when configuring qtbase This is similar to how we show the instructions when configuring in qmake land. Change-Id: Iabd28acc3d74fd0175eab812a412744dac89e6f6 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-17 14:05:50 +00:00
endif()
Replace the syncqt.pl script with syncqt tool syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-15 16:29:41 +00:00
get_property(synced_modules GLOBAL PROPERTY _qt_synced_modules)
if(synced_modules)
set(QT_INTERNAL_SYNCED_MODULES ${synced_modules} CACHE INTERNAL
"List of the synced modules. Prevents running syncqt.cpp after the first configuring.")
endif()
Use CMAKE_MESSAGE_CONTEXT for Better CMake Output Messages Each module now identifies its actions during the configuration by a prefix, e.g., `[QtBase]`. In addition, - I have slightly modified some of the `message()` commands to get a more coherent output. - `syncqt.cpp` prints its output as WARNING if any Change-Id: I3922d75a668d94f402068f4121751b7fcb6522b4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-10-25 14:48:21 +00:00
CMake: Reconfigure faster by not looking for missing packages Instead of constantly trying to find packages by calling qt_find_package on each reconfiguration, record which packages were found during initial configuration. Then on a second reconfiguration, skip looking for packages that were not found on the initial configuration. This speeds up reconfiguration on certain platforms and repos. Here are some stats for my macOS qtbase build. not skip 3.69s user 4.96s system 98% cpu 8.750 total skip 2.69s user 1.00s system 97% cpu 3.792 total Top-level build with -submodules=qtquick3d not skip 15.03s user 10.58s system 97% cpu 26.334 total skip 13.87s user 5.16s system 96% cpu 19.724 total Note this is a behavior change from how find_package is used in most CMake projects, where if a package was previously missing, the developer can just install the package and reconfigure to pick it up. With this change, they will first have to remove their CMakeCache.txt file and configure from scratch, or remove the QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES cache variable and reconfigure. For this reason, we enable this behavior by default only in -developer-builds. Builders can also opt in or out by setting the QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES variable to either ON or OFF. Note this behavior does not apply to user projects, or direct find_package calls (as opposed to qt_find_package). Fixes: QTBUG-107251 Change-Id: Iee9c5d120eb09e2a94eebb059a2174ef6b241e03 Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-09-27 16:20:49 +00:00
if(NOT QT_SUPERBUILD)
Add the list of previously searched packages to qt_find_package When configuring Qt the second time it might be situation that the set of qt_find_package calls is changed. One of the scenarios is the changing of the submodule list that needs to be built in top-level builds. It's also applicable for Qt features that lead to extra package lookup in the unlocked subdirectories. Current approach collects packages that were found at the previous run and skips search of the packages that are missing. The problem is that it also skips packages even if qt_find_package was not called at previous run. QT_INTERNAL_PREVIOUSLY_SEARCHED_PACKAGES collects all packages that were actually searched at the previous run to make sure that qt_find_package don't skip packages that appeared at second run only. Note: Described scenarios may still have other issues and are not tested well. Fixes: QTBUG-113244 Pick-to: 6.5 Change-Id: Iab36060a28fbaa16a3b3bdba67795955c496b0c3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
2023-04-28 15:27:48 +00:00
qt_internal_save_previously_visited_packages()
CMake: Reconfigure faster by not looking for missing packages Instead of constantly trying to find packages by calling qt_find_package on each reconfiguration, record which packages were found during initial configuration. Then on a second reconfiguration, skip looking for packages that were not found on the initial configuration. This speeds up reconfiguration on certain platforms and repos. Here are some stats for my macOS qtbase build. not skip 3.69s user 4.96s system 98% cpu 8.750 total skip 2.69s user 1.00s system 97% cpu 3.792 total Top-level build with -submodules=qtquick3d not skip 15.03s user 10.58s system 97% cpu 26.334 total skip 13.87s user 5.16s system 96% cpu 19.724 total Note this is a behavior change from how find_package is used in most CMake projects, where if a package was previously missing, the developer can just install the package and reconfigure to pick it up. With this change, they will first have to remove their CMakeCache.txt file and configure from scratch, or remove the QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES cache variable and reconfigure. For this reason, we enable this behavior by default only in -developer-builds. Builders can also opt in or out by setting the QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES variable to either ON or OFF. Note this behavior does not apply to user projects, or direct find_package calls (as opposed to qt_find_package). Fixes: QTBUG-107251 Change-Id: Iee9c5d120eb09e2a94eebb059a2174ef6b241e03 Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-09-27 16:20:49 +00:00
endif()
Update -redo option such that it removes CMakeCache.txt and CMakeFiles/ In the case of re-doing, `configure` and `configure.bat` pass an extra parameter to the `QtProcessConfigureArgs.cmake`. As a result, CMake removes CMakeCache.txt and CMakeFiles/ before the reconfiguration. If the user is using CMake 3.24 or newer, this is achieved by passing the `--fresh` option to CMake call. In older CMake(s), CMakeCache.txt and CMakeFiles/ found in CMAKE_BINARY_DIR will be removed using a file(REMOVE_RECURSIVE call. [ChangeLog] The -redo option now additionally removes existing CMakeCache.txt file, and CMakeFiles/ directory, and recreates them from scratch. Task-number: QTBUG-108287 Change-Id: I11a5c8f9df1247d11eb7097552e6764463583346 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-11-11 13:48:57 +00:00
if(QT_INTERNAL_FRESH_REQUESTED)
set(QT_INTERNAL_FRESH_REQUESTED "FALSE" CACHE INTERNAL "")
endif()
CMake: Rework INPUT_foo vars handling when reconfiguring To be able to reconfigure Qt with modified feature values using the configure script, and take into account INPUT_foo values, we need to ignore FEATURE_foo values. But we can't always ignore FEATURE_foo values, because users might want to toggle them by editing CMakeCache.txt or using an IDE. What we can do is tell CMake we are configuring via the configure script, in which case we can mostly be sure that any passed INPUT_foo values should have higher priority than pre-cached FEATURE_foo values. We also need to remove all the cached INPUT_foo variables after they have been used for feature computation, so that subsequent reconfigurations where an INPUT_foo is not passed anymore, doesn't cause a feature to accidentally reuse the previous (stale) value. Pass -DQT_INTERNAL_CALLED_FROM_CONFIGURE=TRUE to CMake when configuring via the configure script, and use that as a marker to make INPUT_foo values have a higher priority. This needs to be done centrally in qt_evaluate_feature and also in a few more locations where we check INPUT_ values, like the developer build and pkgconfig features. Because QT_INTERNAL_CALLED_FROM_CONFIGURE would become a cached variable, we want to remove it at the end of the configuration phase, so that future 'cmake .' reconfigurations are not considered to be done via configure. To do that, we unset it right at the end of qt_build_repo_end in a per-repo build, and in the final qt_print_build_instructions call in a top-level build. The latter needs a cleaner fix in follow up commits in qt5.git and qtbase. Pick-to: 6.6 Task-number: QTBUG-112957 Change-Id: I3fd338092041ef09e3f5a4dfbaf61da5deea0514 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-25 15:32:19 +00:00
if(NOT QT_SUPERBUILD)
qt_internal_qt_configure_end()
endif()
Use CMAKE_MESSAGE_CONTEXT for Better CMake Output Messages Each module now identifies its actions during the configuration by a prefix, e.g., `[QtBase]`. In addition, - I have slightly modified some of the `message()` commands to get a more coherent output. - `syncqt.cpp` prints its output as WARNING if any Change-Id: I3922d75a668d94f402068f4121751b7fcb6522b4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-10-25 14:48:21 +00:00
list(POP_BACK CMAKE_MESSAGE_CONTEXT)
Implement qtbase fixes for superbuilds Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-11-21 12:33:28 +00:00
endmacro()
Print build instructions when configuring qtbase This is similar to how we show the instructions when configuring in qmake land. Change-Id: Iabd28acc3d74fd0175eab812a412744dac89e6f6 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-17 14:05:50 +00:00
CMake: Rework INPUT_foo vars handling when reconfiguring To be able to reconfigure Qt with modified feature values using the configure script, and take into account INPUT_foo values, we need to ignore FEATURE_foo values. But we can't always ignore FEATURE_foo values, because users might want to toggle them by editing CMakeCache.txt or using an IDE. What we can do is tell CMake we are configuring via the configure script, in which case we can mostly be sure that any passed INPUT_foo values should have higher priority than pre-cached FEATURE_foo values. We also need to remove all the cached INPUT_foo variables after they have been used for feature computation, so that subsequent reconfigurations where an INPUT_foo is not passed anymore, doesn't cause a feature to accidentally reuse the previous (stale) value. Pass -DQT_INTERNAL_CALLED_FROM_CONFIGURE=TRUE to CMake when configuring via the configure script, and use that as a marker to make INPUT_foo values have a higher priority. This needs to be done centrally in qt_evaluate_feature and also in a few more locations where we check INPUT_ values, like the developer build and pkgconfig features. Because QT_INTERNAL_CALLED_FROM_CONFIGURE would become a cached variable, we want to remove it at the end of the configuration phase, so that future 'cmake .' reconfigurations are not considered to be done via configure. To do that, we unset it right at the end of qt_build_repo_end in a per-repo build, and in the final qt_print_build_instructions call in a top-level build. The latter needs a cleaner fix in follow up commits in qt5.git and qtbase. Pick-to: 6.6 Task-number: QTBUG-112957 Change-Id: I3fd338092041ef09e3f5a4dfbaf61da5deea0514 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-25 15:32:19 +00:00
# Function called either at the end of per-repo configuration, or at the end of configuration of
# a super build.
# At the moment it is called before examples are configured in a per-repo build. We might want
# to change that at some point if needed.
function(qt_internal_qt_configure_end)
# If Qt is configued via the configure script, remove the marker variable, so that any future
# reconfigurations that are done by calling cmake directly don't trigger configure specific
# logic.
unset(QT_INTERNAL_CALLED_FROM_CONFIGURE CACHE)
endfunction()
Simplify top-level CMakeLists.txt for modules Implement some aspects of qt_parts.prf to simplify the top-level CMakeLists.txt for repositories that follow the common qt structure (src, tools, tests, examples). Change-Id: Ia35f4e9207e92c1cf0406353561b0cc52dcb0e59 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-21 07:04:27 +00:00
macro(qt_build_repo)
qt_build_repo_begin(${ARGN})
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
qt_build_repo_impl_find_package_tests()
qt_build_repo_impl_src()
qt_build_repo_impl_tools()
CMake: Fix find_package(Qt6*Tools) in non-qtbase tests Tests in non-qtbase modules could not find_package their own Qt6*Tools packages, because add_subdirectory(tests) was called before the config files for Qt6*Tools were created. The creation of tools config files is done in QtPostProcess.cmake, which was included in qt_build_repo_end(). Move that include into its own macro, qt_build_repo_post_process() and remove it from qt_build_repo_end(). Call qt_build_repo_post_process() before the 'tests' directory is added in qt_build_repo(). Every call site of qt_build_repo_end() must now be adjusted and call qt_build_repo_post_process(). Task-number: QTBUG-88264 Change-Id: I80d60a1b5c0e9b715c298ef4934b562f815432d1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-18 13:48:21 +00:00
qt_build_repo_post_process()
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
qt_build_repo_impl_tests()
qt_build_repo_end()
qt_build_repo_impl_examples()
endmacro()
macro(qt_build_repo_impl_find_package_tests)
Try to find Test package before calling add_subdirectory(src) in qt_build_repo(). This is important for qtdeclarative for example, which builds QmlTest functionality in ./src, and thus needs Test lib to be available. Change-Id: I84326d79844526f2f177c19de30bab0c858773e3 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-13 13:35:26 +00:00
# If testing is enabled, try to find the qtbase Test package.
# Do this before adding src, because there might be test related conditions
# in source.
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 AND NOT QT_BUILD_STANDALONE_TESTS)
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
# When looking for the Test package, do it using the Qt6 package version, in case if
# PROJECT_VERSION is following a different versioning scheme.
if(Qt6_VERSION)
set(_qt_build_repo_impl_find_package_tests_version "${Qt6_VERSION}")
else()
set(_qt_build_repo_impl_find_package_tests_version "${PROJECT_VERSION}")
endif()
find_package(Qt6
"${_qt_build_repo_impl_find_package_tests_version}"
CONFIG REQUIRED COMPONENTS Test)
unset(_qt_build_repo_impl_find_package_tests_version)
Try to find Test package before calling add_subdirectory(src) in qt_build_repo(). This is important for qtdeclarative for example, which builds QmlTest functionality in ./src, and thus needs Test lib to be available. Change-Id: I84326d79844526f2f177c19de30bab0c858773e3 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-13 13:35:26 +00:00
endif()
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
endmacro()
Try to find Test package before calling add_subdirectory(src) in qt_build_repo(). This is important for qtdeclarative for example, which builds QmlTest functionality in ./src, and thus needs Test lib to be available. Change-Id: I84326d79844526f2f177c19de30bab0c858773e3 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-13 13:35:26 +00:00
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
macro(qt_build_repo_impl_src)
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)
if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/src/CMakeLists.txt")
add_subdirectory(src)
endif()
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
endif()
Add find package for lttng library so that it gets added to target Add it globally so that each module using tracepoints don't have to add it themselves to each modules configure.cmake. Pick-to: 6.5 Change-Id: Id58cfaff5cd715b2667da2470001d646117f9f28 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-11-17 07:06:45 +00:00
if(QT_FEATURE_lttng AND NOT TARGET LTTng::UST)
qt_find_package(LTTngUST PROVIDED_TARGETS LTTng::UST
MODULE_NAME global QMAKE_LIB lttng-ust)
endif()
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
endmacro()
Simplify top-level CMakeLists.txt for modules Implement some aspects of qt_parts.prf to simplify the top-level CMakeLists.txt for repositories that follow the common qt structure (src, tools, tests, examples). Change-Id: Ia35f4e9207e92c1cf0406353561b0cc52dcb0e59 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-21 07:04:27 +00:00
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
macro(qt_build_repo_impl_tools)
if(NOT QT_BUILD_STANDALONE_TESTS)
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 (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/tools/CMakeLists.txt")
add_subdirectory(tools)
endif()
Change qt_build_repo to build tools if present and needed This is needed for qtdeclarative, to automatically start building the tools if needed. Change-Id: I3cbe129e8bb6fa8572a8e34fd3653b51727cb244 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-05 14:10:59 +00:00
endif()
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
endmacro()
Change qt_build_repo to build tools if present and needed This is needed for qtdeclarative, to automatically start building the tools if needed. Change-Id: I3cbe129e8bb6fa8572a8e34fd3653b51727cb244 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-05 14:10:59 +00:00
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
macro(qt_build_repo_impl_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 (QT_BUILD_TESTS AND EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/tests/CMakeLists.txt")
Simplify top-level CMakeLists.txt for modules Implement some aspects of qt_parts.prf to simplify the top-level CMakeLists.txt for repositories that follow the common qt structure (src, tools, tests, examples). Change-Id: Ia35f4e9207e92c1cf0406353561b0cc52dcb0e59 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-21 07:04: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()
Simplify top-level CMakeLists.txt for modules Implement some aspects of qt_parts.prf to simplify the top-level CMakeLists.txt for repositories that follow the common qt structure (src, tools, tests, examples). Change-Id: Ia35f4e9207e92c1cf0406353561b0cc52dcb0e59 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-21 07:04:27 +00:00
endif()
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
endmacro()
Simplify top-level CMakeLists.txt for modules Implement some aspects of qt_parts.prf to simplify the top-level CMakeLists.txt for repositories that follow the common qt structure (src, tools, tests, examples). Change-Id: Ia35f4e9207e92c1cf0406353561b0cc52dcb0e59 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-21 07:04:27 +00:00
CMake: Split qt_repo_build() into reusable macros Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 13:21:44 +00:00
macro(qt_build_repo_impl_examples)
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
if(QT_BUILD_EXAMPLES
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
AND EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/examples/CMakeLists.txt"
AND NOT QT_BUILD_STANDALONE_TESTS)
CMake: Show a message when configuring examples This somewhat indicates the progress of configuring a specific repo and the slower period of time when configuring examples in-tree. Pick-to: 6.5 Change-Id: I643536c4ebc865933730b7af2a1d0c56bbbf2912 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-02-06 16:02:13 +00:00
message(STATUS "Configuring examples.")
Fix qt_build_repo to be more robust Check for the existence of CMakeLists.txt files before trying to call add_subdirectory on examples, tests and src folders. Change-Id: I7be76de5f7520c1dd181c610fd1dc2200ac74672 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-05-24 17:18:21 +00:00
add_subdirectory(examples)
Simplify top-level CMakeLists.txt for modules Implement some aspects of qt_parts.prf to simplify the top-level CMakeLists.txt for repositories that follow the common qt structure (src, tools, tests, examples). Change-Id: Ia35f4e9207e92c1cf0406353561b0cc52dcb0e59 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-05-21 07:04:27 +00:00
endif()
endmacro()
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
macro(qt_set_up_standalone_tests_build)
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
# Remove this macro once all usages of it have been removed.
# Standalone tests are not handled via the main repo project and qt_build_tests.
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
endmacro()
CMake: Fix typo in function name Pick-to: 6.2 Change-Id: I72ab657670ca6fa460b3495f85d6edd920ee2c8a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-07 04:20:32 +00:00
function(qt_get_standalone_tests_config_files_path out_var)
CMake: Provide script to configure and build one or more tests Before this patch there were a few ways to build tests - Configure all tests as part of the repo build - Configure all tests as part of the repo build, but don't build tests by default (-DQT_NO_MAKE_TESTS=ON) - Configure all tests as a standalone project in a separate build dir using -QT_BUILD_STANDALONE_TESTS=ON All of the above incur some time overhead due to the necessity of configuring all tests. Sometimes you just want to build ONE test (or a few). To facilitate that use case, a new shell script called bin/qt-cmake-standalone-test(.bat) can now be used to configure and build one or more tests. The script takes one single argument pointing to the desired test project path and configures a generic template project that sets up all the necessary Qt CMake private API, afterwards calling add_subdirectory on the passed in project. Example $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon or $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image After that, simply run 'ninja && ctest' to build and run the test(s). This is the CMake equivalent of calling qmake on a test .pro file (or on a tests SUBDIRS .pro file) There are 3 details worth mentioning. Due to the add_subdirectory call, the built artifacts will not be in the top-level build dir, but rather in a nested build_dir. The script currently can't handle more than one argument (the path to the project), so you can't pass additional -DFoo=bar arguments. If a test uses a 3rd party library (like Threads::Threads) which was not a public dependency for any of the Qt modules, configuration will fail saying that the target was not found. Perhaps we should consider recording these packages when generating the StandaloneConfig.cmake files. Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-18 18:09:00 +00:00
set(path "${QT_CONFIG_INSTALL_DIR}/${INSTALL_CMAKE_NAMESPACE}BuildInternals/StandaloneTests")
CMake: Fix standalone tests to work properly on reconfiguration And also fix qt-cmake-standalone-test to work for prefix builds. The gist of it is that we have to protect tests not to be installed into the Qt install prefix, but we also have to make sure that the CMAKE_INSTALL_PREFIX is not changed globally (via cache value), so that reconfiguration still works. This took way too long to figure out. Amends d6272d774c7415186aa398e59f234d0073458072 Fixes: QTBUG-84346 Change-Id: I18c29574c9957fe05b86f701c8c14ec07e0f045b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-06-04 16:21:13 +00:00
# QT_CONFIG_INSTALL_DIR is relative in prefix builds.
if(QT_WILL_INSTALL)
Fix autotest config in cross-compiled prefix build qt-cmake-standalone-test would be looking for the config files under the target machine install prefix instead of under the staging prefix on the build host. Change-Id: I29850af6d8fe502f4944f689ec10539d17ccdcb9 Pick-to: 6.0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-08 15:24:15 +00:00
if(DEFINED CMAKE_STAGING_PREFIX)
qt_path_join(path "${CMAKE_STAGING_PREFIX}" "${path}")
else()
qt_path_join(path "${CMAKE_INSTALL_PREFIX}" "${path}")
endif()
CMake: Fix standalone tests to work properly on reconfiguration And also fix qt-cmake-standalone-test to work for prefix builds. The gist of it is that we have to protect tests not to be installed into the Qt install prefix, but we also have to make sure that the CMAKE_INSTALL_PREFIX is not changed globally (via cache value), so that reconfiguration still works. This took way too long to figure out. Amends d6272d774c7415186aa398e59f234d0073458072 Fixes: QTBUG-84346 Change-Id: I18c29574c9957fe05b86f701c8c14ec07e0f045b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-06-04 16:21:13 +00:00
endif()
CMake: Provide script to configure and build one or more tests Before this patch there were a few ways to build tests - Configure all tests as part of the repo build - Configure all tests as part of the repo build, but don't build tests by default (-DQT_NO_MAKE_TESTS=ON) - Configure all tests as a standalone project in a separate build dir using -QT_BUILD_STANDALONE_TESTS=ON All of the above incur some time overhead due to the necessity of configuring all tests. Sometimes you just want to build ONE test (or a few). To facilitate that use case, a new shell script called bin/qt-cmake-standalone-test(.bat) can now be used to configure and build one or more tests. The script takes one single argument pointing to the desired test project path and configures a generic template project that sets up all the necessary Qt CMake private API, afterwards calling add_subdirectory on the passed in project. Example $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon or $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image After that, simply run 'ninja && ctest' to build and run the test(s). This is the CMake equivalent of calling qmake on a test .pro file (or on a tests SUBDIRS .pro file) There are 3 details worth mentioning. Due to the add_subdirectory call, the built artifacts will not be in the top-level build dir, but rather in a nested build_dir. The script currently can't handle more than one argument (the path to the project), so you can't pass additional -DFoo=bar arguments. If a test uses a 3rd party library (like Threads::Threads) which was not a public dependency for any of the Qt modules, configuration will fail saying that the target was not found. Perhaps we should consider recording these packages when generating the StandaloneConfig.cmake files. Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-18 18:09:00 +00:00
set("${out_var}" "${path}" PARENT_SCOPE)
endfunction()
CMake: Make standalone tests TestsConfig file repo-target-set specific Conan CI builds can built a qt repository in a repo-target-set configuration. An example of that is qtscxml. When building standalone tests, qt_build_tests includes a repo specific TestsConfig.cmake file to call find_package on the modules that were built as part of that repo. That doesn't quite work with a repo-target-set build which is enabled when the repo is built with a QT_BUILD_SINGLE_REPO_TARGET_SET value. The TestsConfig.cmake file would be overridden with different contents on each configuration. Fix that by including the QT_BUILD_SINGLE_REPO_TARGET_SET value as part of the TestsConfig.cmake file to be generated and included. This means that when configuring the standalone tests, the same QT_BUILD_SINGLE_REPO_TARGET_SET value should be passed, so that the correct packages are found. Add some debug statements to allow checking which TestsConfig.cmake file is loaded when the standalone tests are configured with --log-level=DEBUG. Adjusts to 4b09522c23e9efdf83ba8d4af436d8a700ccb66e Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb Amends e7f188b2d2f10941006be7b0e7197b3c1ebdefdb Pick-to: 6.2 Task-number: QTBUG-96253 Change-Id: I7c22aaad88fe8e6fce23046543363316203f6e8d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-07 16:43:20 +00:00
function(qt_internal_get_standalone_tests_config_file_name out_var)
# When doing a "single repo target set" build (like in qtscxqml) ensure we use a unique tests
# config file for each repo target set. Using the PROJECT_NAME only is not enough because
# the same file will be overridden with different content on each repo set install.
set(tests_config_file_name "${PROJECT_NAME}")
if(QT_BUILD_SINGLE_REPO_TARGET_SET)
string(APPEND tests_config_file_name "RepoSet${QT_BUILD_SINGLE_REPO_TARGET_SET}")
endif()
string(APPEND tests_config_file_name "TestsConfig.cmake")
set(${out_var} "${tests_config_file_name}" PARENT_SCOPE)
endfunction()
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
macro(qt_build_tests)
Improve the internal handling of unity build - Removed the NO_UNITY_BUILD argument from commands that disable it by default. - Add a warning in case NO_UNITY_BUILD or NO_UNITY_BUILD_SOURCES is being used where it is already disabled, e.g., qt_internal_add_test - Exclude all sources of a target from unity build if NO_UNITY_BUILD is set on the target. This sounds a bit harsh, but I have noticed that sometimes the same source file can be included somewhere else, and some unexpected collision may occur. - qt_examples_build_end excludes all its examples from the unity build. - qt_build_test now sets the CMAKE_UNITY_BUILD to OFF before configuring the tests, and restore its value when done. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ia42e7dd5a5bfb151db241deb639325720fd91eec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-09 13:53:14 +00:00
set(CMAKE_UNITY_BUILD OFF)
CMake: Rename QT_EXAMPLES_CMAKE_PREFIX_PATH ...to QT_BUILD_CMAKE_PREFIX_PATH, because the variable is now used for examples and tests. Change-Id: Ie6d32a0c99f46407f2771e12638456078c59fb18 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-23 08:11:15 +00:00
# Prepending to QT_BUILD_CMAKE_PREFIX_PATH helps find components of Qt6, because those
CMake: Allow find_package(Qt6 COMPONENTS Foo) in tests In prefix builds of non-qtbase repositories, calls to find_package(Qt6 COMPONENT Foo) did not work in tests, because the find_package calls in Qt6Config.cmake use NO_DEFAULT_PATH, and thus CMAKE_PREFIX_PATH is ignored. Non-external-project examples had the same problem. This was fixed by ffe088941378e32ea30c142cca7e63c537a41ff1 which introduced the variable QT_EXAMPLES_CMAKE_PREFIX_PATH as additional parameter in all relevant find_package calls. We now set this variable in qt_build_tests where it should be local to the tests directory and its children. We cannot use QT_ADDITIONAL_PACKAGES_PREFIX_PATH, because it's value is read once and cached in Qt6Config.cmake - we would have to clear the internal cache variable. It would probably be good to rename QT_EXAMPLES_CMAKE_PREFIX_PATH to reflect that it's not just used for examples. However, my naming skills are drained for today. Task-number: QTBUG-88264 Change-Id: I8bcfe9b7f2ee1f1b75dc725977924d09cb36822c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-18 15:33:21 +00:00
# find_package calls use NO_DEFAULT_PATH, and thus CMAKE_PREFIX_PATH is ignored.
Make sure that tests use the module build directory but not install path If we configure module that is already installed it's expected that tests use the build directory to resolve all the depdencies, but not the install directory. This is especially sensetive if the module cmake scripts were changed. This changes the order of find_<package|dependency> PATHS that are used to locate Qt package. QT_EXAMPLES_CMAKE_PREFIX_PATH now is used at first, so we guarantee that we look into the build directory at first place. This trick only works if build directory is added to CMAKE_FIND_ROOT_PATH. The reason for that is the internal CMake logic that tries to relocate the search PATHs and put the paths that are subdirs of or exact CMAKE_FIND_ROOT_PATH higher in search list. Fixes: QTBUG-115730 Change-Id: Icab721f0a6eac7301c626350ab214cc4545b368b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-22 17:11:30 +00:00
list(PREPEND CMAKE_FIND_ROOT_PATH "${QT_BUILD_DIR}")
CMake: Rename QT_EXAMPLES_CMAKE_PREFIX_PATH ...to QT_BUILD_CMAKE_PREFIX_PATH, because the variable is now used for examples and tests. Change-Id: Ie6d32a0c99f46407f2771e12638456078c59fb18 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-23 08:11:15 +00:00
list(PREPEND QT_BUILD_CMAKE_PREFIX_PATH "${QT_BUILD_DIR}/${INSTALL_LIBDIR}/cmake")
CMake: Allow find_package(Qt6 COMPONENTS Foo) in tests In prefix builds of non-qtbase repositories, calls to find_package(Qt6 COMPONENT Foo) did not work in tests, because the find_package calls in Qt6Config.cmake use NO_DEFAULT_PATH, and thus CMAKE_PREFIX_PATH is ignored. Non-external-project examples had the same problem. This was fixed by ffe088941378e32ea30c142cca7e63c537a41ff1 which introduced the variable QT_EXAMPLES_CMAKE_PREFIX_PATH as additional parameter in all relevant find_package calls. We now set this variable in qt_build_tests where it should be local to the tests directory and its children. We cannot use QT_ADDITIONAL_PACKAGES_PREFIX_PATH, because it's value is read once and cached in Qt6Config.cmake - we would have to clear the internal cache variable. It would probably be good to rename QT_EXAMPLES_CMAKE_PREFIX_PATH to reflect that it's not just used for examples. However, my naming skills are drained for today. Task-number: QTBUG-88264 Change-Id: I8bcfe9b7f2ee1f1b75dc725977924d09cb36822c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-18 15:33:21 +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(QT_BUILD_STANDALONE_TESTS)
# Find location of TestsConfig.cmake. These contain the modules that need to be
# find_package'd when testing.
CMake: Fix typo in function name Pick-to: 6.2 Change-Id: I72ab657670ca6fa460b3495f85d6edd920ee2c8a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-07 04:20:32 +00:00
qt_get_standalone_tests_config_files_path(_qt_build_tests_install_prefix)
CMake: Make standalone tests TestsConfig file repo-target-set specific Conan CI builds can built a qt repository in a repo-target-set configuration. An example of that is qtscxml. When building standalone tests, qt_build_tests includes a repo specific TestsConfig.cmake file to call find_package on the modules that were built as part of that repo. That doesn't quite work with a repo-target-set build which is enabled when the repo is built with a QT_BUILD_SINGLE_REPO_TARGET_SET value. The TestsConfig.cmake file would be overridden with different contents on each configuration. Fix that by including the QT_BUILD_SINGLE_REPO_TARGET_SET value as part of the TestsConfig.cmake file to be generated and included. This means that when configuring the standalone tests, the same QT_BUILD_SINGLE_REPO_TARGET_SET value should be passed, so that the correct packages are found. Add some debug statements to allow checking which TestsConfig.cmake file is loaded when the standalone tests are configured with --log-level=DEBUG. Adjusts to 4b09522c23e9efdf83ba8d4af436d8a700ccb66e Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb Amends e7f188b2d2f10941006be7b0e7197b3c1ebdefdb Pick-to: 6.2 Task-number: QTBUG-96253 Change-Id: I7c22aaad88fe8e6fce23046543363316203f6e8d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-07 16:43:20 +00:00
qt_internal_get_standalone_tests_config_file_name(_qt_tests_config_file_name)
set(_qt_standalone_tests_config_file_path
"${_qt_build_tests_install_prefix}/${_qt_tests_config_file_name}")
include("${_qt_standalone_tests_config_file_path}"
OPTIONAL
RESULT_VARIABLE _qt_standalone_tests_included)
if(NOT _qt_standalone_tests_included)
message(DEBUG
"Standalone tests config file not included because it does not exist: "
"${_qt_standalone_tests_config_file_path}"
)
else()
message(DEBUG
"Standalone tests config file included successfully: "
"${_qt_standalone_tests_config_file_path}"
)
endif()
unset(_qt_standalone_tests_config_file_path)
unset(_qt_standalone_tests_included)
unset(_qt_tests_config_file_name)
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
# Of course we always need the test module as well.
CMake: Record used package version for each target dependency When recording which package version to look for in QtFooModuleDependencies.cmake and other files like it, instead of using PROJECT_VERSION, use the version of the package that contains the dependency. For example if we're hypothetically building the qtdeclarative repo from the 6.4 branch, against an installed 6.2 qtbase, then the Qt6QmlModuleDependencies.cmake file will have a find_package(Qt6Core 6.2) call because qtdeclarative's find_package(Qt6Core) call found a 6.2 Core when it was configured. This allows switching the versioning scheme of specific Qt modules that might not want to follow the general Qt versioning scheme. The first candidate would be QtWebEngine which might want to follow the Chromium versioning scheme, something like Qt 6.94.0 where 94 is the Chromium major version. Implementation notes. We now record the package version of a target in a property called _qt_package_version. We do it for qt modules, plugins, 3rd party libraries, tools and the Platform target. When we try to look up which version to write into the QtFooModuleDependencies.cmake file (or the equivalent Plugins and Tools file), we try to find the version from a few sources: the property mentioned above, then the Qt6{target}_VERSION variable, and finally PROJECT_VERSION. In the latter case, we issue a warning because technically that should never have to happen, and it's a bug or an unforeseen case if it does. A few more places also need adjustments: - package versions to look for when configuring standalone tests and generating standalone tests Config files - handling of tools packages - The main Qt6 package lookup in each Dependencies.cmake files Note that there are some requirements and consequences in case a module wants to use a different versioning scheme like 6.94.0. Requirements. - The root CMakeLists.txt file needs to call find_package with a version different from the usual PROJECT_VERSION. Ideally it should look for a few different Qt versions which are known to be compatible, for example the last stable and LTS versions, or just the lowest supported Qt version, e.g. 6.2.6 or whenever this change would land in the 6.2 branch. - If the repository has multiple modules, some of which need to follow the Qt versioning scheme and some not, project(VERSION x.y.z) calls need to be carefully placed in subdirectory scopes with appropriate version numbers, so that qt_internal_add_module / _tool / _plugin pick up the correct version. Consequences. - The .so / .dylib names will contain the new version, e.g. .so.6.94 - Linux ELF symbols will contain the new versions - syncqt private headers will now exist under a include/QtFoo/6.94.0/QtFoo/private folder - pri and prl files will also contain the new version numbers - pkg-config .pc files contain the new version numbers - It won't be possible to write find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code. One would have to write find_package(Qt6WebEngineWidgets 6.94) otherwise CMake will try to look for Qt6Config 6.94 which won't exist. - Similarly, a find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call would always find any kind of WebEngine package that is higher than 6.4, which might be 6.94, 6.95, etc. - In the future, if we fix Qt6Config to pass EXACT to its subcomponent find_package calls, a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets) would fail to find WebEngineWidgets, because its 6.94.0 version will not be equal to 6.5.0. Currently we don't pass through EXACT, so it's not an issue. Augments 5ffc744b791a114a3180a425dd26e298f7399955 Task-number: QTBUG-103500 Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-17 06:44:43 +00:00
# When looking for the Test package, do it using the Qt6 package version, in case if
# PROJECT_VERSION is following a different versioning scheme.
if(Qt6_VERSION)
set(_qt_build_tests_package_version "${Qt6_VERSION}")
else()
set(_qt_build_tests_package_version "${PROJECT_VERSION}")
endif()
find_package(Qt6 "${_qt_build_tests_package_version}" CONFIG REQUIRED COMPONENTS Test)
unset(_qt_build_tests_package_version)
CMake: Use correct C++ standard flag when building standalone tests Before the patch we set the standard flags in two places: - once when building qtbase - and always when including QtSetup (for every repo that is built) This change makes sure to also set the correct standards flag when building standalone tests, because QtSetup is called to early in that case. Change-Id: Iad130b731e9eb9605bb91637364c33fdd49ce3cb Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
2020-02-18 09:59:11 +00:00
# Set language standards after finding Core, because that's when the relevant
# feature variables are available, and the call in QtSetup is too early when building
# standalone tests, because Core was not find_package()'d yet.
qt_set_language_standards()
CMake: Make sure not to use the Qt prefix for standalone tests We don't want people accidentally installing tests into the Qt prefix. Change-Id: Ic99492559875f753897a83af162253cac846a8a5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-16 18:30:03 +00:00
if(NOT QT_SUPERBUILD)
CMake: Fix standalone tests to work properly on reconfiguration And also fix qt-cmake-standalone-test to work for prefix builds. The gist of it is that we have to protect tests not to be installed into the Qt install prefix, but we also have to make sure that the CMAKE_INSTALL_PREFIX is not changed globally (via cache value), so that reconfiguration still works. This took way too long to figure out. Amends d6272d774c7415186aa398e59f234d0073458072 Fixes: QTBUG-84346 Change-Id: I18c29574c9957fe05b86f701c8c14ec07e0f045b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-06-04 16:21:13 +00:00
# Set up fake standalone tests install prefix, so we don't pollute the Qt install
# prefix. For super builds it needs to be done in qt5/CMakeLists.txt.
qt_set_up_fake_standalone_tests_install_prefix()
CMake: Make sure not to use the Qt prefix for standalone tests We don't want people accidentally installing tests into the Qt prefix. Change-Id: Ic99492559875f753897a83af162253cac846a8a5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-16 18:30:03 +00:00
endif()
Set QT_ANDROID_ABIS when builing qtbase for Android When building Qt we need to set QT_ANDROID_ABIS value to CMAKE_ANDROID_ARCH_ABI explictily since the automatical detecting of android ABI is not executed. This fixes build of the qtbase in-tree tests. Fixes: QTBUG-97133 Change-Id: Ica7057bcfcc8f4fe4b5a921ca7449f74cdbca0f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-10-13 12:03:53 +00:00
else()
if(ANDROID)
# When building in-tree tests we need to specify the QT_ANDROID_ABIS list. Since we
# build Qt for the single ABI, build tests for this ABI only.
set(QT_ANDROID_ABIS "${CMAKE_ANDROID_ARCH_ABI}")
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
endif()
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/auto/CMakeLists.txt")
add_subdirectory(auto)
endif()
Build minimal subset of tests for Android multi-ABI Qt builds Add an option to limit the number of tests for building and testing Android multi-ABI configurations in CI. Currently only Core tests supposed to run. Change-Id: Ibb8a41d60d108259ef2675ec54bde2482f87c8b2 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-21 13:32:00 +00:00
if(NOT QT_BUILD_MINIMAL_STATIC_TESTS AND NOT QT_BUILD_MINIMAL_ANDROID_MULTI_ABI_TESTS)
Rename and restructure the baseline (lancelot) testing code In preparation for addition of new baseline tests, establish a new test category, "baseline". This is similar to the category "benchmarks" in that it contains tests that use the QTest framework, but conceptually are not unit tests, in contrast to those under auto/. Move the existing QPainter baseline test, tst_lancelot, into this new category, and rename it accordingly. Baseline tests use the QBaselineTest extension to QTest. Move that extension too into the tests/baseline directory, allowing the clean out of the baselineserver directory. Pick-to: 6.2 Change-Id: I1b527f5867c953b1d22be73798fcf7d1494712ea Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
2021-11-15 12:36:48 +00:00
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/baseline/CMakeLists.txt")
add_subdirectory(baseline)
endif()
CMake: Build minimal subset of tests in desktop static builds Add new configure option -make minimal-static-tests and CMake option QT_BUILD_MINIMAL_STATIC_TESTS. In conjunction with QT_BUILD_TESTS it will enable building a minimal subset of tests when targeting a static desktop Qt build. In qtbase the minimal subset includes all the auto tests of testlib, tools, corelib and cmake. In particular this will also do cmake build tests and qmake build tests (tst_qmake) Adjust CI instructions to enable building a minimal subset of static tests when a platform configuration is tagged with the MinimalStaticTests feature. Fix and skip a few tests that were failing. Pick-to: 6.1 Task-number: QTBUG-87580 Task-number: QTBUG-91869 Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-03-15 16:03:38 +00:00
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/benchmarks/CMakeLists.txt" AND QT_BUILD_BENCHMARKS)
add_subdirectory(benchmarks)
endif()
if(EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/manual/CMakeLists.txt" AND QT_BUILD_MANUAL_TESTS)
add_subdirectory(manual)
endif()
Build test/manual if it contains a CMakeLists.txt Change-Id: Ibada60b0902f9c6a6a7284489a56106e0021a9de Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-08 10:23:04 +00:00
endif()
Improve the internal handling of unity build - Removed the NO_UNITY_BUILD argument from commands that disable it by default. - Add a warning in case NO_UNITY_BUILD or NO_UNITY_BUILD_SOURCES is being used where it is already disabled, e.g., qt_internal_add_test - Exclude all sources of a target from unity build if NO_UNITY_BUILD is set on the target. This sounds a bit harsh, but I have noticed that sometimes the same source file can be included somewhere else, and some unexpected collision may occur. - qt_examples_build_end excludes all its examples from the unity build. - qt_build_test now sets the CMAKE_UNITY_BUILD to OFF before configuring the tests, and restore its value when done. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ia42e7dd5a5bfb151db241deb639325720fd91eec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-09 13:53:14 +00:00
set(CMAKE_UNITY_BUILD ${QT_UNITY_BUILD})
Allow building the tests directory as a standalone CMake project At the moment, Coin builds tests as a separate qmake invocation against an installed Qt. We need to support the same with CMake. Change the tests subdirectory to be a standalone CMake project when CMake does not detect an existing QtTest target while processing the subdirectory. If the target exists, it means we are building the whole repo, if the target does not exist, we need to call find_package to find the installed Qt. Refactor and move around a few things to make standalone tests build successfully: - add a new macro to set up paths to find QtSetup - add a new macro to find all macOS frameworks - add a new macro to set up building tests - add a new macro that actually builds the tests - export the INSTALL_CMAKE_NAMESPACE value into the BuildInternals Config file - export the CMAKE_BUILD_TYPE value, because a test project doesn't have a .git subdir and thus defaults to be built in Release mode, even though qtbase might have been built in Debug, so to avoid the mixing, the propagate the build type - stop overriding INSTALL_CMAKE_NAMESPACE and QT_CMAKE_EXPORT_NAMESPACE inside QtSetup if they are set, because the tests project doesn't specify a major version, and if we override the values, the moc / uic targets don't get the correct major version prefix and configuration fails Change-Id: Ibdb03687302567fe325a15f6d1cb922c76240675 Fixes: QTBUG-75090 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-22 08:22:08 +00:00
endmacro()
Fix Standalone Example build when crosscompiling Added qt_examples_begin() and qt_examples_end() macros to setup the example list so it can be re-used in other projects. When cross-compiling, we also need to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH in order for find_package() to work correctly. Removed support for building the whole qtbase/examples folder as a standalone project. Building examples is only supported when building the whole of qtbase (qtbase + examples together) or each individual example is built separately against an installed Qt version. Change-Id: I9d26b94b48b95af230b76ab618becb21d2d45581 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 11:08:41 +00:00
CMake: Make build system of installed Qt more relocatable Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way. The following story inspired this change. If a user wants to build a Qt repo into a different install prefix than the usual Qt one, this will fail configuration because we look for various things like syncqt, qdoc, etc relative to CMAKE_INSTALL_PREFIX, which will now point to a different location where none of the above tools are located. The intent for such a use case is to support building Qt packages with Conan, which sets a random install prefix when configuring a repo. The idea is to derive the qt prefix dynamically from the QtBuildInternals package location. Essentially it's a reverse relative path from the QtBuildInternalsConfig.cmake file to the install prefix that was specified when initially configuring qtbase. Once the dynamic prefix is computed (so we know where the possibly relocated Qt is), we can find tools like syncqt and qdoc. This is an initial attempt to support a use case like that. More design work will probably needed in case if tools / libs need to be found in a location different than the Qt install prefix (so support for multiple install prefixes / search paths). An example of such a case would be when building qtdeclarative and qtquickcontrols2 as Conan packages in one go. Most likely the qmltyperegistrar tool will be located in the random install prefix set by Conan, so building qtquickcontrols2 might fail due to not finding the tool in the original Qt install prefix. As to the implementation details, the change does the following: - Dynamically computes and sets the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when find_package()'ing QtBuildInternals. It's an absolute path pointing to where the relocated Qt is. - When building qtbase this variable is not yet available (due to QtBuildInternalsExtra not existing), in that case we set the variable to the absolute path of CMAKE_INSTALL_PREFIX (but only for the initial qtbase configuration). - Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used for standalone tests purposes. It's not needed now that we compute the location of the Qt prefix dynamically. - The Unixy qt-cmake and qt-cmake-private shell scripts now use a relative path to find the toolchain file we created. - The toolchain file also dynamically computes the location of the Qt packages, and adds them to CMAKE_PREFIX_PATH. - A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding tool locations, mkspecs dir, path environment setup for tools, etc. - Some places still use CMAKE_PREFIX_PATH in the following cases - When determining paths while configuring qtbase (valid cases) - When I wasn't sure what the behavior should be, so I left them as-is (an example is documentation generation, do we want to install it into the random Conan prefix, or into the main prefix? Currently it installs in the random prefix). Note that relocating a Qt installation does not work for non-prefix / non-installed builds, due to hardcoded paths to include directories and libraries in generated FooTargets.cmake files. Task-number: QTBUG-83999 Change-Id: I87d6558729db93121b1715771034b03ce3295923 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
function(qt_compute_relative_path_from_cmake_config_dir_to_prefix)
# Compute the reverse relative path from the CMake config dir to the install prefix.
# This is used in QtBuildInternalsExtras to create a relocatable relative install prefix path.
# This path is used for finding syncqt and other things, regardless of initial install prefix
# (e.g installed Qt was archived and unpacked to a different path on a different machine).
#
# This is meant to be called only once when configuring qtbase.
#
# Similar code exists in Qt6CoreConfigExtras.cmake.in and src/corelib/CMakeLists.txt which
# might not be needed anymore.
CMake: Allow no install + custom on-device prefix for desktop builds Allow such a combination - staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the qtbase build dir - install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set to some custom location even for non-cross builds. An example would be configure -prefix /usr \ -extprefix ~/qt/qtbase_build_dir CMake will put the Qt libraries in the qtbase build dir, ninja install will not be required, but ultimately in order to run applications, the Qt libraries are expected to be in /usr. Support for this scenario was originally added for cross-builds in 062318feb2d3b7598409c7e81e4459c2f4607764 , but not desktop builds. Such a build is useful when you want to have install rpaths different from where Qt is initially installed to (the staging prefix). This case doesn't really happen often when targeting desktop platforms, it's mostly used for cross-compilation (e.g yocto). Being able to have the same setup with a desktop build is nevertheless useful for faster iteration on build system issues in such a scenario. Amends 062318feb2d3b7598409c7e81e4459c2f4607764 Pick-to: 6.2 6.3 Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-04-13 12:57:34 +00:00
if(CMAKE_STAGING_PREFIX)
set(__qt_prefix "${CMAKE_STAGING_PREFIX}")
else()
set(__qt_prefix "${CMAKE_INSTALL_PREFIX}")
endif()
CMake: Make build system of installed Qt more relocatable Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way. The following story inspired this change. If a user wants to build a Qt repo into a different install prefix than the usual Qt one, this will fail configuration because we look for various things like syncqt, qdoc, etc relative to CMAKE_INSTALL_PREFIX, which will now point to a different location where none of the above tools are located. The intent for such a use case is to support building Qt packages with Conan, which sets a random install prefix when configuring a repo. The idea is to derive the qt prefix dynamically from the QtBuildInternals package location. Essentially it's a reverse relative path from the QtBuildInternalsConfig.cmake file to the install prefix that was specified when initially configuring qtbase. Once the dynamic prefix is computed (so we know where the possibly relocated Qt is), we can find tools like syncqt and qdoc. This is an initial attempt to support a use case like that. More design work will probably needed in case if tools / libs need to be found in a location different than the Qt install prefix (so support for multiple install prefixes / search paths). An example of such a case would be when building qtdeclarative and qtquickcontrols2 as Conan packages in one go. Most likely the qmltyperegistrar tool will be located in the random install prefix set by Conan, so building qtquickcontrols2 might fail due to not finding the tool in the original Qt install prefix. As to the implementation details, the change does the following: - Dynamically computes and sets the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when find_package()'ing QtBuildInternals. It's an absolute path pointing to where the relocated Qt is. - When building qtbase this variable is not yet available (due to QtBuildInternalsExtra not existing), in that case we set the variable to the absolute path of CMAKE_INSTALL_PREFIX (but only for the initial qtbase configuration). - Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used for standalone tests purposes. It's not needed now that we compute the location of the Qt prefix dynamically. - The Unixy qt-cmake and qt-cmake-private shell scripts now use a relative path to find the toolchain file we created. - The toolchain file also dynamically computes the location of the Qt packages, and adds them to CMAKE_PREFIX_PATH. - A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding tool locations, mkspecs dir, path environment setup for tools, etc. - Some places still use CMAKE_PREFIX_PATH in the following cases - When determining paths while configuring qtbase (valid cases) - When I wasn't sure what the behavior should be, so I left them as-is (an example is documentation generation, do we want to install it into the random Conan prefix, or into the main prefix? Currently it installs in the random prefix). Note that relocating a Qt installation does not work for non-prefix / non-installed builds, due to hardcoded paths to include directories and libraries in generated FooTargets.cmake files. Task-number: QTBUG-83999 Change-Id: I87d6558729db93121b1715771034b03ce3295923 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
if(QT_WILL_INSTALL)
get_filename_component(clean_config_prefix
CMake: Allow no install + custom on-device prefix for desktop builds Allow such a combination - staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the qtbase build dir - install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set to some custom location even for non-cross builds. An example would be configure -prefix /usr \ -extprefix ~/qt/qtbase_build_dir CMake will put the Qt libraries in the qtbase build dir, ninja install will not be required, but ultimately in order to run applications, the Qt libraries are expected to be in /usr. Support for this scenario was originally added for cross-builds in 062318feb2d3b7598409c7e81e4459c2f4607764 , but not desktop builds. Such a build is useful when you want to have install rpaths different from where Qt is initially installed to (the staging prefix). This case doesn't really happen often when targeting desktop platforms, it's mostly used for cross-compilation (e.g yocto). Being able to have the same setup with a desktop build is nevertheless useful for faster iteration on build system issues in such a scenario. Amends 062318feb2d3b7598409c7e81e4459c2f4607764 Pick-to: 6.2 6.3 Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-04-13 12:57:34 +00:00
"${__qt_prefix}/${QT_CONFIG_INSTALL_DIR}" ABSOLUTE)
CMake: Make build system of installed Qt more relocatable Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way. The following story inspired this change. If a user wants to build a Qt repo into a different install prefix than the usual Qt one, this will fail configuration because we look for various things like syncqt, qdoc, etc relative to CMAKE_INSTALL_PREFIX, which will now point to a different location where none of the above tools are located. The intent for such a use case is to support building Qt packages with Conan, which sets a random install prefix when configuring a repo. The idea is to derive the qt prefix dynamically from the QtBuildInternals package location. Essentially it's a reverse relative path from the QtBuildInternalsConfig.cmake file to the install prefix that was specified when initially configuring qtbase. Once the dynamic prefix is computed (so we know where the possibly relocated Qt is), we can find tools like syncqt and qdoc. This is an initial attempt to support a use case like that. More design work will probably needed in case if tools / libs need to be found in a location different than the Qt install prefix (so support for multiple install prefixes / search paths). An example of such a case would be when building qtdeclarative and qtquickcontrols2 as Conan packages in one go. Most likely the qmltyperegistrar tool will be located in the random install prefix set by Conan, so building qtquickcontrols2 might fail due to not finding the tool in the original Qt install prefix. As to the implementation details, the change does the following: - Dynamically computes and sets the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when find_package()'ing QtBuildInternals. It's an absolute path pointing to where the relocated Qt is. - When building qtbase this variable is not yet available (due to QtBuildInternalsExtra not existing), in that case we set the variable to the absolute path of CMAKE_INSTALL_PREFIX (but only for the initial qtbase configuration). - Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used for standalone tests purposes. It's not needed now that we compute the location of the Qt prefix dynamically. - The Unixy qt-cmake and qt-cmake-private shell scripts now use a relative path to find the toolchain file we created. - The toolchain file also dynamically computes the location of the Qt packages, and adds them to CMAKE_PREFIX_PATH. - A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding tool locations, mkspecs dir, path environment setup for tools, etc. - Some places still use CMAKE_PREFIX_PATH in the following cases - When determining paths while configuring qtbase (valid cases) - When I wasn't sure what the behavior should be, so I left them as-is (an example is documentation generation, do we want to install it into the random Conan prefix, or into the main prefix? Currently it installs in the random prefix). Note that relocating a Qt installation does not work for non-prefix / non-installed builds, due to hardcoded paths to include directories and libraries in generated FooTargets.cmake files. Task-number: QTBUG-83999 Change-Id: I87d6558729db93121b1715771034b03ce3295923 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
else()
get_filename_component(clean_config_prefix "${QT_CONFIG_BUILD_DIR}" ABSOLUTE)
endif()
file(RELATIVE_PATH
qt_path_from_cmake_config_dir_to_prefix
CMake: Allow no install + custom on-device prefix for desktop builds Allow such a combination - staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the qtbase build dir - install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set to some custom location even for non-cross builds. An example would be configure -prefix /usr \ -extprefix ~/qt/qtbase_build_dir CMake will put the Qt libraries in the qtbase build dir, ninja install will not be required, but ultimately in order to run applications, the Qt libraries are expected to be in /usr. Support for this scenario was originally added for cross-builds in 062318feb2d3b7598409c7e81e4459c2f4607764 , but not desktop builds. Such a build is useful when you want to have install rpaths different from where Qt is initially installed to (the staging prefix). This case doesn't really happen often when targeting desktop platforms, it's mostly used for cross-compilation (e.g yocto). Being able to have the same setup with a desktop build is nevertheless useful for faster iteration on build system issues in such a scenario. Amends 062318feb2d3b7598409c7e81e4459c2f4607764 Pick-to: 6.2 6.3 Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-04-13 12:57:34 +00:00
"${clean_config_prefix}" "${__qt_prefix}")
CMake: Make build system of installed Qt more relocatable Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way. The following story inspired this change. If a user wants to build a Qt repo into a different install prefix than the usual Qt one, this will fail configuration because we look for various things like syncqt, qdoc, etc relative to CMAKE_INSTALL_PREFIX, which will now point to a different location where none of the above tools are located. The intent for such a use case is to support building Qt packages with Conan, which sets a random install prefix when configuring a repo. The idea is to derive the qt prefix dynamically from the QtBuildInternals package location. Essentially it's a reverse relative path from the QtBuildInternalsConfig.cmake file to the install prefix that was specified when initially configuring qtbase. Once the dynamic prefix is computed (so we know where the possibly relocated Qt is), we can find tools like syncqt and qdoc. This is an initial attempt to support a use case like that. More design work will probably needed in case if tools / libs need to be found in a location different than the Qt install prefix (so support for multiple install prefixes / search paths). An example of such a case would be when building qtdeclarative and qtquickcontrols2 as Conan packages in one go. Most likely the qmltyperegistrar tool will be located in the random install prefix set by Conan, so building qtquickcontrols2 might fail due to not finding the tool in the original Qt install prefix. As to the implementation details, the change does the following: - Dynamically computes and sets the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when find_package()'ing QtBuildInternals. It's an absolute path pointing to where the relocated Qt is. - When building qtbase this variable is not yet available (due to QtBuildInternalsExtra not existing), in that case we set the variable to the absolute path of CMAKE_INSTALL_PREFIX (but only for the initial qtbase configuration). - Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used for standalone tests purposes. It's not needed now that we compute the location of the Qt prefix dynamically. - The Unixy qt-cmake and qt-cmake-private shell scripts now use a relative path to find the toolchain file we created. - The toolchain file also dynamically computes the location of the Qt packages, and adds them to CMAKE_PREFIX_PATH. - A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding tool locations, mkspecs dir, path environment setup for tools, etc. - Some places still use CMAKE_PREFIX_PATH in the following cases - When determining paths while configuring qtbase (valid cases) - When I wasn't sure what the behavior should be, so I left them as-is (an example is documentation generation, do we want to install it into the random Conan prefix, or into the main prefix? Currently it installs in the random prefix). Note that relocating a Qt installation does not work for non-prefix / non-installed builds, due to hardcoded paths to include directories and libraries in generated FooTargets.cmake files. Task-number: QTBUG-83999 Change-Id: I87d6558729db93121b1715771034b03ce3295923 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-05 08:30:35 +00:00
set(qt_path_from_cmake_config_dir_to_prefix "${qt_path_from_cmake_config_dir_to_prefix}"
PARENT_SCOPE)
endfunction()
function(qt_get_relocatable_install_prefix out_var)
# We need to compute it only once while building qtbase. Afterwards it's loaded from
# QtBuildInternalsExtras.cmake.
if(QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX)
return()
endif()
# The QtBuildInternalsExtras value is dynamically computed, whereas the initial qtbase
# configuration uses an absolute path.
set(${out_var} "${CMAKE_INSTALL_PREFIX}" PARENT_SCOPE)
endfunction()
CMake: Fix standalone tests to work properly on reconfiguration And also fix qt-cmake-standalone-test to work for prefix builds. The gist of it is that we have to protect tests not to be installed into the Qt install prefix, but we also have to make sure that the CMAKE_INSTALL_PREFIX is not changed globally (via cache value), so that reconfiguration still works. This took way too long to figure out. Amends d6272d774c7415186aa398e59f234d0073458072 Fixes: QTBUG-84346 Change-Id: I18c29574c9957fe05b86f701c8c14ec07e0f045b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-06-04 16:21:13 +00:00
function(qt_set_up_fake_standalone_tests_install_prefix)
# Set a fake local (non-cache) CMAKE_INSTALL_PREFIX.
# Needed for standalone tests, we don't want to accidentally install a test into the Qt prefix.
CMake: Don't reset install prefix upon standalone test reconfiguration CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT might be empty on the first configuration, but because QtBuildInternalsExtra sets the CMAKE_INSTALL_PREFIX, a second reconfiguration of a test would stop setting the fake install prefix. After some further consideration, there's no need to set the local fake prefix conditionally, we can always do it (unless explicitly opted out). This makes sure that a reconfiguration of a test doesn't suddenly install into the Qt prefix again. Amends 37b132cd4e081821ddc261d24abe8f914123547a Task-number: QTBUG-84346 Change-Id: Ic61aefe18418658455d8cdb9ebe6bcbcb8d67c99 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-06-05 11:46:48 +00:00
# Allow opt-out, if a user knows what they're doing.
if(QT_NO_FAKE_STANDALONE_TESTS_INSTALL_PREFIX)
return()
CMake: Fix usage of correct install prefix for standalone tests Previously configuration of standalone tests might have failed due to CMake trying to create files in the /usr/local default prefix. Make sure to use a fake prefix in the binary dir instead, unless another prefix is explicitly specified. Change-Id: Icfcb32285aa5596abf1a918396b26673880a8d27 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-04-28 09:45:44 +00:00
endif()
CMake: Don't reset install prefix upon standalone test reconfiguration CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT might be empty on the first configuration, but because QtBuildInternalsExtra sets the CMAKE_INSTALL_PREFIX, a second reconfiguration of a test would stop setting the fake install prefix. After some further consideration, there's no need to set the local fake prefix conditionally, we can always do it (unless explicitly opted out). This makes sure that a reconfiguration of a test doesn't suddenly install into the Qt prefix again. Amends 37b132cd4e081821ddc261d24abe8f914123547a Task-number: QTBUG-84346 Change-Id: Ic61aefe18418658455d8cdb9ebe6bcbcb8d67c99 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-06-05 11:46:48 +00:00
set(new_install_prefix "${CMAKE_BINARY_DIR}/fake_prefix")
CMake: Fix usage of correct install prefix for standalone tests Previously configuration of standalone tests might have failed due to CMake trying to create files in the /usr/local default prefix. Make sure to use a fake prefix in the binary dir instead, unless another prefix is explicitly specified. Change-Id: Icfcb32285aa5596abf1a918396b26673880a8d27 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-04-28 09:45:44 +00:00
CMake: Fix standalone tests to work properly on reconfiguration And also fix qt-cmake-standalone-test to work for prefix builds. The gist of it is that we have to protect tests not to be installed into the Qt install prefix, but we also have to make sure that the CMAKE_INSTALL_PREFIX is not changed globally (via cache value), so that reconfiguration still works. This took way too long to figure out. Amends d6272d774c7415186aa398e59f234d0073458072 Fixes: QTBUG-84346 Change-Id: I18c29574c9957fe05b86f701c8c14ec07e0f045b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-06-04 16:21:13 +00:00
# It's IMPORTANT that this is not a cache variable. Otherwise
# qt_get_standalone_tests_confg_files_path() will not work on re-configuration.
message(STATUS
"Setting local standalone test install prefix (non-cached) to '${new_install_prefix}'.")
set(CMAKE_INSTALL_PREFIX "${new_install_prefix}" PARENT_SCOPE)
CMake: Fix handling of rpaths for tests with CMAKE_STAGING_PREFIX Task-number: QTBUG-86053 Change-Id: I2f368d9dc2d871b67bd6261aadd8ef4c1dd1ae54 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-23 10:45:10 +00:00
# We also need to clear the staging prefix if it's set, otherwise CMake will modify any computed
# rpaths containing the staging prefix to point to the new fake prefix, which is not what we
# want. This replacement is done in cmComputeLinkInformation::GetRPath().
#
# By clearing the staging prefix for the standalone tests, any detected link time
# rpaths will be embedded as-is, which will point to the place where Qt was installed (aka
# the staging prefix).
if(DEFINED CMAKE_STAGING_PREFIX)
message(STATUS "Clearing local standalone test staging prefix (non-cached).")
set(CMAKE_STAGING_PREFIX "" PARENT_SCOPE)
endif()
CMake: Make sure not to use the Qt prefix for standalone tests We don't want people accidentally installing tests into the Qt prefix. Change-Id: Ic99492559875f753897a83af162253cac846a8a5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-16 18:30:03 +00:00
endfunction()
CMake: Fix configuration of CMake tests in-build-tree Qt6 package was not found the tests were configured in-tree as opposed to standalone tests. Use the same trick we do for building examples in-tree. Specify the path to the build tree packages, and don't create targets. Amends 96e3ee06598d00e7155f3f8574759ea658a134e5 Change-Id: Ia60de416ce0afff5bd40be8c0c6e3c7898fd7ebf Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-20 15:12:45 +00:00
# Mean to be called when configuring examples as part of the main build tree, as well as for CMake
# tests (tests that call CMake to try and build CMake applications).
macro(qt_internal_set_up_build_dir_package_paths)
CMake: prepend build dir for examples build In cross-compilation, the CMAKE_FIND_ROOT_PATH will have path to the host Qt and examples build will pick up wrong Qt6Config.cmake unless the build dir path is prepended. Pick-to: 6.4 6.3 6.2 Fixes: QTBUG-104270 Change-Id: I7fc7499369a2e5446e1c5257155f81c72716fef7 Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-06 13:00:14 +00:00
list(PREPEND CMAKE_PREFIX_PATH "${QT_BUILD_DIR}/${INSTALL_LIBDIR}/cmake")
CMake: Fix configuration of CMake tests in-build-tree Qt6 package was not found the tests were configured in-tree as opposed to standalone tests. Use the same trick we do for building examples in-tree. Specify the path to the build tree packages, and don't create targets. Amends 96e3ee06598d00e7155f3f8574759ea658a134e5 Change-Id: Ia60de416ce0afff5bd40be8c0c6e3c7898fd7ebf Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-20 15:12:45 +00:00
# Make sure the CMake config files do not recreate the already-existing targets
set(QT_NO_CREATE_TARGETS TRUE)
endmacro()
Fix Standalone Example build when crosscompiling Added qt_examples_begin() and qt_examples_end() macros to setup the example list so it can be re-used in other projects. When cross-compiling, we also need to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH in order for find_package() to work correctly. Removed support for building the whole qtbase/examples folder as a standalone project. Building examples is only supported when building the whole of qtbase (qtbase + examples together) or each individual example is built separately against an installed Qt version. Change-Id: I9d26b94b48b95af230b76ab618becb21d2d45581 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 11:08:41 +00:00
macro(qt_examples_build_begin)
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
set(options EXTERNAL_BUILD)
set(singleOpts "")
set(multiOpts DEPENDS)
cmake_parse_arguments(arg "${options}" "${singleOpts}" "${multiOpts}" ${ARGN})
Disable Unity Build for Examples Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I20999512e557db618c14e36d62317680bc17c43a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-22 14:35:24 +00:00
set(CMAKE_UNITY_BUILD OFF)
CMake: Deduce install prefix of example in qt_internal_add_example We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:27:58 +00:00
# Use by qt_internal_add_example.
set(QT_EXAMPLE_BASE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
CMake: Allow opting out of building examples as ExternalProjects We default to configuring examples as separate ExternalProjects when using a developer / non-prefix Qt build. This ensures we test that the examples configure successfully without the pollution of the main Qt build (e.g. already found packages). One down-side of this is that a developer's IDE doesn't see these example targets, unless each project is loaded into the IDE separately. This is cumbersome to do when refactoring or renaming code across multiple example projects. Allow configuring the example projects as part of the main Qt build by setting QT_BUILD_EXAMPLES_AS_EXTERNAL to FALSE when configuring Qt. Save the value of the variable in QtBuildInternalsExtra.cmake.in so it's propagated to leaf repositories as well. Amends dab8f64b6d5d4241b678d0227355858071376496 Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Task-number: QTBUG-90820 Task-number: QTBUG-94608 Task-number: QTBUG-96232 Task-number: QTCREATORBUG-26168 Pick-to: 6.2 Change-Id: Ie1f724f74365b3a788b04c3fffe9eb2d0611dd50 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-09-03 15:08:50 +00:00
if(arg_EXTERNAL_BUILD AND QT_BUILD_EXAMPLES_AS_EXTERNAL)
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
# Examples will be built using ExternalProject.
CMake: Relax example dependencies to be per-repo When doing a top-level build with ExternalProject examples, it doesn't make sense to make qtbase examples depend on e.g. qtdeclarative plugins. Instead the qtbase example should only depend on plugins built in qtbase. Create per-repo custom targets that depend on all plugins built within that particular repo. Create an additional per-repo target which depends on all plugins built in that repo, as well as plugins from dependent repos. Use the latter as a dependency for examples built as part of the current repo. Repo dependencies are parsed from dependencies.yaml. Pick-to: 6.5 Fixes: QTBUG-110913 Change-Id: I149860cc549caf53271c9ea296eb7bac2a663715 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-02-06 15:51:40 +00:00
# We depend on all plugins built as part of the current repo as well as current repo's
# dependencies plugins, to prevent opportunities for
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
# weird errors associated with loading out-of-date plugins from
CMake: Don't make example external projects depend on tests Only depend on the ${project}_src and ${project}_tools targets. This might exclude some non-obivous target dependencies, but we can adjust that if needed. This reduces the build.ninja file of qtbase + qtsvg form 341MB to 41MB when configuring with tests and examples, as well as reduces the processing time of calling ninja. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 Change-Id: I2860d8ae89728f33f6b73fede1335cd6d6290f78 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-06-16 12:56:13 +00:00
# unrelated Qt modules.
# We also depend on all targets from this repo's src and tools subdirectories
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
# to ensure that we've built anything that a find_package() call within
# an example might use. Projects can add further dependencies if needed,
# but that should rarely be necessary.
CMake: Relax example dependencies to be per-repo When doing a top-level build with ExternalProject examples, it doesn't make sense to make qtbase examples depend on e.g. qtdeclarative plugins. Instead the qtbase example should only depend on plugins built in qtbase. Create per-repo custom targets that depend on all plugins built within that particular repo. Create an additional per-repo target which depends on all plugins built in that repo, as well as plugins from dependent repos. Use the latter as a dependency for examples built as part of the current repo. Repo dependencies are parsed from dependencies.yaml. Pick-to: 6.5 Fixes: QTBUG-110913 Change-Id: I149860cc549caf53271c9ea296eb7bac2a663715 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-02-06 15:51:40 +00:00
set(QT_EXAMPLE_DEPENDENCIES ${qt_repo_plugins_recursive} ${arg_DEPENDS})
CMake: Don't make example external projects depend on tests Only depend on the ${project}_src and ${project}_tools targets. This might exclude some non-obivous target dependencies, but we can adjust that if needed. This reduces the build.ninja file of qtbase + qtsvg form 341MB to 41MB when configuring with tests and examples, as well as reduces the processing time of calling ninja. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 Change-Id: I2860d8ae89728f33f6b73fede1335cd6d6290f78 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-06-16 12:56:13 +00:00
if(TARGET ${qt_repo_targets_name}_src)
CMake: Work around AUTOUIC Ninja Multi-Config issue with EP examples AUTOUIC doesn't handle relative paths to .ui files in parent directories when using Ninja Multi-Config. The designer tool in qttools has such a ui file. This leads to the following error when trying to build qttools together with examples as ExternalProjects and Ninja Multi-Config: ninja: error: 'src/designer/src/designer/designer_autogen/ include_Debug/ui_preferencesdialog.h', needed by 'src/designer/src/designer/designer_autogen:Debug', missing and no known rule to make it Until cmake is fixed, we can work around the issue by not adding designer as a dependency when building EP examples, because no example tries to use the app. We can't exclude all apps from example dependencies because some modules use qt_internal_add_app for tools as well, which are called from public CMake API and also examples. An example of this is qtapplicationmanager. Given that we can't exclude all apps, introduce a function to allow skipping single targets when building EP examples. This will allow excluding designer specifically. The examples will now depend on a new ${repo}_src_for_examples target rather than ${repo}_src, which will exclude skipped targets. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Task-number: QTBUG-110369 Change-Id: I2f900253bbf7bac917f2293ef604ab3ea8f298e1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2023-01-19 17:55:58 +00:00
list(APPEND QT_EXAMPLE_DEPENDENCIES ${qt_repo_targets_name}_src_for_examples)
CMake: Don't make example external projects depend on tests Only depend on the ${project}_src and ${project}_tools targets. This might exclude some non-obivous target dependencies, but we can adjust that if needed. This reduces the build.ninja file of qtbase + qtsvg form 341MB to 41MB when configuring with tests and examples, as well as reduces the processing time of calling ninja. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 Change-Id: I2860d8ae89728f33f6b73fede1335cd6d6290f78 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-06-16 12:56:13 +00:00
endif()
if(TARGET ${qt_repo_targets_name}_tools)
list(APPEND QT_EXAMPLE_DEPENDENCIES ${qt_repo_targets_name}_tools)
endif()
CMake: Be precise about EXTERNAL_BUILD check when building examples This change allows temporarily removing the EXTERNAL_BUILD option in a qt repo examples project to check how the examples behave in a non-external project build, without forcing the developer to use a prefix build. Useful to compare behavior until we've ported over prefix builds to use EXTERNAL_BUILD. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Change-Id: I29b834bb5f00e1e93966caae6f816faedba76b76 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-31 11:52:19 +00:00
set(QT_IS_EXTERNAL_EXAMPLES_BUILD TRUE)
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
string(TOLOWER ${PROJECT_NAME} project_name_lower)
if(NOT TARGET examples)
if(QT_BUILD_EXAMPLES_BY_DEFAULT)
add_custom_target(examples ALL)
else()
add_custom_target(examples)
endif()
endif()
if(NOT TARGET examples_${project_name_lower})
add_custom_target(examples_${project_name_lower})
add_dependencies(examples examples_${project_name_lower})
endif()
include(ExternalProject)
else()
# This repo has not yet been updated to build examples in a separate
# build from this main build, or we can't use that arrangement yet.
# Build them directly as part of the main build instead for backward
# compatibility.
if(NOT BUILD_SHARED_LIBS)
# Ordinarily, it would be an error to call return() from within a
# macro(), but in this case we specifically want to return from the
# caller's scope if we are doing a static build and the project
# isn't building examples in a separate build from the main build.
# Configuring static builds requires tools that are not available
# until build time.
return()
endif()
if(NOT QT_BUILD_EXAMPLES_BY_DEFAULT)
set_directory_properties(PROPERTIES EXCLUDE_FROM_ALL TRUE)
endif()
endif()
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
# TODO: Change this to TRUE when all examples in all repos are ported to use
# qt_internal_add_example.
# We shouldn't need to call qt_internal_set_up_build_dir_package_paths when
# QT_IS_EXTERNAL_EXAMPLES_BUILD is TRUE.
# Due to not all examples being ported, if we don't
# call qt_internal_set_up_build_dir_package_paths -> set(QT_NO_CREATE_TARGETS TRUE) we'll get
# CMake configuration errors saying we redefine Qt targets because we both build them and find
# them as part of find_package.
set(__qt_all_examples_ported_to_external_projects FALSE)
Fix examples find_package calls to work in prefix builds To build examples as part of a non-installed Qt prefix build, not-yet-installed Config files need to be found by find_package() calls inside example projects. Facilitate that by propagating the CMAKE_PREFIX_PATH and QT_EXAMPLES_CMAKE_PREFIX_PATH paths in all relevant find_package() calls where NO_DEFAULT_PATH is used. Also adjust the inclusion of the QtFeature.cmake file to be relative to the qt6 directory, rather than the current list directory. This is needed to successfully find the file when parsing a Config file from a non-installed build directory. Change-Id: I36031279628f1f7741d8f4d7571484a6545227f7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-19 11:46:37 +00:00
# Examples that are built as part of the Qt build need to use the CMake config files from the
# build dir, because they are not installed yet in a prefix build.
CMake: prepend build dir for examples build In cross-compilation, the CMAKE_FIND_ROOT_PATH will have path to the host Qt and examples build will pick up wrong Qt6Config.cmake unless the build dir path is prepended. Pick-to: 6.4 6.3 6.2 Fixes: QTBUG-104270 Change-Id: I7fc7499369a2e5446e1c5257155f81c72716fef7 Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-06 13:00:14 +00:00
# Prepending to CMAKE_PREFIX_PATH helps find the initial Qt6Config.cmake.
CMake: Rename QT_EXAMPLES_CMAKE_PREFIX_PATH ...to QT_BUILD_CMAKE_PREFIX_PATH, because the variable is now used for examples and tests. Change-Id: Ie6d32a0c99f46407f2771e12638456078c59fb18 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-23 08:11:15 +00:00
# Prepending to QT_BUILD_CMAKE_PREFIX_PATH helps find components of Qt6, because those
Fix examples find_package calls to work in prefix builds To build examples as part of a non-installed Qt prefix build, not-yet-installed Config files need to be found by find_package() calls inside example projects. Facilitate that by propagating the CMAKE_PREFIX_PATH and QT_EXAMPLES_CMAKE_PREFIX_PATH paths in all relevant find_package() calls where NO_DEFAULT_PATH is used. Also adjust the inclusion of the QtFeature.cmake file to be relative to the qt6 directory, rather than the current list directory. This is needed to successfully find the file when parsing a Config file from a non-installed build directory. Change-Id: I36031279628f1f7741d8f4d7571484a6545227f7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-09-19 11:46:37 +00:00
# find_package calls use NO_DEFAULT_PATH, and thus CMAKE_PREFIX_PATH is ignored.
CMake: prepend build dir for examples build In cross-compilation, the CMAKE_FIND_ROOT_PATH will have path to the host Qt and examples build will pick up wrong Qt6Config.cmake unless the build dir path is prepended. Pick-to: 6.4 6.3 6.2 Fixes: QTBUG-104270 Change-Id: I7fc7499369a2e5446e1c5257155f81c72716fef7 Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-06 13:00:14 +00:00
# Prepending to CMAKE_FIND_ROOT_PATH ensures the components are found while cross-compiling
CMake: Don't rely on CMAKE_FIND_ROOT_PATH_MODE_PACKAGE for examples We shouldn't set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH when cross-building examples without ExternalProjects. Instead append the $build_tree_prefix to CMAKE_FIND_ROOT_PATH and $build_tree_prefix/lib/cmake to QT_EXAMPLES_CMAKE_PREFIX_PATH to circumvent the usual CMake path-rerooting issue. This ensures that the build-tree Config files are found by the in-tree find_package calls when cross-building examples. Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Change-Id: I4e31f0bf3dbfeb4339823fe09addda3ae83f12c3 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-02-03 13:13:25 +00:00
# without setting CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH.
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
if(NOT QT_IS_EXTERNAL_EXAMPLES_BUILD OR NOT __qt_all_examples_ported_to_external_projects)
qt_internal_set_up_build_dir_package_paths()
CMake: prepend build dir for examples build In cross-compilation, the CMAKE_FIND_ROOT_PATH will have path to the host Qt and examples build will pick up wrong Qt6Config.cmake unless the build dir path is prepended. Pick-to: 6.4 6.3 6.2 Fixes: QTBUG-104270 Change-Id: I7fc7499369a2e5446e1c5257155f81c72716fef7 Reviewed-by: Michal Klocek <michal.klocek@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-06 13:00:14 +00:00
list(PREPEND CMAKE_FIND_ROOT_PATH "${QT_BUILD_DIR}")
CMake: Rename QT_EXAMPLES_CMAKE_PREFIX_PATH ...to QT_BUILD_CMAKE_PREFIX_PATH, because the variable is now used for examples and tests. Change-Id: Ie6d32a0c99f46407f2771e12638456078c59fb18 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-23 08:11:15 +00:00
list(PREPEND QT_BUILD_CMAKE_PREFIX_PATH "${QT_BUILD_DIR}/${INSTALL_LIBDIR}/cmake")
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
endif()
CMake: Handle automatic rpath embedding correctly Instead of using CMAKE_INSTALL_RPATH to embed an absolute path to prefix/libdir into all targets, use the more sophisticated aproach that qmake does. For certain targets (modules, plugins, tools) use relative rpaths. Otherwise embed absolute paths (examples, regular binaries). Installed tests currently have no rpaths. On certain platforms rpaths are not used (Windows, Android, iOS / uikit). Frameworks, app bundles and shallow bundles should also be handled correctly. Additional rpaths can be provided via QT_EXTRA_RPATHS variable (similar to the -R option that configure takes). Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF or QT_DISABLE_RPATH=ON. Note that installed examples are not relocatable at the moment (due to always having an absolute path rpath), so this is a missing feature compared to qmake. This is due to missing information on where examples will be installed, so a relative rpath can not be computed. By default a Qt installation is relocatable, so there is no need to pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R . Relative rpaths will have the appropriate 'relative base' prefixed to them (e.g $ORIGIN on linux and @loader_path on darwin platforms). There is currently no support for other platforms that might have a different 'relative base' than the ones mentioned above. Any extra rpaths are saved to BuildInternalsExtra which are re-used when building other repositories. configurejson2cmake modified to include correct conditions for the rpath feature. It's very likely that we will need a new qt_add_internal_app() function for gui apps that are to be installed to prefix/bin. For example for Assistant from qttools. Currently such apps use qt_add_executable(). The distinction is necessary to make sure that relative rpaths are embedded into apps, but not executables (which tests are part of). Amends e835a6853b9c0fb7af32798ed8965de3adf0e15b Task-number: QTBUG-83497 Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-04-15 16:48:26 +00:00
# Because CMAKE_INSTALL_RPATH is empty by default in the repo project, examples need to have
# it set here, so they can run when installed.
# This means that installed examples are not relocatable at the moment. We would need to
# annotate where each example is installed to, to be able to derive a relative rpath, and it
# seems there's no way to query such information from CMake itself.
set(CMAKE_INSTALL_RPATH "${_default_install_rpath}")
CMake: Deduce install prefix of example in qt_internal_add_example We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:27:58 +00:00
install(CODE "
# Backup CMAKE_INSTALL_PREFIX because we're going to change it in each example subdirectory
# and restore it after all examples are processed so that QtFooToolsAdditionalTargetInfo.cmake
# files are installed into the original install prefix.
set(_qt_internal_examples_cmake_install_prefix_backup \"\${CMAKE_INSTALL_PREFIX}\")
")
Fix Standalone Example build when crosscompiling Added qt_examples_begin() and qt_examples_end() macros to setup the example list so it can be re-used in other projects. When cross-compiling, we also need to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH in order for find_package() to work correctly. Removed support for building the whole qtbase/examples folder as a standalone project. Building examples is only supported when building the whole of qtbase (qtbase + examples together) or each individual example is built separately against an installed Qt version. Change-Id: I9d26b94b48b95af230b76ab618becb21d2d45581 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 11:08:41 +00:00
endmacro()
macro(qt_examples_build_end)
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
# We use AUTOMOC/UIC/RCC in the examples. When the examples are part of the
# main build rather than being built in their own separate project, make
# sure we do not fail on a fresh Qt build (e.g. the moc binary won't exist
# yet because it is created at build time).
Fix Standalone Example build when crosscompiling Added qt_examples_begin() and qt_examples_end() macros to setup the example list so it can be re-used in other projects. When cross-compiling, we also need to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH in order for find_package() to work correctly. Removed support for building the whole qtbase/examples folder as a standalone project. Building examples is only supported when building the whole of qtbase (qtbase + examples together) or each individual example is built separately against an installed Qt version. Change-Id: I9d26b94b48b95af230b76ab618becb21d2d45581 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 11:08:41 +00:00
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
# This function gets all targets below this directory (excluding custom targets and aliases)
Fix Standalone Example build when crosscompiling Added qt_examples_begin() and qt_examples_end() macros to setup the example list so it can be re-used in other projects. When cross-compiling, we also need to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH in order for find_package() to work correctly. Removed support for building the whole qtbase/examples folder as a standalone project. Building examples is only supported when building the whole of qtbase (qtbase + examples together) or each individual example is built separately against an installed Qt version. Change-Id: I9d26b94b48b95af230b76ab618becb21d2d45581 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 11:08:41 +00:00
function(get_all_targets _result _dir)
get_property(_subdirs DIRECTORY "${_dir}" PROPERTY SUBDIRECTORIES)
foreach(_subdir IN LISTS _subdirs)
get_all_targets(${_result} "${_subdir}")
endforeach()
get_property(_sub_targets DIRECTORY "${_dir}" PROPERTY BUILDSYSTEM_TARGETS)
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
set(_real_targets "")
if(_sub_targets)
foreach(__target IN LISTS _sub_targets)
get_target_property(target_type ${__target} TYPE)
if(NOT target_type STREQUAL "UTILITY" AND NOT target_type STREQUAL "ALIAS")
list(APPEND _real_targets ${__target})
endif()
endforeach()
endif()
set(${_result} ${${_result}} ${_real_targets} PARENT_SCOPE)
Fix Standalone Example build when crosscompiling Added qt_examples_begin() and qt_examples_end() macros to setup the example list so it can be re-used in other projects. When cross-compiling, we also need to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH in order for find_package() to work correctly. Removed support for building the whole qtbase/examples folder as a standalone project. Building examples is only supported when building the whole of qtbase (qtbase + examples together) or each individual example is built separately against an installed Qt version. Change-Id: I9d26b94b48b95af230b76ab618becb21d2d45581 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 11:08:41 +00:00
endfunction()
get_all_targets(targets "${CMAKE_CURRENT_SOURCE_DIR}")
foreach(target ${targets})
cmake: Init uic only if Qt::Widgets is a target Otherwise we get errors like the following in non-gui projects: Error evaluating generator expression: $<TARGET_FILE:Qt6::uic> No target "Qt6::uic" Change-Id: I8a3a6f8ec5e5c1c3d1f73369c5739a321c64bfbb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-09-20 12:18:17 +00:00
qt_autogen_tools(${target} ENABLE_AUTOGEN_TOOLS "moc" "rcc")
if(TARGET Qt::Widgets)
qt_autogen_tools(${target} ENABLE_AUTOGEN_TOOLS "uic")
endif()
Improve the internal handling of unity build - Removed the NO_UNITY_BUILD argument from commands that disable it by default. - Add a warning in case NO_UNITY_BUILD or NO_UNITY_BUILD_SOURCES is being used where it is already disabled, e.g., qt_internal_add_test - Exclude all sources of a target from unity build if NO_UNITY_BUILD is set on the target. This sounds a bit harsh, but I have noticed that sometimes the same source file can be included somewhere else, and some unexpected collision may occur. - qt_examples_build_end excludes all its examples from the unity build. - qt_build_test now sets the CMAKE_UNITY_BUILD to OFF before configuring the tests, and restore its value when done. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ia42e7dd5a5bfb151db241deb639325720fd91eec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-09 13:53:14 +00:00
set_target_properties(${target} PROPERTIES UNITY_BUILD OFF)
Fix Standalone Example build when crosscompiling Added qt_examples_begin() and qt_examples_end() macros to setup the example list so it can be re-used in other projects. When cross-compiling, we also need to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH in order for find_package() to work correctly. Removed support for building the whole qtbase/examples folder as a standalone project. Building examples is only supported when building the whole of qtbase (qtbase + examples together) or each individual example is built separately against an installed Qt version. Change-Id: I9d26b94b48b95af230b76ab618becb21d2d45581 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 11:08:41 +00:00
endforeach()
CMake: Deduce install prefix of example in qt_internal_add_example We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:27:58 +00:00
install(CODE "
# Restore backed up CMAKE_INSTALL_PREFIX.
set(CMAKE_INSTALL_PREFIX \"\${_qt_internal_examples_cmake_install_prefix_backup}\")
")
Disable Unity Build for Examples Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I20999512e557db618c14e36d62317680bc17c43a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-03-22 14:35:24 +00:00
set(CMAKE_UNITY_BUILD ${QT_UNITY_BUILD})
Fix Standalone Example build when crosscompiling Added qt_examples_begin() and qt_examples_end() macros to setup the example list so it can be re-used in other projects. When cross-compiling, we also need to set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH in order for find_package() to work correctly. Removed support for building the whole qtbase/examples folder as a standalone project. Building examples is only supported when building the whole of qtbase (qtbase + examples together) or each individual example is built separately against an installed Qt version. Change-Id: I9d26b94b48b95af230b76ab618becb21d2d45581 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-06 11:08:41 +00:00
endmacro()
CMake: Allow usage of QtStandaloneTestTemplateProject as package component Currently in order to compile a Qt6 test standalone one needs to use the qt-cmake-standalone-test script which will load the Qt6BuildInternals/QtStandaloneTestTemplateProject/CMakeLists.txt project with the current test source directory to create a complete CMake project. This commit will allow a test to have these lines at top: cmake_minimum_required(VERSION 3.16) if (NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT) project(a_qt_test LANGUAGES C CXX ASM) find_package(Qt6BuildInternals COMPONENTS STANDALONE_TEST) endif() and be standalone and work with any IDE capable of loading CMake projects. Fixes: QTCREATORBUG-25389 Pick-to: 6.1 Change-Id: If3f878b7e560a8bfbb604a8f1aa30b7962742e66 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-21 17:48:37 +00:00
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
# Allows building an example either as an ExternalProject or in-tree with the Qt build.
# Also allows installing the example sources.
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
function(qt_internal_add_example subdir)
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
# Pre-compute unique example name based on the subdir, in case of target name clashes.
qt_internal_get_example_unique_name(unique_example_name "${subdir}")
# QT_INTERNAL_NO_CONFIGURE_EXAMPLES is not meant to be used by Qt builders, it's here for faster
# testing of the source installation code path for build system engineers.
if(NOT QT_INTERNAL_NO_CONFIGURE_EXAMPLES)
if(NOT QT_IS_EXTERNAL_EXAMPLES_BUILD)
qt_internal_add_example_in_tree("${subdir}")
else()
qt_internal_add_example_external_project("${subdir}"
NAME "${unique_example_name}")
endif()
endif()
if(QT_INSTALL_EXAMPLES_SOURCES)
string(TOLOWER ${PROJECT_NAME} project_name_lower)
qt_internal_install_example_sources("${subdir}"
NAME "${unique_example_name}"
REPO_NAME "${project_name_lower}")
endif()
endfunction()
# Gets the install prefix where an example should be installed.
# Used for computing the final installation path.
function(qt_internal_get_example_install_prefix out_var)
# Allow customizing the installation path of the examples. Will be used in CI.
if(QT_INTERNAL_EXAMPLES_INSTALL_PREFIX)
set(qt_example_install_prefix "${QT_INTERNAL_EXAMPLES_INSTALL_PREFIX}")
CMake: Split qt_internal_add_example into two functions One for building using ExternalProject_Add and one when examples are built in-tree by calling add_subdirectory directly. Pick-to: 6.2 6.3 Change-Id: If4c5301163aefed9f15148a70a8f7014bc817ac0 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-12-14 14:48:34 +00:00
else()
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
set(qt_example_install_prefix "${CMAKE_INSTALL_PREFIX}/${INSTALL_EXAMPLESDIR}")
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
endif()
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
file(TO_CMAKE_PATH "${qt_example_install_prefix}" qt_example_install_prefix)
set(${out_var} "${qt_example_install_prefix}" PARENT_SCOPE)
CMake: Split qt_internal_add_example into two functions One for building using ExternalProject_Add and one when examples are built in-tree by calling add_subdirectory directly. Pick-to: 6.2 6.3 Change-Id: If4c5301163aefed9f15148a70a8f7014bc817ac0 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-12-14 14:48:34 +00:00
endfunction()
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
# Gets the install prefix where an example's sources should be installed.
# Used for computing the final installation path.
function(qt_internal_get_examples_sources_install_prefix out_var)
# Allow customizing the installation path of the examples source specifically.
if(QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX)
set(qt_example_install_prefix "${QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX}")
else()
qt_internal_get_example_install_prefix(qt_example_install_prefix)
endif()
file(TO_CMAKE_PATH "${qt_example_install_prefix}" qt_example_install_prefix)
set(${out_var} "${qt_example_install_prefix}" PARENT_SCOPE)
endfunction()
# Gets the relative path of an example, relative to the current repo's examples source dir.
# QT_EXAMPLE_BASE_DIR is meant to be already set in a parent scope.
function(qt_internal_get_example_rel_path out_var subdir)
CMake: Deduce install prefix of example in qt_internal_add_example We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:27:58 +00:00
file(RELATIVE_PATH example_rel_path
"${QT_EXAMPLE_BASE_DIR}" "${CMAKE_CURRENT_SOURCE_DIR}/${subdir}")
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
set(${out_var} "${example_rel_path}" PARENT_SCOPE)
endfunction()
# Gets the install path where an example should be installed.
function(qt_internal_get_example_install_path out_var subdir)
qt_internal_get_example_install_prefix(qt_example_install_prefix)
qt_internal_get_example_rel_path(example_rel_path "${subdir}")
set(example_install_path "${qt_example_install_prefix}/${example_rel_path}")
set(${out_var} "${example_install_path}" PARENT_SCOPE)
endfunction()
# Gets the install path where an example's sources should be installed.
function(qt_internal_get_examples_sources_install_path out_var subdir)
qt_internal_get_examples_sources_install_prefix(qt_example_install_prefix)
qt_internal_get_example_rel_path(example_rel_path "${subdir}")
set(example_install_path "${qt_example_install_prefix}/${example_rel_path}")
set(${out_var} "${example_install_path}" PARENT_SCOPE)
endfunction()
# Get the unique name of an example project based on its subdir or explicitly given name.
# Makes the name unique by appending a short sha1 hash of the relative path of the example
# if a target of the same name already exist.
function(qt_internal_get_example_unique_name out_var subdir)
qt_internal_get_example_rel_path(example_rel_path "${subdir}")
set(name "${subdir}")
# qtdeclarative has calls like qt_internal_add_example(imagine/automotive)
# so passing a nested subdirectory. Custom targets (and thus ExternalProjects) can't contain
# slashes, so extract the last part of the path to be used as a name.
if(name MATCHES "/")
string(REPLACE "/" ";" exploded_path "${name}")
list(POP_BACK exploded_path last_dir)
if(NOT last_dir)
message(FATAL_ERROR "Example subdirectory must have a name.")
else()
set(name "${last_dir}")
endif()
endif()
CMake: Deduce install prefix of example in qt_internal_add_example We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:27:58 +00:00
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
# Likely a clash with an example subdir ExternalProject custom target of the same name in a
# top-level build.
if(TARGET "${name}")
string(SHA1 rel_path_hash "${example_rel_path}")
string(SUBSTRING "${rel_path_hash}" 0 4 short_hash)
set(name "${name}-${short_hash}")
endif()
set(${out_var} "${name}" PARENT_SCOPE)
endfunction()
# Use old non-ExternalProject approach, aka build in-tree with the Qt build.
function(qt_internal_add_example_in_tree subdir)
CMake: Deduce install prefix of example in qt_internal_add_example We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:27:58 +00:00
# Unset the default CMAKE_INSTALL_PREFIX that's generated in
# ${CMAKE_CURRENT_BINARY_DIR}/cmake_install.cmake
# so we can override it with a different value in
# ${CMAKE_CURRENT_BINARY_DIR}/${subdir}/cmake_install.cmake
#
install(CODE "
# Unset the CMAKE_INSTALL_PREFIX in the current cmake_install.cmake file so that it can be
# overridden in the included add_subdirectory-specific cmake_install.cmake files instead.
unset(CMAKE_INSTALL_PREFIX)
")
# Override the install prefix in the subdir cmake_install.cmake, so that
# relative install(TARGETS DESTINATION) calls in example projects install where we tell them to.
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
qt_internal_get_example_install_path(example_install_path "${subdir}")
set(CMAKE_INSTALL_PREFIX "${example_install_path}")
CMake: Deduce install prefix of example in qt_internal_add_example We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:27:58 +00:00
# Make sure unclean example projects have their INSTALL_EXAMPLEDIR set to "."
# Won't have any effect on example projects that don't use INSTALL_EXAMPLEDIR.
# This plus the install prefix above takes care of installing examples where we want them to
# be installed, while allowing us to remove INSTALL_EXAMPLEDIR code in each example
# incrementally.
# TODO: Remove once all repositories use qt_internal_add_example instead of add_subdirectory.
set(QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT ON)
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
add_subdirectory(${subdir})
CMake: Split qt_internal_add_example into two functions One for building using ExternalProject_Add and one when examples are built in-tree by calling add_subdirectory directly. Pick-to: 6.2 6.3 Change-Id: If4c5301163aefed9f15148a70a8f7014bc817ac0 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-12-14 14:48:34 +00:00
endfunction()
function(qt_internal_add_example_external_project subdir)
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
set(options "")
set(singleOpts NAME)
set(multiOpts "")
cmake_parse_arguments(PARSE_ARGV 1 arg "${options}" "${singleOpts}" "${multiOpts}")
Fix running CMake test projects in prefix builds Consider the following situation: There are CMake tests in qttools/tests/auto/cmake that configure and build CMake test projects, essentially as external projects. One of those test projects does find_package(Qt6 COMPONENTS LinguistTools). This call fails in a prefix build, because Qt6LinguistToolsConfig.cmake is not installed yet. It merely exists in qttools-build/lib/cmake/Qt6LinguistTools. We must adjust CMAKE_PREFIX_PATH to be able to find Qt6LinguistTools. We also must adjust QT_ADDITIONAL_PACKAGES_PREFIX_PATH to be able to find the LinguistTools component of the Qt6 package. Use the prefixes setup from the support for building examples as external projects and use it for CMake test projects as well. Task-number: QTBUG-84884 Change-Id: I1bd5d5084cf931196bdb014cd75ca7578cd9decb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-08-17 15:14:09 +00:00
_qt_internal_get_build_vars_for_external_projects(
CMAKE_DIR_VAR qt_cmake_dir
PREFIXES_VAR qt_prefixes
ADDITIONAL_PACKAGES_PREFIXES_VAR qt_additional_packages_prefixes
)
list(APPEND QT_ADDITIONAL_PACKAGES_PREFIX_PATH "${qt_additional_packages_prefixes}")
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
set(vars_to_pass_if_defined)
set(var_defs)
if(QT_HOST_PATH OR CMAKE_CROSSCOMPILING)
list(APPEND var_defs
-DCMAKE_TOOLCHAIN_FILE:FILEPATH=${qt_cmake_dir}/qt.toolchain.cmake
)
else()
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
list(PREPEND CMAKE_PREFIX_PATH ${qt_prefixes})
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
# Setting CMAKE_SYSTEM_NAME affects CMAKE_CROSSCOMPILING, even if it is
# set to the same as the host, so it should only be set if it is different.
# See https://gitlab.kitware.com/cmake/cmake/-/issues/21744
if(NOT DEFINED CMAKE_TOOLCHAIN_FILE AND
NOT CMAKE_SYSTEM_NAME STREQUAL CMAKE_HOST_SYSTEM_NAME)
list(APPEND vars_to_pass_if_defined CMAKE_SYSTEM_NAME:STRING)
endif()
endif()
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
# In multi-config mode by default we exclude building tools for configs other than the main one.
# Trying to build an example in a non-default config using the non-installed
# QtFooConfig.cmake files would error out saying moc is not found.
# Make sure to build examples only with the main config.
# When users build an example against an installed Qt they won't have this problem because
# the generated non-main QtFooTargets-$<CONFIG>.cmake file is empty and doesn't advertise
# a tool that is not there.
if(QT_GENERATOR_IS_MULTI_CONFIG)
set(CMAKE_CONFIGURATION_TYPES "${QT_MULTI_CONFIG_FIRST_CONFIG}")
endif()
# We need to pass the modified CXX flags of the parent project so that using sccache works
# properly and doesn't error out due to concurrent access to the pdb files.
# See qt_internal_set_up_config_optimizations_like_in_qmake, "/Zi" "/Z7".
if(MSVC AND QT_FEATURE_msvc_obj_debug_info)
qt_internal_get_enabled_languages_for_flag_manipulation(enabled_languages)
set(configs RELWITHDEBINFO DEBUG)
foreach(lang ${enabled_languages})
foreach(config ${configs})
set(flag_var_name "CMAKE_${lang}_FLAGS_${config}")
list(APPEND vars_to_pass_if_defined "${flag_var_name}:STRING")
endforeach()
endforeach()
endif()
CMake: Fix examples to build as external projects when cross-compiling We forwarded the compiler path to the EP but not the flags that might have been set via the CXX environment variable. Make sure to also forward the flags. Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I0fbf9b595f7885014b1f09d158db52e56a3d5243 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-03 16:37:03 +00:00
# When cross-compiling for a qemu target in our CI, we source an environment script
# that sets environment variables like CC and CXX. These are parsed by CMake on initial
# configuration to populate the cache vars CMAKE_${lang}_COMPILER.
# If the environment variable specified not only the compiler path, but also a list of flags
# to pass to the compiler, CMake parses those out into a separate CMAKE_${lang}_COMPILER_ARG1
# cache variable. In such a case, we want to ensure that the external project also sees those
# flags.
# Unfortunately we can't do that by simply forwarding CMAKE_${lang}_COMPILER_ARG1 to the EP
# because it breaks the compiler identification try_compile call, it simply doesn't consider
# the cache var. From what I could gather, it's a limitation of try_compile and the list
# of variables it considers for forwarding.
# To fix this case, we ensure not to pass either cache variable, and let the external project
# and its compiler identification try_compile project pick up the compiler and the flags
# from the environment variables instead.
foreach(lang_as_env_var CC CXX OBJC OBJCXX)
if(lang_as_env_var STREQUAL "CC")
set(lang_as_cache_var "C")
else()
set(lang_as_cache_var "${lang_as_env_var}")
endif()
set(lang_env_value "$ENV{${lang_as_env_var}}")
if(lang_env_value
AND CMAKE_${lang_as_cache_var}_COMPILER
AND CMAKE_${lang_as_cache_var}_COMPILER_ARG1)
# The compiler environment variable is set and specifies a list of extra flags, don't
# forward the compiler cache vars and rely on the environment variable to be picked up
# instead.
else()
list(APPEND vars_to_pass_if_defined "CMAKE_${lang_as_cache_var}_COMPILER:STRING")
endif()
endforeach()
unset(lang_as_env_var)
unset(lang_as_cache_var)
unset(lang_env_value)
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
list(APPEND vars_to_pass_if_defined
CMAKE_BUILD_TYPE:STRING
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
CMAKE_CONFIGURATION_TYPES:STRING
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
CMAKE_PREFIX_PATH:STRING
CMake: Rename QT_EXAMPLES_CMAKE_PREFIX_PATH ...to QT_BUILD_CMAKE_PREFIX_PATH, because the variable is now used for examples and tests. Change-Id: Ie6d32a0c99f46407f2771e12638456078c59fb18 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-23 08:11:15 +00:00
QT_BUILD_CMAKE_PREFIX_PATH:STRING
CMake: Fix cross-building examples in prefix builds as ExternalProjects For examples to successfully find not yet installed Config files in a prefix cross-build, both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH need to be adjusted when toolchain files set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY. Before this change, we lacked two things. 1) If the chain-loaded toolchain file sets CMAKE_FIND_ROOT_PATH (instead of appending), then the initial value of CMAKE_FIND_ROOT_PATH that was passed by ExternalProject's initial cache would be overridden. 2) The prefixes we passed via QT_EXAMPLES_CMAKE_PREFIX_PATH did not end in lib/cmake, to work around the path re-rooting problem in CMake. We can handle both of these points by using QT_ADDITIONAL_PACKAGES_PREFIX_PATH which was introduced for Conan usage. Each value assigned to QT_ADDITIONAL_PACKAGES_PREFIX_PATH gets prepended to CMAKE_FIND_ROOT_PATH by qt.toolchain.cmake AFTER the original toolchain file is chain-loaded. And each value also gets lib/cmake appended and assigned to both CMAKE_PREFIX_PATH and _qt_additional_packages_prefix_paths (used by Qt6Config.cmake.in to work with find_package + NO_DEFAULT_PATH). This is exactly what we need to ensure examples build. Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Change-Id: I11a52457ff795a6661a3a7b68e823e0615d0ce89 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-02-03 13:03:42 +00:00
QT_ADDITIONAL_PACKAGES_PREFIX_PATH:STRING
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
CMAKE_FIND_ROOT_PATH:STRING
BUILD_SHARED_LIBS:BOOL
CMAKE_OSX_ARCHITECTURES:STRING
CMAKE_OSX_DEPLOYMENT_TARGET:STRING
CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_ALLOWED:BOOL
CMAKE_XCODE_ATTRIBUTE_ONLY_ACTIVE_ARCH:BOOL
CMAKE_C_COMPILER_LAUNCHER:STRING
CMAKE_CXX_COMPILER_LAUNCHER:STRING
CMAKE_OBJC_COMPILER_LAUNCHER:STRING
CMAKE_OBJCXX_COMPILER_LAUNCHER:STRING
)
foreach(var_with_type IN LISTS vars_to_pass_if_defined)
string(REPLACE ":" ";" key_as_list "${var_with_type}")
list(GET key_as_list 0 var)
if(NOT DEFINED ${var})
continue()
endif()
# Preserve lists
string(REPLACE ";" "$<SEMICOLON>" varForGenex "${${var}}")
list(APPEND var_defs -D${var_with_type}=${varForGenex})
endforeach()
CMake: Enable debug verbosity for cmake auto tests and EP examples Since e2a0ddbb69640c94b4ee107260a088d5c1c7e273 , if Qt is configured as a non-developer-build, some of the CMake tests that include QtSetup would have their CMAKE_MESSAGE_LOG_LEVEL set to the reduced NOTICE value. Make sure that tests always have a DEBUG level, so that if they fail in the CI, we have more info on what goes wrong. For ExternalProject examples, it is conditional on whether Qt is configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise calling the main ninja without -v will end up cluttering the output a non default log level. Amends e2a0ddbb69640c94b4ee107260a088d5c1c7e273 Pick-to: 6.2 6.3 Change-Id: Icd3b6e0fcc6c73e4b53b6c4a6d8354c96077a050 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-23 13:43:23 +00:00
if(QT_INTERNAL_VERBOSE_EXAMPLES)
list(APPEND var_defs -DCMAKE_MESSAGE_LOG_LEVEL:STRING=DEBUG)
CMake: Enable verbose autogen for cmake auto tests and EP examples So we can see the exact moc invocations when debugging issues in the CI. For ExternalProject examples, it is conditional on whether Qt is configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise calling the main ninja without -v will end up cluttering the output with AUTOGEN output. Pick-to: 6.2 6.3 Change-Id: I6468ab0e461b3be283e2428e3515cae4d5986242 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-23 15:24:16 +00:00
list(APPEND var_defs -DCMAKE_AUTOGEN_VERBOSE:BOOL=TRUE)
CMake: Enable debug verbosity for cmake auto tests and EP examples Since e2a0ddbb69640c94b4ee107260a088d5c1c7e273 , if Qt is configured as a non-developer-build, some of the CMake tests that include QtSetup would have their CMAKE_MESSAGE_LOG_LEVEL set to the reduced NOTICE value. Make sure that tests always have a DEBUG level, so that if they fail in the CI, we have more info on what goes wrong. For ExternalProject examples, it is conditional on whether Qt is configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise calling the main ninja without -v will end up cluttering the output a non default log level. Amends e2a0ddbb69640c94b4ee107260a088d5c1c7e273 Pick-to: 6.2 6.3 Change-Id: Icd3b6e0fcc6c73e4b53b6c4a6d8354c96077a050 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-23 13:43:23 +00:00
endif()
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
set(deps "")
list(REMOVE_DUPLICATES QT_EXAMPLE_DEPENDENCIES)
foreach(dep IN LISTS QT_EXAMPLE_DEPENDENCIES)
if(TARGET ${dep})
list(APPEND deps ${dep})
endif()
endforeach()
set(independent_args)
cmake_policy(PUSH)
if(POLICY CMP0114)
set(independent_args INDEPENDENT TRUE)
cmake_policy(SET CMP0114 NEW)
endif()
# The USES_TERMINAL_BUILD setting forces the build step to the console pool
# when using Ninja. This has two benefits:
#
# - You see build output as it is generated instead of at the end of the
# build step.
# - Only one task can use the console pool at a time, so it effectively
# serializes all example build steps, thereby preventing CPU
# over-commitment.
#
# If the loss of interactivity is not so important, one can allow CPU
# over-commitment for Ninja builds. This may result in better throughput,
# but is not allowed by default because it can make a machine almost
# unusable while a compilation is running.
set(terminal_args USES_TERMINAL_BUILD TRUE)
if(CMAKE_GENERATOR MATCHES "Ninja")
option(QT_BUILD_EXAMPLES_WITH_CPU_OVERCOMMIT
"Allow CPU over-commitment when building examples (Ninja only)"
)
if(QT_BUILD_EXAMPLES_WITH_CPU_OVERCOMMIT)
set(terminal_args)
endif()
endif()
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
# QT_EXAMPLE_INSTALL_MARKER
# The goal is to install each example project into a directory that keeps the example source dir
# hierarchy, without polluting the example projects with dirty INSTALL_EXAMPLEDIR and
# INSTALL_EXAMPLESDIR usage.
# E.g. ensure qtbase/examples/widgets/widgets/wiggly is installed to
# $qt_example_install_prefix/examples/widgets/widgets/wiggly/wiggly.exe
# $qt_example_install_prefix defaults to ${CMAKE_INSTALL_PREFIX}/${INSTALL_EXAMPLEDIR}
CMake: Allow installing examples outside of the Qt prefix Introduce a new QT_INTERNAL_CUSTOM_INSTALL_DIR variable to allow specifying an 'examples install dir' outside of the Qt prefix. It will be used in a follow-up change to ensure we don't package the example binaries in our CI artifacts (thus saving space). This will be even more important when the examples will contain code to deploy Qt libraries alongside each deployed example (which would significantly increase the package size). Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I06b4a8f9e8c57a712a356bca0f5c351a9362bc30 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-12-16 11:55:07 +00:00
# but can also be set to a custom location.
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
# This needs to work both:
# - when using ExternalProject to build examples
# - when examples are built in-tree as part of Qt (no ExternalProject).
# The reason we want to support the latter is for nicer IDE integration: a can developer can
# work with a Qt repo and its examples using the same build dir.
#
# In both case we have to ensure examples are not accidentally installed to $qt_prefix/bin or
# similar.
#
# Example projects installation matrix.
# 1) ExternalProject + unclean example install rules (INSTALL_EXAMPLEDIR is set) =>
# use _qt_internal_override_example_install_dir_to_dot + ExternalProject_Add's INSTALL_DIR
# using relative_dir from QT_EXAMPLE_BASE_DIR to example_source_dir
#
# 2) ExternalProject + clean example install rules =>
# use ExternalProject_Add's INSTALL_DIR using relative_dir from QT_EXAMPLE_BASE_DIR to
# example_source_dir, _qt_internal_override_example_install_dir_to_dot would be a no-op
#
# 3) in-tree + unclean example install rules (INSTALL_EXAMPLEDIR is set)
# +
# 4) in-tree + clean example install rules =>
# ensure CMAKE_INSTALL_PREFIX is unset in parent cmake_install.cmake file, set non-cache
# CMAKE_INSTALL_PREFIX using relative_dir from QT_EXAMPLE_BASE_DIR to
# example_source_dir, use _qt_internal_override_example_install_dir_to_dot to ensure
# INSTALL_EXAMPLEDIR does not interfere.
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
qt_internal_get_example_install_path(example_install_path "${subdir}")
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
set(ep_binary_dir "${CMAKE_CURRENT_BINARY_DIR}/${subdir}")
CMake: Allow passing -v to ninja when building examples as EPs By default when building ExternalProjects, even if the main ninja invocation has -v passed, that won't be passed to the nested ninja calls. When building examples in the CI, we want to see the full command line invocations. Allow passing -v to the nested EP ninja calls by configuring Qt with -DQT_INTERNAL_VERBOSE_EXAMPLES=ON, which we will use in our CI. We don't want to add -v by default because if the main ninja does not have one, the nested calls will still be verbose. Pick-to: 6.2 6.3 Change-Id: Ifd4b312c6eaa7354e8870f4fb0a77fadf0f33ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-23 16:33:13 +00:00
set(build_command "")
if(QT_INTERNAL_VERBOSE_EXAMPLES AND CMAKE_GENERATOR MATCHES "Ninja")
set(build_command BUILD_COMMAND "${CMAKE_COMMAND}" --build "." -- -v)
endif()
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
ExternalProject_Add(${arg_NAME}
EXCLUDE_FROM_ALL TRUE
CMake: Shorten ExternalProject example project paths Instead of nesting the external project build dir under the current binary dir, place the EP build dir where it would usually be when we use add_subdirectory. Shorten the name of the external project to just ${subdir} instead of using the relative current binary dir path. Place the EP prefix and stamp dirs under a new ${subdir}-ep folder next to the example build dir. Overall this places example executables where you'd usually expect them to be, as well as shortens a bunch of build paths to circumvent path limit issues when building on Windows. Pick-to: 6.2 6.3 Fixes: QTBUG-94608 Task-number: QTBUG-96232 Change-Id: Ifb921c5a6397385e8a914111bf56ee59cda003fd Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-12-14 14:53:15 +00:00
SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}/${subdir}"
PREFIX "${CMAKE_CURRENT_BINARY_DIR}/${subdir}-ep"
STAMP_DIR "${CMAKE_CURRENT_BINARY_DIR}/${subdir}-ep/stamp"
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
BINARY_DIR "${ep_binary_dir}"
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
INSTALL_DIR "${example_install_path}"
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
INSTALL_COMMAND ""
CMake: Allow passing -v to ninja when building examples as EPs By default when building ExternalProjects, even if the main ninja invocation has -v passed, that won't be passed to the nested ninja calls. When building examples in the CI, we want to see the full command line invocations. Allow passing -v to the nested EP ninja calls by configuring Qt with -DQT_INTERNAL_VERBOSE_EXAMPLES=ON, which we will use in our CI. We don't want to add -v by default because if the main ninja does not have one, the nested calls will still be verbose. Pick-to: 6.2 6.3 Change-Id: Ifd4b312c6eaa7354e8870f4fb0a77fadf0f33ab7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-23 16:33:13 +00:00
${build_command}
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
TEST_COMMAND ""
DEPENDS ${deps}
CMAKE_CACHE_ARGS ${var_defs}
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
-DCMAKE_INSTALL_PREFIX:STRING=<INSTALL_DIR>
-DQT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT:BOOL=TRUE
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
${terminal_args}
)
CMake: Build examples as ExternalProjects in prefix builds Change prefix builds to use ExternalProjects to build examples by default. This will affect our CI which only does prefix builds. To make it work, we have to do a few adjustments: - look for Config files in the build-tree (before Qt is installed) - build only one examples with only a single config, even if Qt is a multi-config build - install examples as part of main make install step, rather than as part of the make step (which is the default for EPs) - adjust CXX flags when building with MSVC to ensure we can still use sccache and separate debug info - derive the correct install prefix for each example and pass it to the ExternalProject As a drive-by, add TODOs to address tidiness of the code and corner cases that likely don't work (Conan). Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:56:39 +00:00
# Install the examples when the the user runs 'make install', and not at build time (which is
# the default for ExternalProjects).
install(CODE "\
# Install example from inside ExternalProject into the main build's install prefix.
execute_process(
COMMAND
\"${CMAKE_COMMAND}\" --build \"${ep_binary_dir}\" --target install
)
")
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
# Force configure step to re-run after we configure the main project
set(reconfigure_check_file ${CMAKE_CURRENT_BINARY_DIR}/reconfigure_${arg_NAME}.txt)
file(TOUCH ${reconfigure_check_file})
ExternalProject_Add_Step(${arg_NAME} reconfigure-check
DEPENDERS configure
DEPENDS ${reconfigure_check_file}
${independent_args}
)
CMake: Fix global 'apk' target to apply to Qt EXTERNAL_BUILD examples This means calling 'ninja apk' in a Qt build with examples configured will build all example apks, regardless of whether the examples are built as external projects or in-tree. Fixes: QTBUG-94264 Change-Id: I5c7af0354858898a2e154a6d54fb025e4d81ff80 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
# Create an apk external project step and custom target that invokes the apk target
# within the external project.
# Make the global apk target depend on that custom target.
if(ANDROID)
ExternalProject_Add_Step(${arg_NAME} apk
COMMAND ${CMAKE_COMMAND} --build <BINARY_DIR> --target apk
DEPENDEES configure
EXCLUDE_FROM_MAIN YES
${terminal_args}
)
ExternalProject_Add_StepTargets(${arg_NAME} apk)
if(TARGET apk)
add_dependencies(apk ${arg_NAME}-apk)
endif()
endif()
Build examples in isolated sub-builds using ExternalProject Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-24 06:35:39 +00:00
cmake_policy(POP)
string(TOLOWER ${PROJECT_NAME} project_name_lower)
add_dependencies(examples_${project_name_lower} ${arg_NAME})
endfunction()
CMake: Allow installation of example sources into the Qt prefix In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-08-07 10:15:35 +00:00
function(qt_internal_install_example_sources subdir)
set(options "")
set(single_args NAME REPO_NAME)
set(multi_args "")
cmake_parse_arguments(PARSE_ARGV 1 arg "${options}" "${single_args}" "${multi_args}")
qt_internal_get_examples_sources_install_path(example_install_path "${subdir}")
# The trailing slash is important to avoid duplicate nested directory names.
set(example_source_dir "${subdir}/")
# Allow controlling whether sources should be part of the default install target.
if(QT_INSTALL_EXAMPLES_SOURCES_BY_DEFAULT)
set(exclude_from_all "")
else()
set(exclude_from_all "EXCLUDE_FROM_ALL")
endif()
# Create an install component for all example sources. Can also be part of the default
# install target if EXCLUDE_FROM_ALL is not passed.
install(
DIRECTORY "${example_source_dir}"
DESTINATION "${example_install_path}"
COMPONENT "examples_sources"
USE_SOURCE_PERMISSIONS
${exclude_from_all}
)
# Also create a specific install component just for this repo's examples.
install(
DIRECTORY "${example_source_dir}"
DESTINATION "${example_install_path}"
COMPONENT "examples_sources_${arg_REPO_NAME}"
USE_SOURCE_PERMISSIONS
EXCLUDE_FROM_ALL
)
# Also create a specific install component just for the current example's sources.
install(
DIRECTORY "${example_source_dir}"
DESTINATION "${example_install_path}"
COMPONENT "examples_sources_${arg_NAME}"
USE_SOURCE_PERMISSIONS
EXCLUDE_FROM_ALL
)
endfunction()
CMake: Allow usage of QtStandaloneTestTemplateProject as package component Currently in order to compile a Qt6 test standalone one needs to use the qt-cmake-standalone-test script which will load the Qt6BuildInternals/QtStandaloneTestTemplateProject/CMakeLists.txt project with the current test source directory to create a complete CMake project. This commit will allow a test to have these lines at top: cmake_minimum_required(VERSION 3.16) if (NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT) project(a_qt_test LANGUAGES C CXX ASM) find_package(Qt6BuildInternals COMPONENTS STANDALONE_TEST) endif() and be standalone and work with any IDE capable of loading CMake projects. Fixes: QTCREATORBUG-25389 Pick-to: 6.1 Change-Id: If3f878b7e560a8bfbb604a8f1aa30b7962742e66 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-21 17:48:37 +00:00
if ("STANDALONE_TEST" IN_LIST Qt6BuildInternals_FIND_COMPONENTS)
include(${CMAKE_CURRENT_LIST_DIR}/QtStandaloneTestTemplateProject/Main.cmake)
if (NOT PROJECT_VERSION_MAJOR)
get_property(_qt_major_version TARGET ${QT_CMAKE_EXPORT_NAMESPACE}::Core PROPERTY INTERFACE_QT_MAJOR_VERSION)
set(PROJECT_VERSION ${Qt${_qt_major_version}Core_VERSION})
string(REPLACE "." ";" _qt_core_version_list ${PROJECT_VERSION})
list(GET _qt_core_version_list 0 PROJECT_VERSION_MAJOR)
list(GET _qt_core_version_list 1 PROJECT_VERSION_MINOR)
list(GET _qt_core_version_list 2 PROJECT_VERSION_PATCH)
endif()
endif()
Add the check for linker capabilities to resolve circular dependencies 'ld' only capable to resolve circular dependencies by wrapping the suspected static libraries and objects using --start/end-group arguments. We want to detect if linker is 'ld' at configure time to decide how to link the resource objects if finalizers are not enabled. The qt_config_compile_test function is extended with an extra argument since it's required to pass custom cmake flags to the ld-related test. Pick-to: 6.2 Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-03 11:51:48 +00:00
function(qt_internal_static_link_order_test)
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 17:01:35 +00:00
# The CMake versions greater than 3.21 take care about the resource object files order in a
# linker line, it's expected that all object files are located at the beginning of the linker
# line.
# No need to run the test.
if(CMAKE_VERSION VERSION_LESS 3.21)
Remove target specific flags from the linker capabilities check Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-16 17:24:59 +00:00
__qt_internal_check_link_order_matters(link_order_matters)
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 17:01:35 +00:00
if(link_order_matters)
set(summary_message "no")
else()
set(summary_message "yes")
endif()
Add the check for linker capabilities to resolve circular dependencies 'ld' only capable to resolve circular dependencies by wrapping the suspected static libraries and objects using --start/end-group arguments. We want to detect if linker is 'ld' at configure time to decide how to link the resource objects if finalizers are not enabled. The qt_config_compile_test function is extended with an extra argument since it's required to pass custom cmake flags to the ld-related test. Pick-to: 6.2 Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-03 11:51:48 +00:00
else()
set(summary_message "yes")
endif()
qt_configure_add_summary_entry(TYPE "message"
ARGS "Linker can resolve circular dependencies"
MESSAGE "${summary_message}"
)
endfunction()
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 16:00:39 +00:00
function(qt_internal_check_cmp0099_available)
# Don't care about CMP0099 in CMake versions greater than or equal to 3.21
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.21)
return()
endif()
__qt_internal_check_cmp0099_available(result)
if(result)
set(summary_message "yes")
else()
set(summary_message "no")
endif()
qt_configure_add_summary_entry(TYPE "message"
ARGS "CMake policy CMP0099 is supported"
MESSAGE "${summary_message}"
)
endfunction()
Add the check for linker capabilities to resolve circular dependencies 'ld' only capable to resolve circular dependencies by wrapping the suspected static libraries and objects using --start/end-group arguments. We want to detect if linker is 'ld' at configure time to decide how to link the resource objects if finalizers are not enabled. The qt_config_compile_test function is extended with an extra argument since it's required to pass custom cmake flags to the ld-related test. Pick-to: 6.2 Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-03 11:51:48 +00:00
function(qt_internal_run_common_config_tests)
qt_configure_add_summary_section(NAME "Common build options")
qt_internal_static_link_order_test()
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 16:00:39 +00:00
qt_internal_check_cmp0099_available()
Add the check for linker capabilities to resolve circular dependencies 'ld' only capable to resolve circular dependencies by wrapping the suspected static libraries and objects using --start/end-group arguments. We want to detect if linker is 'ld' at configure time to decide how to link the resource objects if finalizers are not enabled. The qt_config_compile_test function is extended with an extra argument since it's required to pass custom cmake flags to the ld-related test. Pick-to: 6.2 Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-03 11:51:48 +00:00
qt_configure_end_summary_section()
endfunction()
Implement qt_internal_get_file_path_mode for changing the file path mode In cases where we allow symlink, we need to use ABSOLUTE path, and don't resolve the symlink. This function returns ABSOLUTE only if we are on Apple platform, and have QT_ALLOW_SYMLINK_IN_PATHS enabled. While this is mainly to resolve the issue report by Homebrew, it might be useful if a user really want to build with symlink. Pick-to: 6.5 Task-number: QTBUG-113463 Change-Id: Ided141ed8de66cc1d3717ec2719eb703fa7fc589 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-05-09 12:37:33 +00:00
# It is used in QtWebEngine to replace the REALPATH with ABSOLUTE path, which is
# useful for building Qt in Homebrew.
function(qt_internal_get_filename_path_mode out_var)
set(mode REALPATH)
if(APPLE AND QT_ALLOW_SYMLINK_IN_PATHS)
set(mode ABSOLUTE)
endif()
set(${out_var} ${mode} PARENT_SCOPE)
endfunction()
Reference in New Issue Copy Permalink