1berry/qtbase
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
qtbase/cmake/QtBuildInternals/QtBuildInternalsConfig.cmake

58 lines
2.4 KiB
CMake
Raw Permalink Normal View History

Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 13:26:52 +02:00
# Copyright (C) 2022 The Qt Company Ltd.
Change the license of all CMakeLists.txt and *.cmake files to BSD Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-19 15:21:34 +02:00
# SPDX-License-Identifier: BSD-3-Clause
Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 13:26:52 +02:00
CMake: Enable NEW policies by CMake version with a global default When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-30 18:46:49 +11:00
# These values should be kept in sync with those in qtbase/.cmake.conf
Sync CMake Version with `.cmake.conf` As stated in `QtBuildInternalsConfig.cmake`, `cmake_minimum_required` versions should be synced with `qtbase/.cmake.conf`, but it wasn't at the moment. Change-Id: I8100370778707d46abe973b681fd4aba182a7513 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-10-24 11:13:46 +02:00
cmake_minimum_required(VERSION 3.16...3.21)
Use the qt_build_repo() macros for building qtbase as well To implement this, create a new Qt5BuildInternals package. All child Qt modules like qtsvg should use find_package(Qt5BuildInternals) or find_package(Qt5 COMPONENTS BuildInternals) in the their top level CMakeLists.txt. This will make the qt_build_repo() macros available. For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH pointing to the source folder that contains the BuildInternals package. For the other modules we actually use a configured and installed package Config file. This change moves variables that used to be written into the QtCore Config file into the BuildInternals package. This way things that are relevant only for building additional Qt modules does not pollute the QtCore package. Task-number: QTBUG-75580 Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-05-15 13:57:15 +02:00
CMake: Split and refactor QtBuildInternalsConfig.cmake Move most of the code into two new files: - QtBuildRepoHelpers.cmake - QtBuildRepoExamplesHelpers.cmake Task-number: QTBUG-86035 Change-Id: I48c4e7c64f0ffb600118172b8e69b26018f36ffb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-16 19:57:25 +01:00
set(QT_BACKUP_CMAKE_INSTALL_PREFIX_BEFORE_EXTRA_INCLUDE "${CMAKE_INSTALL_PREFIX}")
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 20:43:25 +01:00
CMake: Split and refactor QtBuildInternalsConfig.cmake Move most of the code into two new files: - QtBuildRepoHelpers.cmake - QtBuildRepoExamplesHelpers.cmake Task-number: QTBUG-86035 Change-Id: I48c4e7c64f0ffb600118172b8e69b26018f36ffb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-16 19:57:25 +01:00
# This depends on qt_internal_read_repo_dependencies existing.
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 13:57:15 +02:00
if(EXISTS "${CMAKE_CURRENT_LIST_DIR}/QtBuildInternalsExtra.cmake")
include(${CMAKE_CURRENT_LIST_DIR}/QtBuildInternalsExtra.cmake)
endif()
CMake: Make QT_CMAKE_EXPORT_NAMESPACE available in the top-level scope Previously QT_CMAKE_EXPORT_NAMESPACE was set by calling find_package(QtBuildInternals) at repo dir scope, even in a top-level build. Starting with ddcafa0a51c65d86f6b5481f06fce5faeb75920d in qtdeclarative, we now have a deferred call of _qt_internal_write_deferred_qmlls_build_ini_file in the CMAKE_BINARY_DIR scope, which lacks the QT_CMAKE_EXPORT_NAMESPACE variable. This caused errors in a top-level standalone tests build: Error evaluating generator expression $ No target "::qtpaths" CMakeLists.txt:DEFERRED To avoid the error we now set QT_CMAKE_EXPORT_NAMESPACE in the top level scope. To avoid duplicating the code into the QtBaseTopLevelHelpers, we extract the qt_internal_top_level_setup_cmake_and_export_namespace function into a new QtBuildInternalsHelpers.cmake file, which is included by both QtBaseTopLevelHelpers.cmake and QtBuildInternalsConfig.cmake. We also copy and install that file. This has less side effects than trying to call find_package(QtBuildInternals) in the top-level scope. Pick-to: 6.10 Change-Id: I8e54e21d3f07ee86860cad49d6e43e0fdefbcee3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2025-06-05 13:06:55 +02:00
include(${CMAKE_CURRENT_LIST_DIR}/QtBuildInternalsHelpers.cmake)
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 19:29:52 +01:00
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 10:22:08 +02: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 17:58:53 +02: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 18:17:00 +02: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 10:22:08 +02: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 18:17:00 +02: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 13:33:28 +01: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 18:17:00 +02:00
# so that if a change is done in cmake/QtBuild.cmake, it gets automatically picked up when
# building qtdeclarative, rather than having to build qtbase first (which will copy
# QtBuild.cmake to the build dir). This is similar to qmake non-prefix builds, where the
# source qtbase/mkspecs directory is used.
CMake: Fix picking of the binary_for_strip project location Fix binary_for_strip project not being found when the following conditions were met: - building a repo other than qtbase - qtbase sources are not available on the machine (usually happens in CI where only the current repo sources are available). The issue was that QT_CMAKE_DIR would always be defined, regardless of which repo was being built and the system would incorrectly assume the location of the project files. The fix is to always pick up the sources from qtbase's source dir if they are available (this time done with an appropriate check), otherwise use the installed files. Note that the behavior of always using the qtbase sources if available is not exactly the best, but it is a more general issue that affects other code too. In the name of consistency, make it so for the binary_for_strip project as well, but add TODOs in code to address the situation in a separate change. Amends 39f657032b5e65bfcb93472201f6607c0388ba37 Pick-to: 6.2 6.3 Fixes: QTBUG-102064 Task-number: QTBUG-88090 Task-number: QTBUG-101653 Change-Id: I0649f945e9ff0ab1f597c51bb5ab389fa665c021 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-28 16:59:20 +02:00
# TODO: Clean this up, together with qt_internal_try_compile_binary_for_strip to only use the
# the qtbase sources when building qtbase. And perhaps also when doing a non-prefix
# developer-build.
Implement qtbase fixes for superbuilds Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-11-21 13:33:28 +01: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 18:17:00 +02: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 10:22:08 +02: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 18:17:00 +02: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 10:22:08 +02: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 15:20:57 +02: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 10:22:08 +02:00
endmacro()
CMake: Split and refactor QtBuildInternalsConfig.cmake Move most of the code into two new files: - QtBuildRepoHelpers.cmake - QtBuildRepoExamplesHelpers.cmake Task-number: QTBUG-86035 Change-Id: I48c4e7c64f0ffb600118172b8e69b26018f36ffb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-16 19:57:25 +01:00
qt_internal_setup_cmake_and_export_namespace()
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 17:58:53 +02:00
# Set up the build internal paths unless explicitly requested not to.
if(NOT QT_BUILD_INTERNALS_SKIP_CMAKE_MODULE_PATH_ADDITION)
CMake: Split and refactor QtBuildInternalsConfig.cmake Move most of the code into two new files: - QtBuildRepoHelpers.cmake - QtBuildRepoExamplesHelpers.cmake Task-number: QTBUG-86035 Change-Id: I48c4e7c64f0ffb600118172b8e69b26018f36ffb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-16 19:57:25 +01:00
# Depends on qt_internal_setup_cmake_and_export_namespace
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 17:58:53 +02:00
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 13:57:15 +02:00
CMake: Mostly unify includes into a single location Make the QtBuildRepoHelpers and QtBuildRepoExamplesHelpers files that were previously loaded as part of BuildInternals package instead be loaded when qt_internal_include_all_helpers is called. Load all the helpers as soon as find_package(QtBuildInternals) is called rather than when qt_build_repo() is called. This is a behavior change, but because including the Qt's Helpers should have no side-effects aside from defining functions, it should be fine. This lets us have a unified location where to include Helpers files, instead of thinking whether it needs to be done in QtBuildInternals or in QtBuildHelpers or some other place. Move also some additional inclusions into the same function. Note that including some upstream CMake files like CMakeFindBinUtils does have side-effects, but we've been doing it already anyway, so moving it to the top should not make a difference because any modifications we would do to the globally assigned variables would have come later when we actually called our own functions. Task-number: QTBUG-86035 Change-Id: I33f36f7e8db69d504c34a4d4a094b98f6fa50ee4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-17 16:46:45 +01:00
include(QtBuildHelpers)
Implement qt_internal_get_file_path_mode for changing the file path mode In cases where we allow symlink, we need to use ABSOLUTE path, and don't resolve the symlink. This function returns ABSOLUTE only if we are on Apple platform, and have QT_ALLOW_SYMLINK_IN_PATHS enabled. While this is mainly to resolve the issue report by Homebrew, it might be useful if a user really want to build with symlink. Pick-to: 6.5 Task-number: QTBUG-113463 Change-Id: Ided141ed8de66cc1d3717ec2719eb703fa7fc589 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-05-09 14:37:33 +02:00
CMake: Mostly unify includes into a single location Make the QtBuildRepoHelpers and QtBuildRepoExamplesHelpers files that were previously loaded as part of BuildInternals package instead be loaded when qt_internal_include_all_helpers is called. Load all the helpers as soon as find_package(QtBuildInternals) is called rather than when qt_build_repo() is called. This is a behavior change, but because including the Qt's Helpers should have no side-effects aside from defining functions, it should be fine. This lets us have a unified location where to include Helpers files, instead of thinking whether it needs to be done in QtBuildInternals or in QtBuildHelpers or some other place. Move also some additional inclusions into the same function. Note that including some upstream CMake files like CMakeFindBinUtils does have side-effects, but we've been doing it already anyway, so moving it to the top should not make a difference because any modifications we would do to the globally assigned variables would have come later when we actually called our own functions. Task-number: QTBUG-86035 Change-Id: I33f36f7e8db69d504c34a4d4a094b98f6fa50ee4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-17 16:46:45 +01:00
qt_internal_include_all_helpers()
CMake: Split and refactor QtBuildInternalsConfig.cmake Move most of the code into two new files: - QtBuildRepoHelpers.cmake - QtBuildRepoExamplesHelpers.cmake Task-number: QTBUG-86035 Change-Id: I48c4e7c64f0ffb600118172b8e69b26018f36ffb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2023-11-16 19:57:25 +01:00
qt_internal_setup_build_internals()
Reference in New Issue Copy Permalink