qtbase/cmake/QtBuildHelpers.cmake

457 lines
16 KiB
CMake
Raw Normal View History

CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
# Copyright (C) 2023 The Qt Company Ltd.
# SPDX-License-Identifier: BSD-3-Clause
function(qt_internal_validate_cmake_generator)
get_property(warning_shown GLOBAL PROPERTY _qt_validate_cmake_generator_warning_shown)
if(NOT warning_shown
AND NOT CMAKE_GENERATOR MATCHES "Ninja"
AND NOT QT_SILENCE_CMAKE_GENERATOR_WARNING
AND NOT DEFINED ENV{QT_SILENCE_CMAKE_GENERATOR_WARNING})
set_property(GLOBAL PROPERTY _qt_validate_cmake_generator_warning_shown TRUE)
message(WARNING
"The officially supported CMake generator for building Qt is "
"Ninja / Ninja Multi-Config. "
"You are using: '${CMAKE_GENERATOR}' instead. "
"Thus, you might encounter issues. Use at your own risk.")
endif()
endfunction()
macro(qt_internal_set_qt_building_qt)
# Set the QT_BUILDING_QT variable so we can verify whether we are building
# Qt from source.
# Make sure not to set it when building a standalone test, otherwise
# upon reconfiguration we get an error about qt_internal_add_test
# not being found due the if(NOT QT_BUILDING_QT) check we have
# in each standalone test.
if(NOT QT_INTERNAL_IS_STANDALONE_TEST)
set(QT_BUILDING_QT TRUE CACHE BOOL
"When this is present and set to true, it signals that we are building Qt from source.")
endif()
endmacro()
macro(qt_internal_unset_extra_build_internals_vars)
# Reset content of extra build internal vars for each inclusion of QtSetup.
unset(QT_EXTRA_BUILD_INTERNALS_VARS)
endmacro()
macro(qt_internal_get_generator_is_multi_config)
# Save the global property in a variable to make it available to feature conditions.
get_property(QT_GENERATOR_IS_MULTI_CONFIG GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
endmacro()
macro(qt_internal_setup_position_independent_code)
## Position independent code:
set(CMAKE_POSITION_INDEPENDENT_CODE ON)
# Does the linker support position independent code?
include(CheckPIESupported)
check_pie_supported()
endmacro()
macro(qt_internal_set_link_depends_no_shared)
# Do not relink dependent libraries when no header has changed:
set(CMAKE_LINK_DEPENDS_NO_SHARED ON)
endmacro()
macro(qt_internal_set_qt_source_tree_var)
# Specify the QT_SOURCE_TREE only when building qtbase. Needed by some tests when the tests are
# built as part of the project, and not standalone. For standalone tests, the value is set in
# QtBuildInternalsExtra.cmake.
if(PROJECT_NAME STREQUAL "QtBase")
set(QT_SOURCE_TREE "${QtBase_SOURCE_DIR}" CACHE PATH
"A path to the source tree of the previously configured QtBase project." FORCE)
endif()
endmacro()
macro(qt_internal_include_qt_platform_android)
## Android platform settings
if(ANDROID)
include(QtPlatformAndroid)
endif()
endmacro()
macro(qt_internal_set_compiler_optimization_flags)
include(QtCompilerOptimization)
endmacro()
macro(qt_internal_set_compiler_warning_flags)
include(QtCompilerFlags)
endmacro()
macro(qt_internal_set_skip_setup_deployment)
if(NOT QT_BUILD_EXAMPLES)
# Disable deployment setup to avoid warnings about missing patchelf with CMake < 3.21.
set(QT_SKIP_SETUP_DEPLOYMENT ON)
endif()
endmacro()
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
macro(qt_internal_reset_global_state)
qt_internal_clear_qt_repo_known_modules()
qt_internal_clear_qt_repo_known_plugin_types()
qt_internal_set_qt_known_plugins("")
set(QT_KNOWN_MODULES_WITH_TOOLS "" CACHE INTERNAL "Known Qt modules with tools" FORCE)
endmacro()
macro(qt_internal_set_qt_path_separator)
# For adjusting variables when running tests, we need to know what
# the correct variable is for separating entries in PATH-alike
# variables.
if(CMAKE_HOST_SYSTEM_NAME STREQUAL "Windows")
set(QT_PATH_SEPARATOR "\\;")
else()
set(QT_PATH_SEPARATOR ":")
endif()
endmacro()
macro(qt_internal_set_internals_extra_cmake_code)
# This is used to hold extra cmake code that should be put into QtBuildInternalsExtra.cmake file
# at the QtPostProcess stage.
set(QT_BUILD_INTERNALS_EXTRA_CMAKE_CODE "")
endmacro()
macro(qt_internal_set_top_level_source_dir)
# Save the value of the current first project source dir.
# This will be /path/to/qtbase for qtbase both in a super-build and a non super-build.
# This will be /path/to/qtbase/tests when building standalone tests.
set(QT_TOP_LEVEL_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
endmacro()
macro(qt_internal_set_apple_archiver_flags)
# Prevent warnings about object files without any symbols. This is a common
# thing in Qt as we tend to build files unconditionally, and then use ifdefs
# to compile out parts that are not relevant.
if(CMAKE_CXX_COMPILER_ID MATCHES "AppleClang")
foreach(lang ASM C CXX)
# We have to tell 'ar' to not run ranlib by itself, by passing the 'S' option
set(CMAKE_${lang}_ARCHIVE_CREATE "<CMAKE_AR> qcS <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_${lang}_ARCHIVE_APPEND "<CMAKE_AR> qS <TARGET> <LINK_FLAGS> <OBJECTS>")
set(CMAKE_${lang}_ARCHIVE_FINISH "<CMAKE_RANLIB> -no_warning_for_no_symbols <TARGET>")
endforeach()
endif()
endmacro()
macro(qt_internal_set_apple_privacy_manifest target manifest_file)
set_target_properties(${target} PROPERTIES _qt_privacy_manifest "${manifest_file}")
endmacro()
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
macro(qt_internal_set_debug_extend_target)
option(QT_CMAKE_DEBUG_EXTEND_TARGET "Debug extend_target calls in Qt's build system" OFF)
endmacro()
# These upstream CMake modules will be automatically include()'d when doing
# find_package(Qt6 COMPONENTS BuildInternals).
function(qt_internal_get_qt_build_upstream_cmake_modules out_var)
set(${out_var}
CMakeFindBinUtils
CMakePackageConfigHelpers
CheckCXXSourceCompiles
FeatureSummary
PARENT_SCOPE
)
endfunction()
# These helpers will be installed when building qtbase, and they will be automatically include()'d
# when doing find_package(Qt6 COMPONENTS BuildInternals).
# The helpers are expected to exist under the qtbase/cmake sub-directory and their file name
# extension should be '.cmake'.
function(qt_internal_get_qt_build_private_helpers out_var)
set(${out_var}
Qt3rdPartyLibraryHelpers
QtAndroidHelpers
QtAppHelpers
QtAutoDetectHelpers
QtAutogenHelpers
QtBuildInformation
QtBuildOptionsHelpers
QtBuildPathsHelpers
QtBuildRepoExamplesHelpers
QtBuildRepoHelpers
QtCMakeHelpers
QtCMakeVersionHelpers
QtDbusHelpers
QtDeferredDependenciesHelpers
QtDocsHelpers
QtExecutableHelpers
QtFindPackageHelpers
QtFlagHandlingHelpers
QtFrameworkHelpers
QtGlobalStateHelpers
QtHeadersClean
QtInstallHelpers
QtJavaHelpers
QtLalrHelpers
QtMkspecHelpers
QtModuleHelpers
QtNoLinkTargetHelpers
QtPkgConfigHelpers
QtPlatformTargetHelpers
QtPluginHelpers
QtPostProcessHelpers
QtPrecompiledHeadersHelpers
QtPriHelpers
QtPrlHelpers
QtQmakeHelpers
QtResourceHelpers
QtRpathHelpers
QtSanitizerHelpers
QtScopeFinalizerHelpers
QtSeparateDebugInfo
QtSimdHelpers
QtSingleRepoTargetSetBuildHelpers
QtSyncQtHelpers
QtTargetHelpers
QtTestHelpers
QtToolHelpers
QtToolchainHelpers
QtUnityBuildHelpers
QtWasmHelpers
QtWrapperScriptHelpers
PARENT_SCOPE
)
endfunction()
# These files will be installed when building qtbase, but will NOT be automatically include()d
# when doing find_package(Qt6 COMPONENTS BuildInternals).
# The files are expected to exist under the qtbase/cmake sub-directory.
function(qt_internal_get_qt_build_private_files_to_install out_var)
set(${out_var}
ModuleDescription.json.in
PkgConfigLibrary.pc.in
Qt3rdPartyLibraryConfig.cmake.in
QtBaseTopLevelHelpers.cmake
QtBuild.cmake
QtBuildHelpers.cmake
QtCMakePackageVersionFile.cmake.in
QtCompilerFlags.cmake
QtCompilerOptimization.cmake
QtConfigDependencies.cmake.in
QtConfigureTimeExecutableCMakeLists.txt.in
QtFileConfigure.txt.in
QtFindWrapConfigExtra.cmake.in
QtFindWrapHelper.cmake
QtFinishPkgConfigFile.cmake
QtFinishPrlFile.cmake
QtGenerateExtPri.cmake
QtGenerateLibHelpers.cmake
QtGenerateLibPri.cmake
QtGenerateVersionScript.cmake
QtModuleConfig.cmake.in
QtModuleDependencies.cmake.in
QtModuleHeadersCheck.cmake
QtModuleToolsConfig.cmake.in
QtModuleToolsDependencies.cmake.in
QtModuleToolsVersionlessTargets.cmake.in
QtPlatformAndroid.cmake
QtPlatformSupport.cmake
QtPluginConfig.cmake.in
QtPluginDependencies.cmake.in
QtPlugins.cmake.in
QtPostProcess.cmake
QtProcessConfigureArgs.cmake
QtSeparateDebugInfo.Info.plist.in
QtSetup.cmake
QtStandaloneTestsConfig.cmake.in
QtWriteArgsFile.cmake
modulecppexports.h.in
qbatchedtestrunner.in.cpp
PARENT_SCOPE
)
endfunction()
# These helpers will be installed when building qtbase, and they will be automatically include()'d
# when doing find_package(Qt6 COMPONENTS BuildInternals).
# The helpers are expected to exist under the qtbase/cmake sub-directory and their file name
# extension should be '.cmake'.
# In addition, they are meant to be included when doing find_package(Qt6) as well.
function(qt_internal_get_qt_build_public_helpers out_var)
set(${out_var}
QtFeature
QtFeatureCommon
QtPublicAppleHelpers
QtPublicCMakeHelpers
QtPublicCMakeVersionHelpers
QtPublicDependencyHelpers
QtPublicExternalProjectHelpers
QtPublicFinalizerHelpers
QtPublicFindPackageHelpers
QtPublicPluginHelpers
QtPublicTargetHelpers
QtPublicTestHelpers
QtPublicToolHelpers
QtPublicWalkLibsHelpers
PARENT_SCOPE
)
endfunction()
# These files will be installed when building qtbase, but will NOT be automatically include()d
# when doing find_package(Qt6) nor find_package(Qt6 COMPONENTS BuildInternals).
# The files are expected to exist under the qtbase/cmake sub-directory.
function(qt_internal_get_qt_build_public_files_to_install out_var)
set(${out_var}
QtCopyFileIfDifferent.cmake
QtInitProject.cmake
# Public CMake files that are installed next Qt6Config.cmake, but are NOT included by it.
# Instead they are included by the generated CMake toolchain file.
QtPublicWasmToolchainHelpers.cmake
PARENT_SCOPE
)
endfunction()
# Includes all Qt CMake helper files that define functions and macros.
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
macro(qt_internal_include_all_helpers)
# Upstream cmake modules.
qt_internal_get_qt_build_upstream_cmake_modules(__qt_upstream_helpers)
foreach(__qt_file_name IN LISTS __qt_upstream_helpers)
include("${__qt_file_name}")
endforeach()
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
# Internal helpers available only while building Qt itself.
qt_internal_get_qt_build_private_helpers(__qt_private_helpers)
foreach(__qt_file_name IN LISTS __qt_private_helpers)
include("${__qt_file_name}")
endforeach()
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
# Helpers that are available in public projects and while building Qt itself.
qt_internal_get_qt_build_public_helpers(__qt_public_helpers)
foreach(__qt_file_name IN LISTS __qt_public_helpers)
include("${__qt_file_name}")
endforeach()
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
endmacro()
function(qt_internal_check_host_path_set_for_cross_compiling)
if(CMAKE_CROSSCOMPILING)
if(NOT IS_DIRECTORY "${QT_HOST_PATH}")
message(FATAL_ERROR "You need to set QT_HOST_PATH to cross compile Qt.")
endif()
endif()
endfunction()
macro(qt_internal_setup_find_host_info_package)
_qt_internal_determine_if_host_info_package_needed(__qt_build_requires_host_info_package)
_qt_internal_find_host_info_package("${__qt_build_requires_host_info_package}")
endmacro()
macro(qt_internal_setup_poor_mans_scope_finalizer)
# This sets up the poor man's scope finalizer mechanism.
# For newer CMake versions, we use cmake_language(DEFER CALL) instead.
if(CMAKE_VERSION VERSION_LESS "3.19.0")
variable_watch(CMAKE_CURRENT_LIST_DIR qt_watch_current_list_dir)
endif()
endmacro()
macro(qt_internal_set_qt_namespace)
set(QT_NAMESPACE "" CACHE STRING "Qt Namespace")
endmacro()
macro(qt_internal_set_qt_coord_type)
if(PROJECT_NAME STREQUAL "QtBase")
set(QT_COORD_TYPE double CACHE STRING "Type of qreal")
endif()
endmacro()
function(qt_internal_check_macos_host_version)
# macOS versions 10.14 and less don't have the implementation of std::filesystem API.
if(CMAKE_HOST_APPLE AND CMAKE_HOST_SYSTEM_VERSION VERSION_LESS "19.0.0")
message(FATAL_ERROR "macOS versions less than 10.15 are not supported for building Qt.")
endif()
endfunction()
function(qt_internal_setup_tool_path_command)
if(NOT CMAKE_HOST_WIN32)
return()
endif()
set(bindir "${QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX}/${INSTALL_BINDIR}")
file(TO_NATIVE_PATH "${bindir}" bindir)
list(APPEND command COMMAND)
list(APPEND command set PATH=${bindir}$<SEMICOLON>%PATH%)
set(QT_TOOL_PATH_SETUP_COMMAND "${command}" CACHE INTERNAL
"internal command prefix for tool invocations" FORCE)
# QT_TOOL_PATH_SETUP_COMMAND is deprecated. Please use _qt_internal_get_wrap_tool_script_path
# instead.
endfunction()
macro(qt_internal_setup_android_platform_specifics)
if(ANDROID)
qt_internal_setup_android_target_properties()
endif()
endmacro()
macro(qt_internal_setup_build_and_global_variables)
qt_internal_validate_cmake_generator()
qt_internal_set_qt_building_qt()
CMake: Simplify default CMAKE_BUILD_TYPE logic Previously we had four-ish locations where the CMAKE_BUILD_TYPE was force set. Twice in QtBuildInternalsExtra.cmake via qt_internal_force_set_cmake_build_type_conditionally(), depending on some conditions. This was executed right at find_package(Qt6 COMPONENTS BuildInternals) time. And twice in qt_internal_set_default_build_type() via qt_build_repo_begin() / qt_prepare_standalone_project() that goes through QtSetup.cmake. This was executed only if the relevant functions were called, rather than directly at find_package() time. The exact logic of which build type ended up being set was very confusing. Refactor the code to decide the build type in one single location when qt_build_repo_begin() / qt_prepare_standalone_project() are called, rather than directly at find_package() time. The actual logic when we override the build type depends on many factors: - when an explicit CMAKE_BUILD_TYPE is given, honor it, unless it's a multi-config build - when it's a multi-config build, don't set any CMAKE_BUILD_TYPE, use the value of CMAKE_CONFIGURATION_TYPES - when it's a qtbase build, compute a default unless an explicit value was given - the default is Debug if FEATURE_developer_build is ON - otherwise the default is Release - when it's a top-level build, only choose a build type for qtbase - when it's another repo build, use the original build type unless another was given explicitly (including in a top-level build) - when it's a standalone tests build - if qt is multi-config, the tests will be single config, due to various CI failure reasons, this hasn't changed - if qt is single config, use the original unless an explicit value was given - when it's a single standalone test build, use the original unless an explicit value was given To determine when an explicit CMAKE_BUILD_TYPE was given in contrast to when it was default initialized, we now have one single function that uses a few heuristics. The heuristics are needed because we can't reliably determine an explicitly given 'Debug' build on Windows, because CMake default initializes to that. The heuristics include: - checking whether CMAKE_BUILD_TYPE_INIT is different from CMAKE_BUILD_TYPE - checking what the CMAKE_BUILD_TYPE was before the first project() call when CMake default initializes - we save the previous value in the qt.toolchain.cmake file - also in QtAutoDetect during qtbase configuration - also when building the sqldrivers project - honoring the value of QT_NO_FORCE_SET_CMAKE_BUILD_TYPE As a result of the above changes, the build type will be set exactly zero or one times, for a particular build directory. Note that the configure script also has some logic on which CMAKE_BUILD_TYPE / CMAKE_CONFIGURATION_TYPES to pass to CMake depending on whether -debug / -release / -debug-and-release / -force-debug-info were passed. But once the values are passed, CMake will honor them. Amends 48841c34d2e86a741ec9992b9704c0fa5973503c Amends 8c912cddebe544010e7da3f87af5b21f3328d7ec Pick-to: 6.7 Task-number: QTBUG-114958 Task-number: QTBUG-120436 Change-Id: I30db14d1e8e9ff9bd2d7ea1d2256cdeb9493ca0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2024-01-22 17:11:31 +00:00
qt_internal_set_cmake_build_type()
qt_internal_set_message_log_level(CMAKE_MESSAGE_LOG_LEVEL)
qt_internal_unset_extra_build_internals_vars()
qt_internal_get_generator_is_multi_config()
CMake: Simplify default CMAKE_BUILD_TYPE logic Previously we had four-ish locations where the CMAKE_BUILD_TYPE was force set. Twice in QtBuildInternalsExtra.cmake via qt_internal_force_set_cmake_build_type_conditionally(), depending on some conditions. This was executed right at find_package(Qt6 COMPONENTS BuildInternals) time. And twice in qt_internal_set_default_build_type() via qt_build_repo_begin() / qt_prepare_standalone_project() that goes through QtSetup.cmake. This was executed only if the relevant functions were called, rather than directly at find_package() time. The exact logic of which build type ended up being set was very confusing. Refactor the code to decide the build type in one single location when qt_build_repo_begin() / qt_prepare_standalone_project() are called, rather than directly at find_package() time. The actual logic when we override the build type depends on many factors: - when an explicit CMAKE_BUILD_TYPE is given, honor it, unless it's a multi-config build - when it's a multi-config build, don't set any CMAKE_BUILD_TYPE, use the value of CMAKE_CONFIGURATION_TYPES - when it's a qtbase build, compute a default unless an explicit value was given - the default is Debug if FEATURE_developer_build is ON - otherwise the default is Release - when it's a top-level build, only choose a build type for qtbase - when it's another repo build, use the original build type unless another was given explicitly (including in a top-level build) - when it's a standalone tests build - if qt is multi-config, the tests will be single config, due to various CI failure reasons, this hasn't changed - if qt is single config, use the original unless an explicit value was given - when it's a single standalone test build, use the original unless an explicit value was given To determine when an explicit CMAKE_BUILD_TYPE was given in contrast to when it was default initialized, we now have one single function that uses a few heuristics. The heuristics are needed because we can't reliably determine an explicitly given 'Debug' build on Windows, because CMake default initializes to that. The heuristics include: - checking whether CMAKE_BUILD_TYPE_INIT is different from CMAKE_BUILD_TYPE - checking what the CMAKE_BUILD_TYPE was before the first project() call when CMake default initializes - we save the previous value in the qt.toolchain.cmake file - also in QtAutoDetect during qtbase configuration - also when building the sqldrivers project - honoring the value of QT_NO_FORCE_SET_CMAKE_BUILD_TYPE As a result of the above changes, the build type will be set exactly zero or one times, for a particular build directory. Note that the configure script also has some logic on which CMAKE_BUILD_TYPE / CMAKE_CONFIGURATION_TYPES to pass to CMake depending on whether -debug / -release / -debug-and-release / -force-debug-info were passed. But once the values are passed, CMake will honor them. Amends 48841c34d2e86a741ec9992b9704c0fa5973503c Amends 8c912cddebe544010e7da3f87af5b21f3328d7ec Pick-to: 6.7 Task-number: QTBUG-114958 Task-number: QTBUG-120436 Change-Id: I30db14d1e8e9ff9bd2d7ea1d2256cdeb9493ca0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2024-01-22 17:11:31 +00:00
# Depends on qt_internal_set_cmake_build_type
qt_internal_setup_cmake_config_postfix()
qt_internal_setup_position_independent_code()
qt_internal_set_link_depends_no_shared()
qt_internal_setup_default_install_prefix()
qt_internal_set_qt_source_tree_var()
qt_internal_set_export_compile_commands()
qt_internal_set_configure_from_ide()
# Depends on qt_internal_set_configure_from_ide
qt_internal_set_sync_headers_at_configure_time()
qt_internal_setup_build_benchmarks()
# Depends on qt_internal_setup_build_benchmarks
qt_internal_setup_build_tests()
qt_internal_setup_build_tools()
# Depends on qt_internal_setup_default_install_prefix
qt_internal_setup_build_examples()
qt_internal_set_qt_host_path()
qt_internal_include_qt_platform_android()
# Depends on qt_internal_setup_default_install_prefix
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
qt_internal_setup_paths_and_prefixes()
qt_internal_reset_global_state()
# Depends on qt_internal_setup_paths_and_prefixes
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
qt_internal_set_mkspecs_dir()
qt_internal_setup_platform_definitions_and_mkspec()
qt_internal_check_macos_host_version()
_qt_internal_check_apple_sdk_and_xcode_versions()
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
qt_internal_check_host_path_set_for_cross_compiling()
qt_internal_setup_android_platform_specifics()
qt_internal_setup_find_host_info_package()
qt_internal_setup_tool_path_command()
qt_internal_setup_default_target_function_options()
qt_internal_set_default_rpath_settings()
qt_internal_set_qt_namespace()
qt_internal_set_qt_coord_type()
qt_internal_set_qt_path_separator()
qt_internal_set_internals_extra_cmake_code()
qt_internal_set_top_level_source_dir()
qt_internal_set_apple_archiver_flags()
qt_internal_set_debug_extend_target()
qt_internal_setup_poor_mans_scope_finalizer()
qt_internal_set_compiler_optimization_flags()
qt_internal_set_compiler_warning_flags()
qt_set_language_standards()
qt_internal_set_use_ccache()
qt_internal_set_unity_build()
qt_internal_set_allow_symlink_in_paths()
qt_internal_set_skip_setup_deployment()
qt_internal_set_qt_allow_download()
qt_internal_detect_dirty_features()
CMake: Split QtBuild.cmake into smaller files v2 My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
2023-11-15 17:08:15 +00:00
endmacro()