AuroraMiddleware/qt5base-lts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
2979df59b9
qt5base-lts/cmake/QtTargetHelpers.cmake

899 lines
39 KiB
CMake
Raw Normal View History

CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# This function can be used to add sources/libraries/etc. to the specified CMake target
# if the provided CONDITION evaluates to true.
CMake: Rename internal functions to contain qt_internal Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2020-09-22 08:02:27 +00:00
function(qt_internal_extend_target target)
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
# Don't try to extend_target when cross compiling an imported host target (like a tool).
qt_is_imported_target("${target}" is_imported)
if(is_imported)
return()
endif()
if (NOT TARGET "${target}")
message(FATAL_ERROR "Trying to extend non-existing target \"${target}\".")
endif()
qt_parse_all_arguments(arg "qt_extend_target" "HEADER_MODULE" "PRECOMPILED_HEADER"
"CONDITION;${__default_public_args};${__default_private_args};${__default_private_module_args};COMPILE_FLAGS;NO_PCH_SOURCES" ${ARGN})
if ("x${arg_CONDITION}" STREQUAL x)
set(arg_CONDITION ON)
endif()
qt_evaluate_config_expression(result ${arg_CONDITION})
if (${result})
if(QT_CMAKE_DEBUG_EXTEND_TARGET)
message("qt_extend_target(${target} CONDITION ${arg_CONDITION} ...): Evaluated")
endif()
set(dbus_sources "")
foreach(adaptor ${arg_DBUS_ADAPTOR_SOURCES})
qt_create_qdbusxml2cpp_command("${target}" "${adaptor}" ADAPTOR BASENAME "${arg_DBUS_ADAPTOR_BASENAME}" FLAGS "${arg_DBUS_ADAPTOR_FLAGS}")
CMake: Fix dbus headers not being added in qt_internal_extend_target The generated dbus headers would not appear in IDE source lists because of incorrectly named variables. Pick-to: 6.2 6.3 Change-Id: I276d4284eb94b98cc75f791de62ca332ad947004 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-01-17 15:59:05 +00:00
list(APPEND dbus_sources "${adaptor}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endforeach()
foreach(interface ${arg_DBUS_INTERFACE_SOURCES})
qt_create_qdbusxml2cpp_command("${target}" "${interface}" INTERFACE BASENAME "${arg_DBUS_INTERFACE_BASENAME}" FLAGS "${arg_DBUS_INTERFACE_FLAGS}")
CMake: Fix dbus headers not being added in qt_internal_extend_target The generated dbus headers would not appear in IDE source lists because of incorrectly named variables. Pick-to: 6.2 6.3 Change-Id: I276d4284eb94b98cc75f791de62ca332ad947004 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-01-17 15:59:05 +00:00
list(APPEND dbus_sources "${interface}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endforeach()
get_target_property(target_type ${target} TYPE)
set(is_library FALSE)
if (${target_type} STREQUAL "STATIC_LIBRARY" OR ${target_type} STREQUAL "SHARED_LIBRARY")
set(is_library TRUE)
endif()
foreach(lib ${arg_PUBLIC_LIBRARIES} ${arg_LIBRARIES})
CMake: Fix excessive size of precompiled header files Do not add catch-all header files like QtCore, QtGui, etc. to precompiled headers for targets that already define their own set of precompiled header files. This reduces the size of the precompiled headers and brings the pch file sizes down into the region of the qmake build. Pick-to: 6.2 Task-number: QTBUG-89122 Change-Id: I8e4d17aa6829c7d7b1aa01a01a61b6677e22c460 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-23 19:12:36 +00:00
# Automatically generate PCH for 'target' using public dependencies.
# But only if 'target' is a library/module that does not specify its own PCH file.
if(NOT arg_PRECOMPILED_HEADER AND ${is_library})
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
qt_update_precompiled_header_with_library("${target}" "${lib}")
endif()
string(REGEX REPLACE "_nolink$" "" base_lib "${lib}")
if(NOT base_lib STREQUAL lib)
qt_create_nolink_target("${base_lib}" ${target})
endif()
endforeach()
# Set-up the target
Exclude sources from HEADER_MODULE if cmake version is less than 3.19 CMake versions less than 3.19 don't support adding the source files to the PRIVATE scope of the INTERFACE libraries. It looks like these PRIVATE sources are only used by IDEs to display them in a project tree. Skip them to avoid configuring issues. Fixes: QTBUG-99316 Pick-to: 6.3 Change-Id: Id03f540ac9c94e920adfae5de4f364bd7aba4613 Reviewed-by: Andrei Golubev <andrei.golubev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-21 16:05:07 +00:00
# CMake versions less than 3.19 don't support adding the source files to the PRIVATE scope
# of the INTERFACE libraries. These PRIVATE sources are only needed by IDEs to display
# them in a project tree, so to avoid build issues and appearing the sources in
# INTERFACE_SOURCES property of HEADER_MODULE let's simply exclude them for compatibility
# with CMake versions less than 3.19.
if(NOT arg_HEADER_MODULE OR CMAKE_VERSION VERSION_GREATER_EQUAL "3.19")
target_sources("${target}" PRIVATE ${arg_SOURCES} ${dbus_sources})
if (arg_COMPILE_FLAGS)
set_source_files_properties(${arg_SOURCES} PROPERTIES
COMPILE_FLAGS "${arg_COMPILE_FLAGS}")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
set(public_visibility_option "PUBLIC")
set(private_visibility_option "PRIVATE")
if(arg_HEADER_MODULE)
set(public_visibility_option "INTERFACE")
set(private_visibility_option "INTERFACE")
endif()
target_include_directories("${target}"
${public_visibility_option} ${arg_PUBLIC_INCLUDE_DIRECTORIES}
${private_visibility_option} ${arg_INCLUDE_DIRECTORIES})
target_compile_definitions("${target}"
${public_visibility_option} ${arg_PUBLIC_DEFINES}
${private_visibility_option} ${arg_DEFINES})
target_link_libraries("${target}"
${public_visibility_option} ${arg_PUBLIC_LIBRARIES}
${private_visibility_option} ${arg_LIBRARIES})
target_compile_options("${target}"
${public_visibility_option} ${arg_PUBLIC_COMPILE_OPTIONS}
${private_visibility_option} ${arg_COMPILE_OPTIONS})
target_link_options("${target}"
${public_visibility_option} ${arg_PUBLIC_LINK_OPTIONS}
${private_visibility_option} ${arg_LINK_OPTIONS})
if(NOT arg_HEADER_MODULE)
set_property (TARGET "${target}" APPEND PROPERTY
AUTOMOC_MOC_OPTIONS "${arg_MOC_OPTIONS}"
)
endif()
# When computing the private library dependencies, we need to check not only the known
# modules added by this repo's qt_build_repo(), but also all module dependencies that
# were found via find_package().
qt_internal_get_qt_all_known_modules(known_modules)
# When a public module depends on a private module (Gui on CorePrivate)
# make its private module depend on the other private module (GuiPrivate will depend on
# CorePrivate).
set(qt_libs_private "")
foreach(it ${known_modules})
list(FIND arg_LIBRARIES "Qt::${it}Private" pos)
if(pos GREATER -1)
list(APPEND qt_libs_private "Qt::${it}Private")
endif()
endforeach()
set(target_private "${target}Private")
Add missing PRIVATE_MODULE_INTERFACEs to INTERNAL_MODULEs To detect the internal module ouside the qt_internal_add_module function need to mark it with the property. This adds _qt_is_internal_module property to the Qt internal modules. Since PRIVATE_MODULE_INTERFACE only was applicable to pure Private modules, INTERNAL_MODULEs is missing those dependencies if they were specified. Add extra condition to qt_internal_extend_target to link PRIVATE_MODULE_INTERFACE libraries to internal modules as well. Pick-to: 6.2 6.1 Change-Id: I9c32fa5bad3aff365f5d7663349e5365d5f1d72d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-24 11:30:51 +00:00
get_target_property(is_internal_module ${target} _qt_is_internal_module)
# Internal modules don't have Private targets but we still need to
# propagate their private dependencies.
if(is_internal_module)
set(target_private "${target}")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
if(TARGET "${target_private}")
CMake: Warn when PRIVATE_MODULE_INTERFACE is provided with no target Warn if the PRIVATE_MODULE_INTERFACE option is provided a value, but there is no ${target}Private target to set the interface dependencies on. Pick-to: 6.2 Task-number: QTBUG-95921 Change-Id: I7d4df9cb3aa9b7746d836b82019ecdd9c8f50fdc Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-23 18:47:05 +00:00
target_link_libraries("${target_private}"
INTERFACE ${arg_PRIVATE_MODULE_INTERFACE})
elseif(arg_PRIVATE_MODULE_INTERFACE)
set(warning_message "")
string(APPEND warning_message
"The PRIVATE_MODULE_INTERFACE option was provided the values:"
"'${arg_PRIVATE_MODULE_INTERFACE}' "
"but there is no ${target}Private target to assign them to."
"Ensure the target exists or remove the option.")
message(AUTHOR_WARNING "${warning_message}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
qt_register_target_dependencies("${target}"
Add PRIVATE_MODULE_INTERFACE to the module dependency set PRIVATE_MODULE_INTERFACE libraries are linked as interface libraries to the module's Private target and exported as the dependencies of package targets. We need to register these modules as public package dependencies to call find_package when resolving module dependencies in user projects. Pick-to: 6.2 Fixes: QTBUG-96558 Change-Id: I4eef550aab306eaf357539ef7a0f76d69873f856 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-14 14:41:04 +00:00
"${arg_PUBLIC_LIBRARIES};${arg_PRIVATE_MODULE_INTERFACE}"
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
"${qt_libs_private};${arg_LIBRARIES}")
qt_autogen_tools(${target}
ENABLE_AUTOGEN_TOOLS ${arg_ENABLE_AUTOGEN_TOOLS}
DISABLE_AUTOGEN_TOOLS ${arg_DISABLE_AUTOGEN_TOOLS})
qt_update_precompiled_header("${target}" "${arg_PRECOMPILED_HEADER}")
qt_update_ignore_pch_source("${target}" "${arg_NO_PCH_SOURCES}")
## Ignore objective-c files for PCH (not supported atm)
qt_ignore_pch_obj_c_sources("${target}" "${arg_SOURCES}")
else()
if(QT_CMAKE_DEBUG_EXTEND_TARGET)
message("qt_extend_target(${target} CONDITION ${arg_CONDITION} ...): Skipped")
endif()
endif()
endfunction()
function(qt_is_imported_target target out_var)
if(NOT TARGET "${target}")
set(target "${QT_CMAKE_EXPORT_NAMESPACE}::${target}")
endif()
if(NOT TARGET "${target}")
message(FATAL_ERROR "Invalid target given to qt_is_imported_target: ${target}")
endif()
get_target_property(is_imported "${target}" IMPORTED)
set(${out_var} "${is_imported}" PARENT_SCOPE)
endfunction()
# Add Qt::target and Qt6::target as aliases for the target
function(qt_internal_add_target_aliases target)
CMake: Refactor parts of qt_internal_walk_libs Refactor the function in preparation of processing rcc object files. Introduce 2 new functions to get and set values in the memoization dictionary used by qt_internal_walk_libs. Modify qt_internal_add_target_aliases to assign the alias names it creates as properties on the target. Extract these aliases when available to assign memoized values not only for the initial library name, but also for its aliases. When recursively calling qt_internal_walk_libs, make sure to provide a unique out_var name based on the outer target name, and not just lib_libs. Otherwise the out_var values would be polluted from previous recursion runs. Make sure to check for -NOTFOUND in if() checks so that we reuse memoized values that are the empty string. Change-Id: I8fd8e2b0ae14d0ba8f502bc5a764d6e01095001a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 15:53:15 +00:00
set(versionless_alias "Qt::${target}")
set(versionfull_alias "Qt${PROJECT_VERSION_MAJOR}::${target}")
set_target_properties("${target}" PROPERTIES _qt_versionless_alias "${versionless_alias}")
set_target_properties("${target}" PROPERTIES _qt_versionfull_alias "${versionfull_alias}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
get_target_property(type "${target}" TYPE)
if (type STREQUAL EXECUTABLE)
CMake: Refactor parts of qt_internal_walk_libs Refactor the function in preparation of processing rcc object files. Introduce 2 new functions to get and set values in the memoization dictionary used by qt_internal_walk_libs. Modify qt_internal_add_target_aliases to assign the alias names it creates as properties on the target. Extract these aliases when available to assign memoized values not only for the initial library name, but also for its aliases. When recursively calling qt_internal_walk_libs, make sure to provide a unique out_var name based on the outer target name, and not just lib_libs. Otherwise the out_var values would be polluted from previous recursion runs. Make sure to check for -NOTFOUND in if() checks so that we reuse memoized values that are the empty string. Change-Id: I8fd8e2b0ae14d0ba8f502bc5a764d6e01095001a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 15:53:15 +00:00
add_executable("${versionless_alias}" ALIAS "${target}")
add_executable("${versionfull_alias}" ALIAS "${target}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
else()
CMake: Refactor parts of qt_internal_walk_libs Refactor the function in preparation of processing rcc object files. Introduce 2 new functions to get and set values in the memoization dictionary used by qt_internal_walk_libs. Modify qt_internal_add_target_aliases to assign the alias names it creates as properties on the target. Extract these aliases when available to assign memoized values not only for the initial library name, but also for its aliases. When recursively calling qt_internal_walk_libs, make sure to provide a unique out_var name based on the outer target name, and not just lib_libs. Otherwise the out_var values would be polluted from previous recursion runs. Make sure to check for -NOTFOUND in if() checks so that we reuse memoized values that are the empty string. Change-Id: I8fd8e2b0ae14d0ba8f502bc5a764d6e01095001a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-16 15:53:15 +00:00
add_library("${versionless_alias}" ALIAS "${target}")
add_library("${versionfull_alias}" ALIAS "${target}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
endfunction()
function(qt_get_cmake_configurations out_var)
set(possible_configs "${CMAKE_BUILD_TYPE}")
if(CMAKE_CONFIGURATION_TYPES)
set(possible_configs "${CMAKE_CONFIGURATION_TYPES}")
endif()
set(${out_var} "${possible_configs}" PARENT_SCOPE)
endfunction()
function(qt_clone_property_for_configs target property configs)
get_target_property(value "${target}" "${property}")
foreach(config ${configs})
string(TOUPPER "${config}" upper_config)
set_property(TARGET "${target}" PROPERTY "${property}_${upper_config}" "${value}")
endforeach()
endfunction()
function(qt_handle_multi_config_output_dirs target)
qt_get_cmake_configurations(possible_configs)
qt_clone_property_for_configs(${target} LIBRARY_OUTPUT_DIRECTORY "${possible_configs}")
qt_clone_property_for_configs(${target} RUNTIME_OUTPUT_DIRECTORY "${possible_configs}")
qt_clone_property_for_configs(${target} ARCHIVE_OUTPUT_DIRECTORY "${possible_configs}")
endfunction()
# Set target properties that are the same for all modules, plugins, executables
# and 3rdparty libraries.
function(qt_set_common_target_properties target)
CMake: Implement configure -reduce-exports This option maps to FEATURE_reduce_exports. The feature is on by default, except for MSVC. The reduce_exports configure test is not used in the CMake build. The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target properties are now explicitly initialized in the qt_set_common_target_properties function, because we don't have access to the feature in QtSetup.cmake where the CMAKE_<LANG>_VISIBILITY_PRESET variables were set before. Task-number: QTBUG-85373 Change-Id: I378453f0e0665731970016170302871e20ceb4e2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-08-25 06:17:23 +00:00
if(QT_FEATURE_reduce_exports)
set_target_properties(${target} PROPERTIES
C_VISIBILITY_PRESET hidden
CXX_VISIBILITY_PRESET hidden
OBJC_VISIBILITY_PRESET hidden
OBJCXX_VISIBILITY_PRESET hidden
VISIBILITY_INLINES_HIDDEN 1)
endif()
CMake: Fix module separate build error when -DFEATURE_static_runtime=ON Build qtbase with -DFEATURE_static_runtime=ON, and then separately build another module, following build error occurs: error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'. That's because all the sources in this module are compiled with 'MD'. When separately building a module except qtbase, FEATURE_static_runtime is not exist in cmake cache. So we should use QT_FEATURE_static_runtime instead of FEATURE_static_runtime in qt_set_common_target_properties. Additionally, adjust the indentation. Pick-to: 6.0 Change-Id: I2cf4737db9d3e8533570039a66c7d277d62a8d14 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-16 05:32:04 +00:00
qt_internal_set_compile_pdb_names("${target}")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endfunction()
# Set common, informational target properties.
#
# On Windows, these properties are used to generate the version information resource.
function(qt_set_target_info_properties target)
cmake_parse_arguments(arg "" "${__default_target_info_args}" "" ${ARGN})
if("${arg_TARGET_VERSION}" STREQUAL "")
set(arg_TARGET_VERSION "${PROJECT_VERSION}.0")
endif()
if("${arg_TARGET_PRODUCT}" STREQUAL "")
set(arg_TARGET_PRODUCT "Qt6")
endif()
if("${arg_TARGET_DESCRIPTION}" STREQUAL "")
set(arg_TARGET_DESCRIPTION "C++ Application Development Framework")
endif()
if("${arg_TARGET_COMPANY}" STREQUAL "")
set(arg_TARGET_COMPANY "The Qt Company Ltd.")
endif()
if("${arg_TARGET_COPYRIGHT}" STREQUAL "")
Update copyright year to 2022 Pick-to: 5.15 6.2 6.3 Change-Id: If6f1d6f9f82a601f8e2b6d36650d6e737518aa60 Reviewed-by: Paul Wicking <paul.wicking@qt.io> Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
2022-01-03 10:54:52 +00:00
set(arg_TARGET_COPYRIGHT "Copyright (C) 2022 The Qt Company Ltd.")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
set_target_properties(${target} PROPERTIES
QT_TARGET_VERSION "${arg_TARGET_VERSION}"
QT_TARGET_COMPANY_NAME "${arg_TARGET_COMPANY}"
QT_TARGET_DESCRIPTION "${arg_TARGET_DESCRIPTION}"
QT_TARGET_COPYRIGHT "${arg_TARGET_COPYRIGHT}"
QT_TARGET_PRODUCT_NAME "${arg_TARGET_PRODUCT}")
endfunction()
# Uses the QT_DELAYED_TARGET_* property values to set the final QT_TARGET_* properties.
# Needed when doing executable finalization at the end of a subdirectory scope
# (aka scope finalization).
function(qt_internal_set_target_info_properties_from_delayed_properties target)
set(args "")
foreach(prop ${__default_target_info_args})
get_target_property(prop_value "${target}" "QT_DELAYED_${prop}")
list(APPEND args "${prop}" "${prop_value}")
endforeach()
qt_set_target_info_properties(${target} ${args})
endfunction()
# Updates the QT_DELAYED_ properties with values from the QT_ variants, in case if they were
# set in-between a qt_add_* call and before scope finalization.
function(qt_internal_update_delayed_target_info_properties target)
foreach(prop ${__default_target_info_args})
get_target_property(prop_value "${target}" "QT_${prop}")
get_target_property(delayed_prop_value ${target} "QT_DELAYED_${prop}")
set(final_value "${delayed_prop_value}")
if(prop_value)
set(final_value "${prop_value}")
endif()
set_target_properties(${target} PROPERTIES "QT_DELAYED_${prop}" "${final_value}")
endforeach()
endfunction()
function(qt_internal_check_directory_or_type name dir type default result_var)
if ("x${dir}" STREQUAL x)
if("x${type}" STREQUAL x)
CMake: Rename qt6_add_plugin TYPE option to PLUGIN_TYPE The intention is to remove TYPE as a keyword completely before 6.2.0 release, but in case if that's not possible due to the large amount of repositories and examples, just print a deprecation warning for now and handle both TYPE and PLUGIN_TYPE. Task-number: QTBUG-95170 Pick-to: 6.2 Change-Id: If0c18345483b9254b0fc21120229fcc2a2fbfbf5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-04 14:18:44 +00:00
message(FATAL_ERROR
"qt_internal_add_plugin called without setting either PLUGIN_TYPE or ${name}.")
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endif()
set(${result_var} "${default}" PARENT_SCOPE)
else()
set(${result_var} "${dir}" PARENT_SCOPE)
endif()
endfunction()
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
macro(qt_internal_get_export_additional_targets_keywords option_args single_args multi_args)
set(${option_args}
)
set(${single_args}
EXPORT_NAME_PREFIX
)
set(${multi_args}
TARGETS
TARGET_EXPORT_NAMES
)
endmacro()
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
# Create a Qt*AdditionalTargetInfo.cmake file that is included by Qt*Config.cmake
# and sets IMPORTED_*_<CONFIG> properties on the exported targets.
#
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
# The file also makes the targets global if the QT_PROMOTE_TO_GLOBAL_TARGETS property is set in the
# consuming project.
CMake: Promote all targets to global within a scope when possible CMake 3.21 introduced a new IMPORTED_TARGETS directory property which we can use to promote all imported targets within a scope to be global. This would cover transitive non-Qt imported targets which the Qt build system does not know about and is thus a more complete solution compared to promoting only Qt targets. Run a finalizer at the end of the directory scope where find_package(Qt6) is called to promote all imported targets within that scope to global (when requested). The old promotion method is disabled when the CMake version is new enough. Pick-to: 6.2 Task-number: QTBUG-92878 Task-number: QTBUG-94528 Change-Id: I533a3bd4186eba652f878ddd72c76118c2fd8bae Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-11 07:54:47 +00:00
# When using a CMake version lower than 3.21, only the specified TARGETS are made global.
# E.g. transitive non-Qt 3rd party targets of the specified targets are not made global.
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
#
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
# EXPORT_NAME_PREFIX:
# The portion of the file name before AdditionalTargetInfo.cmake
# CONFIG_INSTALL_DIR:
# Installation location for the target info file
# TARGETS:
# The internal target names. Those must be actual targets.
# TARGET_EXPORT_NAMES:
# The target names how they appear in the QtXXXTargets.cmake files.
# The names get prefixed by ${QT_CMAKE_EXPORT_NAMESPACE}:: unless they already are.
# This argument may be empty, then the target export names are the same as the internal ones.
#
# TARGETS and TARGET_EXPORT_NAMES must contain exactly the same number of elements.
# Example: TARGETS = qmljs_native
# TARGET_EXPORT_NAMES = Qt6::qmljs
#
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
function(qt_internal_export_additional_targets_file)
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
qt_internal_get_export_additional_targets_keywords(option_args single_args multi_args)
cmake_parse_arguments(arg
"${option_args}"
"${single_args};CONFIG_INSTALL_DIR"
"${multi_args}"
${ARGN})
qt_internal_append_export_additional_targets()
set_property(GLOBAL APPEND PROPERTY _qt_export_additional_targets_ids "${id}")
set_property(GLOBAL APPEND
PROPERTY _qt_export_additional_targets_export_name_prefix_${id} "${arg_EXPORT_NAME_PREFIX}")
set_property(GLOBAL APPEND
PROPERTY _qt_export_additional_targets_config_install_dir_${id} "${arg_CONFIG_INSTALL_DIR}")
qt_add_list_file_finalizer(qt_internal_export_additional_targets_file_finalizer)
endfunction()
function(qt_internal_get_export_additional_targets_id export_name out_var)
string(MAKE_C_IDENTIFIER "${export_name}" id)
set(${out_var} "${id}" PARENT_SCOPE)
endfunction()
# Uses outer-scope variables to keep the implementation less verbose.
macro(qt_internal_append_export_additional_targets)
qt_internal_validate_export_additional_targets(
EXPORT_NAME_PREFIX "${arg_EXPORT_NAME_PREFIX}"
TARGETS ${arg_TARGETS}
TARGET_EXPORT_NAMES ${arg_TARGET_EXPORT_NAMES})
qt_internal_get_export_additional_targets_id("${arg_EXPORT_NAME_PREFIX}" id)
set_property(GLOBAL APPEND
PROPERTY _qt_export_additional_targets_${id} "${arg_TARGETS}")
set_property(GLOBAL APPEND
PROPERTY _qt_export_additional_target_export_names_${id} "${arg_TARGET_EXPORT_NAMES}")
endmacro()
# Can be called to add additional targets to the file after the initial setup call.
# Used for resources.
function(qt_internal_add_targets_to_additional_targets_export_file)
qt_internal_get_export_additional_targets_keywords(option_args single_args multi_args)
cmake_parse_arguments(arg
"${option_args}"
"${single_args}"
"${multi_args}"
${ARGN})
qt_internal_append_export_additional_targets()
endfunction()
function(qt_internal_validate_export_additional_targets)
qt_internal_get_export_additional_targets_keywords(option_args single_args multi_args)
cmake_parse_arguments(arg
"${option_args}"
"${single_args}"
"${multi_args}"
${ARGN})
if(NOT arg_EXPORT_NAME_PREFIX)
message(FATAL_ERROR "qt_internal_validate_export_additional_targets: "
"Missing EXPORT_NAME_PREFIX argument.")
endif()
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
list(LENGTH arg_TARGETS num_TARGETS)
list(LENGTH arg_TARGET_EXPORT_NAMES num_TARGET_EXPORT_NAMES)
if(num_TARGET_EXPORT_NAMES GREATER 0)
if(NOT num_TARGETS EQUAL num_TARGET_EXPORT_NAMES)
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
message(FATAL_ERROR "qt_internal_validate_export_additional_targets: "
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
"TARGET_EXPORT_NAMES is set but has ${num_TARGET_EXPORT_NAMES} elements while "
"TARGETS has ${num_TARGETS} elements. "
"They must contain the same number of elements.")
endif()
else()
set(arg_TARGET_EXPORT_NAMES ${arg_TARGETS})
endif()
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
set(arg_TARGETS "${arg_TARGETS}" PARENT_SCOPE)
set(arg_TARGET_EXPORT_NAMES "${arg_TARGET_EXPORT_NAMES}" PARENT_SCOPE)
endfunction()
# The finalizer might be called multiple times in the same scope, but only the first one will
# process all the ids.
function(qt_internal_export_additional_targets_file_finalizer)
get_property(ids GLOBAL PROPERTY _qt_export_additional_targets_ids)
foreach(id ${ids})
qt_internal_export_additional_targets_file_handler("${id}")
endforeach()
set_property(GLOBAL PROPERTY _qt_export_additional_targets_ids "")
endfunction()
function(qt_internal_export_additional_targets_file_handler id)
get_property(arg_EXPORT_NAME_PREFIX GLOBAL PROPERTY
_qt_export_additional_targets_export_name_prefix_${id})
get_property(arg_CONFIG_INSTALL_DIR GLOBAL PROPERTY
_qt_export_additional_targets_config_install_dir_${id})
get_property(arg_TARGETS GLOBAL PROPERTY
_qt_export_additional_targets_${id})
get_property(arg_TARGET_EXPORT_NAMES GLOBAL PROPERTY
_qt_export_additional_target_export_names_${id})
list(LENGTH arg_TARGETS num_TARGETS)
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
# Determine the release configurations we're currently building
if(QT_GENERATOR_IS_MULTI_CONFIG)
set(active_configurations ${CMAKE_CONFIGURATION_TYPES})
else()
set(active_configurations ${CMAKE_BUILD_TYPE})
endif()
unset(active_release_configurations)
foreach(config ${active_configurations})
string(TOUPPER ${config} ucconfig)
if(NOT ucconfig STREQUAL "DEBUG")
list(APPEND active_release_configurations ${config})
endif()
endforeach()
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
if(active_release_configurations)
# Use the first active release configuration as *the* release config for imported targets
# and for QT_DEFAULT_IMPORT_CONFIGURATION.
list(GET active_release_configurations 0 release_cfg)
string(TOUPPER ${release_cfg} uc_release_cfg)
set(uc_default_cfg ${uc_release_cfg})
# Determine the release configurations we do *not* build currently
set(configurations_to_export Release;RelWithDebInfo;MinSizeRel)
list(REMOVE_ITEM configurations_to_export ${active_configurations})
else()
# There are no active release configurations.
# Use the first active configuration for QT_DEFAULT_IMPORT_CONFIGURATION.
unset(uc_release_cfg)
list(GET active_configurations 0 default_cfg)
string(TOUPPER ${default_cfg} uc_default_cfg)
unset(configurations_to_export)
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
endif()
set(content "# Additional target information for ${arg_EXPORT_NAME_PREFIX}
if(NOT DEFINED QT_DEFAULT_IMPORT_CONFIGURATION)
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
set(QT_DEFAULT_IMPORT_CONFIGURATION ${uc_default_cfg})
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
endif()
")
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
math(EXPR n "${num_TARGETS} - 1")
foreach(i RANGE ${n})
list(GET arg_TARGETS ${i} target)
list(GET arg_TARGET_EXPORT_NAMES ${i} target_export_name)
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
CMake: Fix additional target info files ...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING. qt_internal_export_additional_targets_file now gets two lists of target names when run from qt_export_tools: - TARGETS containing actually existing targets, and - TARGET_EXPORT_NAMES containing the target names as they appear in the additional target info file. Operations that require actual targets are run on the TARGETS, in the additional target info file only TARGET_EXPORT_NAMES are written. This distinction is required for the case where the host Qt lacks a tool that is built in the target Qt. Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built in the target Qt. TARGETS contains qmljs_native, and TARGET_EXPORT_NAMES contains qmljs. Fixes: QTBUG-87693 Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2020-10-15 15:11:16 +00:00
set(full_target ${target_export_name})
CMake: Generate *AdditionalTargetInfo.cmake for tools This ensures that we have the configuration-independent IMPORTED_* properties set on tools. Fixes: QTBUG-86893 Change-Id: I2b772c21341e6e4631379d4a5a99580ec96909ed Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 10:18:58 +00:00
if(NOT full_target MATCHES "^${QT_CMAKE_EXPORT_NAMESPACE}::")
string(PREPEND full_target "${QT_CMAKE_EXPORT_NAMESPACE}::")
endif()
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
# Tools are already made global unconditionally in QtFooToolsConfig.cmake.
# And the
get_target_property(target_type ${target} TYPE)
if(NOT target_type STREQUAL "EXECUTABLE")
string(APPEND content
"__qt_internal_promote_target_to_global_checked(${full_target})\n")
endif()
# INTERFACE libraries don't have IMPORTED_LOCATION-like properties.
# OBJECT libraries have properties like IMPORTED_OBJECTS instead.
CMake: Fix typos Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-10 14:41:59 +00:00
# Skip the rest of the processing for those.
CMake: Allow promoting the Qt libraries to be global targets User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-20 11:38:30 +00:00
if(target_type STREQUAL "INTERFACE_LIBRARY" OR target_type STREQUAL "OBJECT_LIBRARY")
continue()
endif()
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
set(properties_retrieved TRUE)
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
# Non-prefix debug-and-release builds: add check for the existence of the debug binary of
# the target. It is not built by default.
if(NOT QT_WILL_INSTALL AND QT_FEATURE_debug_and_release)
get_target_property(excluded_genex ${target} EXCLUDE_FROM_ALL)
if(NOT excluded_genex STREQUAL "")
string(APPEND content "
# ${full_target} is not built by default in the Debug configuration. Check existence.
get_target_property(_qt_imported_location ${full_target} IMPORTED_LOCATION_DEBUG)
if(NOT EXISTS \"$\\{_qt_imported_location}\")
get_target_property(_qt_imported_configs ${full_target} IMPORTED_CONFIGURATIONS)
list(REMOVE_ITEM _qt_imported_configs DEBUG)
set_property(TARGET ${full_target} PROPERTY IMPORTED_CONFIGURATIONS $\\{_qt_imported_configs})
set_property(TARGET ${full_target} PROPERTY IMPORTED_LOCATION_DEBUG)
endif()\n\n")
endif()
endif()
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
set(write_implib FALSE)
set(write_soname FALSE)
if(target_type STREQUAL "SHARED_LIBRARY")
CMake: Fix IMPORTED_IMPLIB to be set for shared libraries on Windows The correct variable to check is WIN32, not WINDOWS. Amends 85e25d93b3b99fbeae8541586252df2cb099081d Pick-to: 6.2 Change-Id: I4570eb5a124bcaa0bd38135dd7c7f48345c40c9d Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
2021-07-14 09:14:51 +00:00
if(WIN32)
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
set(write_implib TRUE)
else()
set(write_soname TRUE)
endif()
endif()
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
if(NOT "${uc_release_cfg}" STREQUAL "")
string(APPEND content "get_target_property(_qt_imported_location ${full_target} IMPORTED_LOCATION_${uc_release_cfg})\n")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
if(write_implib)
string(APPEND content "get_target_property(_qt_imported_implib ${full_target} IMPORTED_IMPLIB_${uc_release_cfg})\n")
endif()
if(write_soname)
string(APPEND content "get_target_property(_qt_imported_soname ${full_target} IMPORTED_SONAME_${uc_release_cfg})\n")
endif()
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
endif()
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
string(APPEND content "get_target_property(_qt_imported_location_default ${full_target} IMPORTED_LOCATION_$\\{QT_DEFAULT_IMPORT_CONFIGURATION})\n")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
if(write_implib)
string(APPEND content "get_target_property(_qt_imported_implib_default ${full_target} IMPORTED_IMPLIB_$\\{QT_DEFAULT_IMPORT_CONFIGURATION})\n")
endif()
if(write_soname)
string(APPEND content "get_target_property(_qt_imported_soname_default ${full_target} IMPORTED_SONAME_$\\{QT_DEFAULT_IMPORT_CONFIGURATION})\n")
endif()
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
foreach(config ${configurations_to_export} "")
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
string(TOUPPER "${config}" ucconfig)
if("${config}" STREQUAL "")
set(property_suffix "")
set(var_suffix "_default")
string(APPEND content "\n# Default configuration")
else()
set(property_suffix "_${ucconfig}")
set(var_suffix "")
string(APPEND content "
# Import target \"${full_target}\" for configuration \"${config}\"
set_property(TARGET ${full_target} APPEND PROPERTY IMPORTED_CONFIGURATIONS ${ucconfig})
")
endif()
string(APPEND content "
if(_qt_imported_location${var_suffix})
set_property(TARGET ${full_target} PROPERTY IMPORTED_LOCATION${property_suffix} \"$\\{_qt_imported_location${var_suffix}}\")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
endif()")
if(write_implib)
string(APPEND content "
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
if(_qt_imported_implib${var_suffix})
set_property(TARGET ${full_target} PROPERTY IMPORTED_IMPLIB${property_suffix} \"$\\{_qt_imported_implib${var_suffix}}\")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
endif()")
endif()
if(write_soname)
string(APPEND content "
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
if(_qt_imported_soname${var_suffix})
set_property(TARGET ${full_target} PROPERTY IMPORTED_SONAME${property_suffix} \"$\\{_qt_imported_soname${var_suffix}}\")
CMake: Set IMPORTED_{SONAME|IMPLIB} for shared libs only In our *AdditionalTargetInfo.cmake we now set above target properties for shared libs only, not executables. IMPORTED_IMPLIB is only set for Windows. IMPORTED_SONAME is only set for non-Windows platforms. Pick-to: 6.2 Change-Id: If7f01e6bf5183cca0ac90f9afffd57c41b34dccd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 08:41:59 +00:00
endif()")
endif()
string(APPEND content "\n")
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
endforeach()
endforeach()
if(properties_retrieved)
string(APPEND content "
unset(_qt_imported_location)
unset(_qt_imported_location_default)
unset(_qt_imported_soname)
Fix build of Debug projects against debug-and-release non-prefix Qt Building a CMake project with CMAKE_BUILD_CONFIG=Debug was broken for non-prefix debug-and-release builds of Qt. In debug-and-release builds we set EXCLUDE_FROM_ALL on tools in the Debug configuration. In non-prefix builds we export(EXPORT) targets, and that also contains the non-existent Debug variants of the tools. In prefix builds, we install(EXPORT) instead, which only exports what is built and installed. Consequently, we now remove the DEBUG-related import information if the debug variant if the target binary does not exist. Pick-to: 6.2 Fixes: QTBUG-95027 Change-Id: I37766d5ab1e2795bcb91a348e7e72150e8a00f82 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-08 07:59:05 +00:00
unset(_qt_imported_soname_default)
unset(_qt_imported_configs)")
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
endif()
CMake: Write proper *AdditionalTargetInfo file in debug-only build To provide the IMPORTED_LOCATION target property we must write the *AdditionalTargetInfo.cmake file for all debug-only builds, not only the ones containing a release configuration. Task-number: QTBUG-86893 Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-25 12:08:46 +00:00
qt_path_join(output_file "${arg_CONFIG_INSTALL_DIR}"
"${arg_EXPORT_NAME_PREFIX}AdditionalTargetInfo.cmake")
if(NOT IS_ABSOLUTE "${output_file}")
qt_path_join(output_file "${QT_BUILD_DIR}" "${output_file}")
endif()
CMake: Fix build of Release user projects against RelWithDebInfo Qt Building a user project in Release configuration against a Qt built with CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project being linked against the Debug Qt libraries. This is especially painful with MSVC where debug and release runtimes are incompatible. We now create *AdditionalTargetInfo.cmake files along the exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties to the values of the release config Qt was built with. User projects built with an unknown configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a release Qt. This can be controlled by setting the variable QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user project. Fixes: QTBUG-86743 Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-22 20:16:20 +00:00
qt_configure_file(OUTPUT "${output_file}" CONTENT "${content}")
qt_install(FILES "${output_file}" DESTINATION "${arg_CONFIG_INSTALL_DIR}")
endfunction()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
function(qt_internal_export_modern_cmake_config_targets_file)
cmake_parse_arguments(__arg "" "EXPORT_NAME_PREFIX;CONFIG_INSTALL_DIR" "TARGETS" ${ARGN})
set(export_name "${__arg_EXPORT_NAME_PREFIX}VersionlessTargets")
foreach(target ${__arg_TARGETS})
if (TARGET "${target}Versionless")
continue()
endif()
add_library("${target}Versionless" INTERFACE)
target_link_libraries("${target}Versionless" INTERFACE "${target}")
set_target_properties("${target}Versionless" PROPERTIES
EXPORT_NAME "${target}"
_qt_is_versionless_target "TRUE")
set_property(TARGET "${target}Versionless"
APPEND PROPERTY EXPORT_PROPERTIES _qt_is_versionless_target)
qt_install(TARGETS "${target}Versionless" EXPORT ${export_name})
endforeach()
qt_install(EXPORT ${export_name} NAMESPACE Qt:: DESTINATION "${__arg_CONFIG_INSTALL_DIR}")
endfunction()
CMake: Rename internal functions to contain qt_internal Offer compatibility wrapper functions until we update all of the Qt repos to use the new names. Task-number: QTBUG-86815 Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2020-09-22 08:02:27 +00:00
function(qt_internal_create_tracepoints name tracepoints_file)
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
string(TOLOWER "${name}" provider_name)
string(PREPEND provider_name "qt")
set(header_filename "${provider_name}_tracepoints_p.h")
set(header_path "${CMAKE_CURRENT_BINARY_DIR}/${header_filename}")
if(QT_FEATURE_lttng OR QT_FEATURE_etw)
set(source_path "${CMAKE_CURRENT_BINARY_DIR}/${provider_name}_tracepoints.cpp")
qt_configure_file(OUTPUT "${source_path}"
CONTENT "#define TRACEPOINT_CREATE_PROBES
#define TRACEPOINT_DEFINE
CMake: Fix generation of XXX_tracepoints.cpp The include directive was incorrectly written. This amends 5c092c2b401. Change-Id: Ia72ca3a5d5e1486ade4d71a764550d36979640f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-10 14:17:16 +00:00
#include \"${header_filename}\"")
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
target_sources(${name} PRIVATE "${source_path}")
target_compile_definitions(${name} PRIVATE Q_TRACEPOINT)
if(QT_FEATURE_lttng)
set(tracegen_arg "lttng")
target_link_libraries(${name} PRIVATE LTTng::UST)
elseif(QT_FEATURE_etw)
set(tracegen_arg "etw")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
CMake: Use host variables instead of hardcoded directories 'QT_HOST_PATH' indicates that we use crosscompilation toolchain to build project. In this case 'Qt6Config.cmake' loads 'Qt6HostInfoConfig.cmake' from host QT_HOST_PATH, that defines correct paths to host tools. Replace hardcoded paths for host tools by paths recorded in Qt6HostInfoConfig.cmake. Correct conditions for QT_HOST_PATH, evaluate it explicitly as string, but not as boolean expression. Fixes: QTBUG-86557 Pick-to: 6.0 Change-Id: Ib52bbd32478051d019a932dcb1f735e2d4aacfbf Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-12-15 17:09:32 +00:00
if(NOT "${QT_HOST_PATH}" STREQUAL "")
CMake: Fix call to tracegen when cross-compiling tools We need to use the imported host tracegen target to generate files, not the one we're going to cross-build. This amends 5c092c2b401. Change-Id: Ib74dd2d87110383c31216872eb55bebf5d90df37 Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
2020-09-03 10:04:54 +00:00
qt_path_join(tracegen
"${QT_HOST_PATH}"
Move build tools to libexec instead of the bin dir [ChangeLog][Build System] Tools that are called by the build system and are unlikely to be called by the user are now installed to the libexec directory. This is a step towards easier co-installability of different Qt versions. Pick-to: 6.1 Task-number: QTBUG-88791 Change-Id: Id19575b5ba27795f7715e4ea6a09391b26dd4942 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2021-01-25 10:12:37 +00:00
"${QT${PROJECT_VERSION_MAJOR}_HOST_INFO_LIBEXECDIR}"
CMake: Fix call to tracegen when cross-compiling tools We need to use the imported host tracegen target to generate files, not the one we're going to cross-build. This amends 5c092c2b401. Change-Id: Ib74dd2d87110383c31216872eb55bebf5d90df37 Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
2020-09-03 10:04:54 +00:00
"tracegen")
else()
set(tracegen "${QT_CMAKE_EXPORT_NAMESPACE}::tracegen")
endif()
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
get_filename_component(tracepoints_filepath "${tracepoints_file}" ABSOLUTE)
add_custom_command(OUTPUT "${header_path}"
CMake: Fix call to tracegen when cross-compiling tools We need to use the imported host tracegen target to generate files, not the one we're going to cross-build. This amends 5c092c2b401. Change-Id: Ib74dd2d87110383c31216872eb55bebf5d90df37 Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
2020-09-03 10:04:54 +00:00
COMMAND ${tracegen} ${tracegen_arg} "${tracepoints_filepath}" "${header_path}"
CMake: Implement configure -trace Task-number: QTBUG-85373 Change-Id: Ib9ac35ec98dd5b6c272f58f8a61a124d1d262ec0 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-08-24 19:05:05 +00:00
VERBATIM)
add_custom_target(${name}_tracepoints_header DEPENDS "${header_path}")
add_dependencies(${name} ${name}_tracepoints_header)
else()
qt_configure_file(OUTPUT "${header_path}" CONTENT "#include <private/qtrace_p.h>\n")
endif()
CMake: Split QtBuild.cmake into smaller files QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-08-13 15:37:47 +00:00
endfunction()
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
function(qt_internal_set_compile_pdb_names target)
if(MSVC)
get_target_property(target_type ${target} TYPE)
Install MSVC debug information for resource object libraries Building against a static debug MSVC Qt produced LNK4099 warnings (PDB was not found with object file). This was because we did not install the .pdb files for the object libraries that are created for Qt resources. Now, these .pdb files are named like the object library targets and are installed next to the object files. Pick-to: 6.2 Fixes: QTBUG-97699 Change-Id: I7e23f8392b7ac657be1d2fb3b33e051ae2e4d407 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-11-29 20:18:43 +00:00
if(target_type STREQUAL "STATIC_LIBRARY" OR target_type STREQUAL "OBJECT_LIBRARY")
CMake: set correct COMPILE_PDB_NAME for static libraries Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-30 15:38:02 +00:00
get_target_property(output_name ${target} OUTPUT_NAME)
if(NOT output_name)
set(output_name "${INSTALL_CMAKE_NAMESPACE}${target}")
endif()
set_target_properties(${target} PROPERTIES COMPILE_PDB_NAME "${output_name}")
set_target_properties(${target} PROPERTIES COMPILE_PDB_NAME_DEBUG "${output_name}d")
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
endif()
endif()
endfunction()
# Installs pdb files for given target into the specified install dir.
#
# MSVC generates 2 types of pdb files:
# - compile-time generated pdb files (compile flag /Zi + /Fd<pdb_name>)
CMake: Fix typos Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-10 14:41:59 +00:00
# - link-time generated pdb files (link flag /debug + /PDB:<pdb_name>)
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
#
# CMake allows changing the names of each of those pdb file types by setting
# the COMPILE_PDB_NAME_<CONFIG> and PDB_NAME_<CONFIG> properties. If they are
# left empty, CMake will compute the default names itself (or rather in certain cases
CMake: Fix typos Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-10 14:41:59 +00:00
# leave it up to the compiler), without actually setting the property values.
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
#
# For installation purposes, CMake only provides a generator expression to the
# link time pdb file path, not the compile path one, which means we have to compute the
# path to the compile path pdb files ourselves.
# See https://gitlab.kitware.com/cmake/cmake/-/issues/18393 for details.
#
# For shared libraries and executables, we install the linker provided pdb file via the
# TARGET_PDB_FILE generator expression.
#
# For static libraries there is no linker invocation, so we need to install the compile
# time pdb file. We query the ARCHIVE_OUTPUT_DIRECTORY property of the target to get the
# path to the pdb file, and reconstruct the file name. We use a generator expression
# to append a possible debug suffix, in order to allow installation of all Release and
# Debug pdb files when using Ninja Multi-Config.
function(qt_internal_install_pdb_files target install_dir_path)
if(MSVC)
get_target_property(target_type ${target} TYPE)
CMake: Install pdb files to proper directories in multi-config build In multi-config build, for different configs, the pdb files of EXEs should have different installation directories. For example, when CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug, <build_dir>/bin/moc.pdb will be installed to <install_dir>/bin/moc.pdb. <build_dir>/bin/Debug/moc.pdb should be installed to <install_dir>/bin/Debug/moc.pdb, not <install_dir>/bin/moc.pdb. Fixes: QTBUG-88268 Change-Id: Idc7c92ca8d44bb81d990656af2b309306a4f5c6b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-13 09:27:12 +00:00
if(target_type STREQUAL "EXECUTABLE")
qt_get_cmake_configurations(cmake_configs)
list(LENGTH cmake_configs all_configs_count)
list(GET cmake_configs 0 first_config)
foreach(cmake_config ${cmake_configs})
set(suffix "")
if(all_configs_count GREATER 1 AND NOT cmake_config STREQUAL first_config)
set(suffix "/${cmake_config}")
endif()
qt_install(FILES "$<TARGET_PDB_FILE:${target}>"
CONFIGURATIONS ${cmake_config}
DESTINATION "${install_dir_path}${suffix}"
OPTIONAL)
endforeach()
elseif(target_type STREQUAL "SHARED_LIBRARY"
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
OR target_type STREQUAL "MODULE_LIBRARY")
qt_install(FILES "$<TARGET_PDB_FILE:${target}>"
DESTINATION "${install_dir_path}"
OPTIONAL)
elseif(target_type STREQUAL "STATIC_LIBRARY")
get_target_property(lib_dir "${target}" ARCHIVE_OUTPUT_DIRECTORY)
if(NOT lib_dir)
message(FATAL_ERROR
"Can't install pdb file for static library ${target}. "
"The ARCHIVE_OUTPUT_DIRECTORY path is not known.")
endif()
CMake: set correct COMPILE_PDB_NAME for static libraries Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-30 15:38:02 +00:00
get_target_property(pdb_name "${target}" COMPILE_PDB_NAME)
qt_path_join(compile_time_pdb_file_path
"${lib_dir}" "${pdb_name}$<$<CONFIG:Debug>:d>.pdb")
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
qt_install(FILES "${compile_time_pdb_file_path}"
DESTINATION "${install_dir_path}" OPTIONAL)
Install MSVC debug information for resource object libraries Building against a static debug MSVC Qt produced LNK4099 warnings (PDB was not found with object file). This was because we did not install the .pdb files for the object libraries that are created for Qt resources. Now, these .pdb files are named like the object library targets and are installed next to the object files. Pick-to: 6.2 Fixes: QTBUG-97699 Change-Id: I7e23f8392b7ac657be1d2fb3b33e051ae2e4d407 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-11-29 20:18:43 +00:00
elseif(target_type STREQUAL "OBJECT_LIBRARY")
get_target_property(pdb_dir "${target}" COMPILE_PDB_OUTPUT_DIRECTORY)
if(NOT pdb_dir)
get_target_property(pdb_dir "${target}" BINARY_DIR)
if(QT_GENERATOR_IS_MULTI_CONFIG)
qt_path_join(pdb_dir "${pdb_dir}" "$<CONFIG>")
endif()
endif()
CMake: set correct COMPILE_PDB_NAME for static libraries Output names of static libraries might be different from target names. For example, the library name of Qt6::DeviceDiscoverySupportPrivate is "Qt6DeviceDiscoverySupport.lib", and the library name of Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib". This commit make pdb files names consistent with the library names. And make sure we have set correct OUTPUT_NAME property before calling qt_set_common_target_properties()/qt_internal_set_compile_pdb_names(). Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-04-30 15:38:02 +00:00
get_target_property(pdb_name "${target}" COMPILE_PDB_NAME)
qt_path_join(compile_time_pdb_file_path
"${pdb_dir}" "${pdb_name}$<$<CONFIG:Debug>:d>.pdb")
Install MSVC debug information for resource object libraries Building against a static debug MSVC Qt produced LNK4099 warnings (PDB was not found with object file). This was because we did not install the .pdb files for the object libraries that are created for Qt resources. Now, these .pdb files are named like the object library targets and are installed next to the object files. Pick-to: 6.2 Fixes: QTBUG-97699 Change-Id: I7e23f8392b7ac657be1d2fb3b33e051ae2e4d407 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-11-29 20:18:43 +00:00
qt_install(FILES "${compile_time_pdb_file_path}"
DESTINATION "${install_dir_path}" OPTIONAL)
CMake: Install PDB debug info for MSVC builds Supports installing linker generated debug info for shared libraries and executables, as well as compiler generated debug info for static libraries. Works with Ninja Multi-Config as well, with the caveat that the files are installed optionally, aka the install rule will not error out if a pdb file is not present. This is necessary, because it's not possible to create per-config install rules properly. Fixes: QTBUG-87006 Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-09-29 20:07:33 +00:00
endif()
endif()
endfunction()
CMake: Fix building multi-arch universal macOS Qt Use the same approach we use for iOS, which is to set multiple CMAKE_OSX_ARCHITECTURES values and let the clang front end deal with lipo-ing the final libraries. For now, Qt can be configured to build universal macOS libraries by passing 2 architectures to CMake, either via: -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" or -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" Currently we recommend specifying the intel x86_64 arch as the first one, to get an intel slice configuration that is comparable to a non-universal intel build. Specifying the arm64 slice first could pessimize optimizations and reduce the feature set for the intel slice due to the limitation that we run configure tests only once. The first specified architecture is the one used to do all the configure tests. It 'mostly' defines the common feature set of both architecture slices, with the excepion of some special handling for sse2 and neon instructions. In the future we might want to run at least the Qt architecture config test for all specified architectures, so that we can extract all the supported sub-arches and instruction sets in a reliable way. For now, we use the same sse2 hack as for iOS simulator_and_device builds, otherwise QtGui fails to link due to missing qt_memfill32_sse2 and other symbols. The hack is somewhat augmented to ensure that reconfiguration still succeeds (same issue happened with iOS). Previously the sse2 feature condition was broken due to force setting the feature to be ON. Now the condition also checks for a special QT_FORCE_FEATURE_sse2 variable which we set internally. Note that we shouldn't build for arm64e, because the binaries get killed when running on AS with the following message: kernel: exec_mach_imgact: not running binary built against preview arm64e ABI. Aslo, by default, we disable the arm64 slice for qt sql plugins, mostly because the CI provisioned sql libraries that we depend on only contain x86_64 slices, and trying to build the sql plugins for both slices will fail with linker errors. This behavior can be disabled for all targets marked by qt_internal_force_macos_intel_arch, by setting the QT_FORCE_MACOS_ALL_ARCHES CMake option to ON. To disble it per-target one can set QT_FORCE_MACOS_ALL_ARCHES_${target} to ON. Task-number: QTBUG-85447 Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-03-24 15:03:35 +00:00
# Certain targets might have dependencies on libraries that don't have an Apple Silicon arm64
# slice. When doing a universal macOS build, force those targets to be built only for the
# Intel x86_64 arch.
# This behavior can be disabled for all targets by setting the QT_FORCE_MACOS_ALL_ARCHES cache
# variable to TRUE or by setting the target specific cache variable
# QT_FORCE_MACOS_ALL_ARCHES_${target} to TRUE.
#
# TODO: Ideally we'd use something like _apple_resolve_supported_archs_for_sdk_from_system_lib
# from CMake's codebase to parse which architectures are available in a library, but it's
# not straightforward to extract the library absolute file path from a CMake target. Furthermore
# Apple started using a built-in dynamic linker cache of all system-provided libraries as per
# https://gitlab.kitware.com/cmake/cmake/-/issues/20863
# so if the target is a library in the dynamic cache, that might further complicate how to get
# the list of arches in it.
function(qt_internal_force_macos_intel_arch target)
if(MACOS AND QT_IS_MACOS_UNIVERSAL AND NOT QT_FORCE_MACOS_ALL_ARCHES
AND NOT QT_FORCE_MACOS_ALL_ARCHES_${target})
set(arches "x86_64")
set_target_properties(${target} PROPERTIES OSX_ARCHITECTURES "${arches}")
endif()
endfunction()
CMake: Allow enabling Apple app extension API in other repos It's needed in qtconnectivity, but currently the qt_disable_apple_app_extension_api_only function is defined in QtInternalTargets.cmake which is loaded only in qtbase. Move the function to cmake/QtTargetHelpers.cmake. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.1 Change-Id: Ia2470e48a91385239394368780f5bbb223000113 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-22 07:55:55 +00:00
function(qt_disable_apple_app_extension_api_only target)
set_target_properties("${target}" PROPERTIES QT_NO_APP_EXTENSION_ONLY_API TRUE)
endfunction()
Do not use qt_internal_module_info for non-module targets The qt_internal_module_info function suppose to provide the information only about the Qt modules. Avoid using it for the tool and extra package dependencies, since some targets do not always exist, when function is called. Add the qt_internal_qtfy_target function to make the prefixed target names. Change-Id: Ifa8c61064d9c6c430889f00a4ead304029da711b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-28 15:24:30 +00:00
# Common function to add Qt prefixes to the target name
function(qt_internal_qtfy_target out_var target)
set(${out_var} "Qt${target}" PARENT_SCOPE)
set(${out_var}_versioned "Qt${PROJECT_VERSION_MAJOR}${target}" PARENT_SCOPE)
endfunction()
CMake: Place internal apps in the correct output directory In a -debug-and-release build, apps were placed under bin/Release rather than just bin. Apply the logic we use for tools for apps as well. Rename and move the common functions into QtTargetHelpers.cmake. Pick-to: 6.2 Fixes: QTBUG-95028 Change-Id: I5a9082ea50c9238c8fcf0c6dd099708fbc571bf8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-07 14:04:17 +00:00
function(qt_internal_get_main_cmake_configuration out_var)
if(CMAKE_BUILD_TYPE)
set(config "${CMAKE_BUILD_TYPE}")
elseif(QT_MULTI_CONFIG_FIRST_CONFIG)
set(config "${QT_MULTI_CONFIG_FIRST_CONFIG}")
endif()
set("${out_var}" "${config}" PARENT_SCOPE)
endfunction()
function(qt_internal_get_upper_case_main_cmake_configuration out_var)
qt_internal_get_main_cmake_configuration("${out_var}")
string(TOUPPER "${${out_var}}" upper_config)
set("${out_var}" "${upper_config}" PARENT_SCOPE)
endfunction()
function(qt_internal_adjust_main_config_runtime_output_dir target output_dir)
# When building Qt with multiple configurations, place the main configuration executable
# directly in ${output_dir}, rather than a ${output_dir}/<CONFIG> subdirectory.
qt_internal_get_upper_case_main_cmake_configuration(main_cmake_configuration)
set_target_properties("${target}" PROPERTIES
RUNTIME_OUTPUT_DIRECTORY_${main_cmake_configuration} "${output_dir}"
)
endfunction()
CMake: Don't propagate -fapplication-extension to user projects Both the compiler and linker -fapplication-extension flag should only be applied when building Qt's libraries (not executables). It's up to the user project whether their code will be restricted with application-extension-only APIs. In qmake that can be achieved by adding to the qmake project CONFIG += app_extension_api_only In CMake it can be achieved by either adding the compiler and link flags in the project directly (using target_X_options) or by setting the appropriate setting in the Xcode project when using the Xcode generator. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.2 Task-number: QTBUG-95199 Change-Id: Ie7a764d460a89c7650391abff0fcc5abfcabef64 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 11:04:15 +00:00
# Marks a target with a property that it is a library (shared or static) which was built using the
# internal Qt API (qt_internal_add_module, qt_internal_add_plugin, etc) as opposed to it being
# a user project library (qt_add_library, qt_add_plugin, etc).
#
# Needed to allow selectively applying certain flags via PlatformXInternal targets.
function(qt_internal_mark_as_internal_library target)
set_target_properties(${target} PROPERTIES _qt_is_internal_library TRUE)
endfunction()
CMake: Apply bitcode flags to internal plugin object lib initializers All internal libraries, plugins, object libraries (resources, plugin initializers) need to be built with bitcode flags when targeting iOS. Internal here means all libraries added by qt_internal_add_X functions or associated with internal libraries. We didn't do that for plugin initializers, which were added not too long ago. Extract the logic that links to Qt::PlatformModuleInternal into a separate function to be used for object libraries. Use it for resources and plugin initializers. It will also be used in qtdeclarative for qml plugin initializers. Pick-to: 6.2 Task-number: QTBUG-95208 Change-Id: I366996078f5e9d1c2d2797f6b81c522ee99529e3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-15 11:41:15 +00:00
function(qt_internal_link_internal_platform_for_object_library target)
# We need to apply iOS bitcode flags to object libraries that are associated with internal
# modules or plugins (e.g. object libraries added by qt_internal_add_resource,
# qt_internal_add_plugin, etc.)
# The flags are needed when building iOS apps because Xcode expects bitcode to be
# present by default.
# Achieve this by compiling the cpp files with the PlatformModuleInternal compile flags.
target_link_libraries("${target}" PRIVATE Qt::PlatformModuleInternal)
endfunction()
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
Don't export Qt6::ATSPI2_nolink target in Qt6GuiTargets.cmake We don't have any APSPI2 includes in our public headers and should therefore not export the target that provides ATSPI2 include paths for consumers. Link against PkgConfig::ATSPI2 instead of the _nolink target. The former will not be exported. Pick-to: 6.2 Fixes: QTBUG-97023 Change-Id: I4b12e0c2230917feeb963c02565e6db24f757bd3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-01 07:48:42 +00:00
# Use ${dep_target}'s include dirs when building ${target}.
#
# Assumes ${dep_target} is an INTERFACE_LIBRARY that only propagates include dirs and ${target}
# is a Qt module / plugin.
#
# Building ${target} requires ${dep_target}'s include dirs.
# Using ${target} does not require ${dep_target}'s include dirs.
#
# The main use case is adding the private header-only dependency PkgConfig::ATSPI2.
function(qt_internal_add_target_include_dirs target dep_target)
if(NOT TARGET "${target}")
message(FATAL_ERROR "${target} is not a valid target.")
endif()
if(NOT TARGET "${dep_target}")
message(FATAL_ERROR "${dep_target} is not a valid target.")
endif()
target_include_directories("${target}" PRIVATE
"$<TARGET_PROPERTY:${dep_target},INTERFACE_INCLUDE_DIRECTORIES>")
endfunction()
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
# Use ${dep_target}'s include dirs when building ${target} and optionally propagate the include
# dirs to consumers of ${target}.
# Assumes ${dep_target} is an INTERFACE_LIBRARY that only propagates include dirs and ${target}
# is a Qt module / plugin.
#
# Building ${target} requires ${dep_target}'s include dirs.
#
# User projects that don't have ${dep_target}'s headers installed in their system should still
# configure successfully.
#
# To achieve that, consumers of ${target} will only get the include directories of ${dep_target}
# if the latter package and target exists.
#
CMake: Clarify qt_record_extra_third_party_dependency docs Pick-to: 6.4 Change-Id: I458a5b488741c639650c8b3b6668c82c80b5e93f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-08 15:11:59 +00:00
# A find_package(dep_target) dependency is added to ${target}'s *Dependencies.cmake file.
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
#
# We use target_include_directories(PRIVATE) instead of target_link_libraries(PRIVATE) because the
# latter would propagate a mandatory LINK_ONLY dependency on the ${dep_target} in a static Qt build.
#
# The main use case is for propagating WrapVulkanHeaders::WrapVulkanHeaders.
function(qt_internal_add_target_include_dirs_and_optionally_propagate target dep_target)
Don't export Qt6::ATSPI2_nolink target in Qt6GuiTargets.cmake We don't have any APSPI2 includes in our public headers and should therefore not export the target that provides ATSPI2 include paths for consumers. Link against PkgConfig::ATSPI2 instead of the _nolink target. The former will not be exported. Pick-to: 6.2 Fixes: QTBUG-97023 Change-Id: I4b12e0c2230917feeb963c02565e6db24f757bd3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-01 07:48:42 +00:00
qt_internal_add_target_include_dirs(${target} ${dep_target})
CMake: Make WrapVulkanHeaders target optional for QtGui consumers If Vulkan headers are present on the system when qtbase is configured, QtGui and QtOpenGL should be compiled with Vulkan support. If a user project uses a Qt built with Vulkan support, but their system is missing Vulkan headers, the project configuration needs to succeed. The project will get compilation errors if it uses Vulkan headers, but that's intended. This use case was broken when fixing Vulkan to be found when building Qt for Android. Fix the regression with a combination of things 1) Mark the WrapVulkanHeaders package as optional (already the case) 2) Use the include directories directly when compiling Gui and OpenGL 3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to consumers only if the target exists. It won't exist if Vulkan include dirs are not found This also requires some changes in pri and prl file generation. For prl file generation, we don't want to link to the WrapVulkanHeaders target, so we filter out all dependencies that use TARGET_NAME_IF_EXISTS for anything that calls __qt_internal_walk_libs which includes qt_collect_libs. For pri files, we make sure to generate a uses=vulkan/nolink clause by inspecting a new _qt_is_nolink_target property on the target. We also don't add include dirs to the pri file if the new _qt_skip_include_dir_for_pri property is set. This is intended for Vulkan, because there is separate qmake logic to try and find the include dirs when configuring a user project. As a drive-by, fix nolink handling for WrapOpenSSLHeaders. Amends bb25536a3db657b41ae31e1690d230ef8722b57d Amends 7b9904849fe1a43f0db8216076a9e974ebca5c78 Pick-to: 6.2 Fixes: QTBUG-95391 Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-27 11:54:56 +00:00
target_link_libraries("${target}" INTERFACE "$<TARGET_NAME_IF_EXISTS:${dep_target}>")
qt_record_extra_third_party_dependency("${target}" "${dep_target}")
endfunction()
Add qt_internal_undefine_global_definition function qt_internal_undefine_global_definition disables an internal global definition that is defined by the qt_internal_add_global_definition function for a specific target. Remove the ability to set the custom "undefine" flag for the definitions since it's hard to control it using the introduced function. Pick-to: 6.2 6.3 Task-number: QTBUG-100334 Change-Id: Ic1637d97aa51bbdd06c5b191c57a941aa208d4dc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-01-31 17:53:57 +00:00
# The function disables one or multiple internal global definitions that are defined by the
# qt_internal_add_global_definition function for a specific 'target'.
function(qt_internal_undefine_global_definition target)
if(NOT TARGET ${target})
message(FATAL_ERROR "${target} is not a target.")
endif()
if("${ARGN}" STREQUAL "")
message(FATAL_ERROR "The function expects at least one definition as an argument.")
endif()
foreach(definition IN LISTS ARGN)
set(undef_property_name "QT_INTERNAL_UNDEF_${definition}")
set_target_properties(${target} PROPERTIES "${undef_property_name}" TRUE)
endforeach()
endfunction()
build system: support module local definitions This introduces a new helper function, qt_internal_add_repo_local_defines and makes use of it in qt_internal_add_{module,test,executable,benchmark,plugin}. That function checks whether QT_EXTRA_INTERNAL_TARGET_DEFINES is set. If it is, the defines listed in there will be aded to all targets passed to the functions mentioned above. The intended usage is that QT_EXTRA_INTERNAL_TARGET_DEFINES gets set in the repository local .cmake.conf. This allows e.g. opting in to source incompatible changes in leaf modules (as long as those are guarded by some define). Pick-to: 6.2 6.3 Fixes: QTBUG-101640 Change-Id: I06c3693ee69f46e95a48de724621f0c97e7cc3a8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-11 11:41:36 +00:00
# This function adds any defines which are local to the current repository (e.g. qtbase,
# qtmultimedia). Those can be defined in the corresponding .cmake.conf file via
# QT_EXTRA_INTERNAL_TARGET_DEFINES. QT_EXTRA_INTERNAL_TARGET_DEFINES accepts a list of definitions.
# The definitions are passed to target_compile_definitions, which means that values can be provided
# via the FOO=Bar syntax
# This does nothing for interface targets
function(qt_internal_add_repo_local_defines target)
get_target_property(type "${target}" TYPE)
if (${type} STREQUAL "INTERFACE_LIBRARY")
return()
endif()
if(DEFINED QT_EXTRA_INTERNAL_TARGET_DEFINES)
target_compile_definitions("${target}" PRIVATE ${QT_EXTRA_INTERNAL_TARGET_DEFINES})
endif()
endfunction()
Reference in New Issue Copy Permalink