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

1004 lines
41 KiB
CMake
Raw Normal View History

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
CMake: Bump min required CMake version for shared Qt builds to 3.16 Building a shared library Qt configuration already required a minimum CMake version of 3.16, because we depend on CMake's Autogen.json files which are used for metatype.json file generation. If a lower version was used, a FATAL_ERROR was issued in qt6_extract_metatypes. This change is essentially moving the check to happen earlier in the qtbase configure process. User projects will now /also/ officially require a minimum of 3.16 (up from 3.14). As a consequence, the min/max version policy range that is set in the public QtFooConfig.cmake files is changed from 3.14..3.19 to 3.16..3.20 The upper bound is raised because building and using Qt works fine with all CMake 3.20 policies set to NEW. [ChangeLog][CMake] Building Qt as shared libraries now requires CMake version 3.16 or later. Building user projects with CMake using that Qt installation also requires a CMake version of 3.16 or later. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: I77d2829370f1dfc90b4071bebc8a3ade654e59e6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-06 15:55:30 +00:00
cmake_minimum_required(VERSION 3.16...3.20)
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.
#
# Example output for qtimageformats:
# qtbase;qtshadertools;qtsvg;qtdeclarative;qttools
#
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.
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: 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
if(NOT "${FEATURE_pkg_config}" AND "${INPUT_pkg_config}"
AND NOT "${INPUT_pkg_config}" STREQUAL "undefined")
set(FEATURE_pkg_config ON)
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
# 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()
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_internals_set_up_private_api)
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()
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)
if(NOT (${_type} STREQUAL "UTILITY" OR ${_type} STREQUAL "INTERFACE"))
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}"
DEPENDS ${qt_repo_targets}
COMMENT "Building everything in ${qt_repo_targets_name}/${qt_repo_target_basename}")
list(APPEND qt_repo_target_all "${qt_repo_target_name}")
endif()
endforeach()
if (qt_repo_target_all)
add_custom_target("${qt_repo_targets_name}"
DEPENDS ${qt_repo_target_all}
COMMENT "Building everything in ${qt_repo_targets_name}")
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)
include(CheckLanguage)
set(__qt_required_language_list C CXX)
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
set(__qt_optional_language_list )
# https://gitlab.kitware.com/cmake/cmake/-/issues/20545
if(APPLE)
list(APPEND __qt_optional_language_list OBJC OBJCXX)
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()
foreach(__qt_lang ${__qt_optional_language_list})
check_language(${__qt_lang})
if(CMAKE_${__qt_lang}_COMPILER)
enable_language(${__qt_lang})
endif()
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)
qt_build_internals_set_up_private_api()
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: 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
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)
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()
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()
macro(qt_build_repo_end)
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)
# Delayed actions on some of the Qt targets:
include(QtPostProcess)
# Install the repo-specific cmake find modules.
qt_path_join(__qt_repo_install_dir ${QT_CONFIG_INSTALL_DIR} ${INSTALL_CMAKE_NAMESPACE})
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"
)
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()
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
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()
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)
Merge remote-tracking branch 'origin/wip/qt6' into wip/cmake This changes many different CMake places to mention Qt6 instead of Qt5. Note that some old qt5 cmake config files in corelib are probably not needed anymore, but I still renamed and kept them for now. Change-Id: Ie69e81540386a5af153f76c0242e18d48211bec4
2019-06-14 10:59:07 +00:00
find_package(Qt6 ${PROJECT_VERSION} CONFIG REQUIRED COMPONENTS Test)
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()
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)
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()
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)
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)
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
include("${_qt_build_tests_install_prefix}/${PROJECT_NAME}TestsConfig.cmake" OPTIONAL)
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.
find_package(Qt6 ${PROJECT_VERSION} CONFIG REQUIRED COMPONENTS Test)
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()
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()
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(NOT QT_BUILD_MINIMAL_STATIC_TESTS)
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()
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.
if(QT_WILL_INSTALL)
get_filename_component(clean_config_prefix
"${CMAKE_INSTALL_PREFIX}/${QT_CONFIG_INSTALL_DIR}" ABSOLUTE)
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: quote paths to prevent issues when no install prefix is set Change-Id: Ifa7f1ef70c4893e10cb4ce9a54d8a0806d19be93 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-05 09:05:05 +00:00
"${clean_config_prefix}" "${CMAKE_INSTALL_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)
list(APPEND CMAKE_PREFIX_PATH "${QT_BUILD_DIR}")
# Make sure the CMake config files do not recreate the already-existing targets
set(QT_NO_CREATE_TARGETS TRUE)
set(BACKUP_CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${CMAKE_FIND_ROOT_PATH_MODE_PACKAGE})
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE "BOTH")
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})
# FIXME: Support prefix builds as well
if(arg_EXTERNAL_BUILD AND NOT QT_WILL_INSTALL)
# Examples will be built using ExternalProject.
# We always depend on all plugins so as to prevent opportunities for
# 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: 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
set(QT_EXAMPLE_DEPENDENCIES qt_plugins ${arg_DEPENDS})
if(TARGET ${qt_repo_targets_name}_src)
list(APPEND QT_EXAMPLE_DEPENDENCIES ${qt_repo_targets_name}_src)
endif()
if(TARGET ${qt_repo_targets_name}_tools)
list(APPEND QT_EXAMPLE_DEPENDENCIES ${qt_repo_targets_name}_tools)
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(QT_EXAMPLE_BASE_DIR ${CMAKE_CURRENT_SOURCE_DIR})
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()
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.
# Appending to CMAKE_PREFIX_PATH helps find the initial Qt6Config.cmake.
# Appending to QT_EXAMPLES_CMAKE_PREFIX_PATH helps find components of Qt6, because those
# find_package calls use NO_DEFAULT_PATH, and thus CMAKE_PREFIX_PATH is ignored.
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
qt_internal_set_up_build_dir_package_paths()
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
list(APPEND QT_EXAMPLES_CMAKE_PREFIX_PATH "${QT_BUILD_DIR}")
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: Add qt6_add_plugin public API This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-21 11:28:57 +00:00
set(QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY TRUE)
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()
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()
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ${BACKUP_CMAKE_FIND_ROOT_PATH_MODE_PACKAGE})
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
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)
# FIXME: Support building examples externally for prefix builds as well.
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
if(NOT QT_IS_EXTERNAL_EXAMPLES_BUILD)
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
# Use old non-external approach
add_subdirectory(${subdir} ${ARGN})
return()
endif()
set(options "")
set(singleOpts NAME)
set(multiOpts "")
cmake_parse_arguments(PARSE_ARGV 1 arg "${options}" "${singleOpts}" "${multiOpts}")
if(NOT arg_NAME)
file(RELATIVE_PATH rel_path ${QT_EXAMPLE_BASE_DIR} ${CMAKE_CURRENT_SOURCE_DIR}/${subdir})
string(REPLACE "/" "_" arg_NAME "${rel_path}")
endif()
if(QtBase_BINARY_DIR)
# Always use the copy in the build directory, even for prefix builds.
# We may build examples without installing, so we can't use the
# install or staging area.
set(qt_cmake_dir ${QtBase_BINARY_DIR}/lib/cmake/${QT_CMAKE_EXPORT_NAMESPACE})
else()
# This is a per-repo build that isn't the qtbase repo, so we know that
# qtbase was found via find_package() and Qt6_DIR must be set
set(qt_cmake_dir ${${QT_CMAKE_EXPORT_NAMESPACE}_DIR})
endif()
set(vars_to_pass_if_defined)
set(var_defs)
if(QT_HOST_PATH OR CMAKE_CROSSCOMPILING)
# Android NDK forces CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY, so we
# can't rely on this setting here making it through to the example
# project.
# TODO: We should probably leave CMAKE_FIND_ROOT_PATH_MODE_PACKAGE
# alone. It may be a leftover from earlier methods that are no
# longer used or that no longer need this.
list(APPEND var_defs
-DCMAKE_TOOLCHAIN_FILE:FILEPATH=${qt_cmake_dir}/qt.toolchain.cmake
-DCMAKE_FIND_ROOT_PATH_MODE_PACKAGE:STRING=BOTH
)
else()
get_filename_component(prefix_dir ${qt_cmake_dir}/../../.. ABSOLUTE)
list(PREPEND CMAKE_PREFIX_PATH ${prefix_dir})
# 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()
list(APPEND vars_to_pass_if_defined
CMAKE_BUILD_TYPE:STRING
CMAKE_PREFIX_PATH:STRING
CMAKE_FIND_ROOT_PATH:STRING
CMAKE_FIND_ROOT_PATH_MODE_PACKAGE: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()
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()
ExternalProject_Add(${arg_NAME}
EXCLUDE_FROM_ALL TRUE
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/${subdir}
INSTALL_COMMAND ""
TEST_COMMAND ""
DEPENDS ${deps}
CMAKE_CACHE_ARGS ${var_defs}
${terminal_args}
)
# 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 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.
# TODO: This check is added before the actual release of CMake 3.21. So need to check if the
# target version meets the expectations.
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()
Reference in New Issue Copy Permalink