qiurui
/
qtbase
mirror of https://github.com/qt/qtbase.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
qtbase/src/corelib/Qt6CoreMacros.cmake

3208 lines
127 KiB
CMake
Raw Normal View History

Install CMake config files from Qt. This includes a BSD licenced file Qt5CoreMacros.cmake which is adapted from Qt4Macros.cmake in the CMake source tree. Change-Id: I54326b808795535490a0489659b351a8da72cdbb Reviewed-by: Clinton Stimpson <clinton@elemtech.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2011-11-01 13:59:23 +00:00
# Copyright 2005-2011 Kitware, Inc.
Add license headers to cmake files CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 11:26:52 +00:00
# Copyright (C) 2022 The Qt Company Ltd.
# SPDX-License-Identifier: (LicenseRef-Qt-Commercial OR GPL-3.0-only WITH Qt-GPL-exception-1.0) AND BSD-3-Clause
Install CMake config files from Qt. This includes a BSD licenced file Qt5CoreMacros.cmake which is adapted from Qt4Macros.cmake in the CMake source tree. Change-Id: I54326b808795535490a0489659b351a8da72cdbb Reviewed-by: Clinton Stimpson <clinton@elemtech.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2011-11-01 13:59:23 +00:00
######################################
#
# Macros for building Qt files
#
######################################
Port to CMakeParseArguments from a custom rolled macro. Change-Id: Ia7bf5046420ee8f2d690d098937a212eb75b07ce Reviewed-by: Clinton Stimpson <clinton@elemtech.com> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-05 01:06:21 +00:00
include(CMakeParseArguments)
Install CMake config files from Qt. This includes a BSD licenced file Qt5CoreMacros.cmake which is adapted from Qt4Macros.cmake in the CMake source tree. Change-Id: I54326b808795535490a0489659b351a8da72cdbb Reviewed-by: Clinton Stimpson <clinton@elemtech.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2011-11-01 13:59:23 +00:00
CMake: Fix unnecessary rebuilding upon reconfiguration The following MR in upstream CMake makes sure that the autogen targets depend on the CMakeLists.txt file associated with the autogen target, as well as any files it includes. https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5166 When doing a no-op reconfiguration in the build dir (call 'cmake .') we used file(WRITE) to prepare the contents of a file to be used with configure_file() for creation of a .qrc resource file. Because this file was always rewritten on reconfiguration, its timestamp was newer than then autogen target's timestamp which caused the autogen targets to-be rerun, as well as some compilation and relinking. To avoid this, instead of using file(WRITE) ship a template file next to the Qt6CoreMacros.cmake file, and use it as a template for the qrc configure_file() call. This ensures that a reconfiguration doesn't necessarily rebuild things it shouldn't rebuild. Amends 113f1ad324202ea2b861a3dbdec2ee7ef716c283 Task-number: QTBUG-88004 Change-Id: Icd95b28ca3642434cf21e5c49dcbd1ec65d76252 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-30 15:46:40 +00:00
set(__qt_core_macros_module_base_dir "${CMAKE_CURRENT_LIST_DIR}")
Install CMake config files from Qt. This includes a BSD licenced file Qt5CoreMacros.cmake which is adapted from Qt4Macros.cmake in the CMake source tree. Change-Id: I54326b808795535490a0489659b351a8da72cdbb Reviewed-by: Clinton Stimpson <clinton@elemtech.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2011-11-01 13:59:23 +00:00
# macro used to create the names of output files preserving relative dirs
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
macro(_qt_internal_make_output_file infile prefix ext outfile )
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
string(LENGTH ${CMAKE_CURRENT_BINARY_DIR} _binlength)
string(LENGTH ${infile} _infileLength)
set(_checkinfile ${CMAKE_CURRENT_SOURCE_DIR})
if(_infileLength GREATER _binlength)
string(SUBSTRING "${infile}" 0 ${_binlength} _checkinfile)
if(_checkinfile STREQUAL "${CMAKE_CURRENT_BINARY_DIR}")
file(RELATIVE_PATH rel ${CMAKE_CURRENT_BINARY_DIR} ${infile})
else()
file(RELATIVE_PATH rel ${CMAKE_CURRENT_SOURCE_DIR} ${infile})
endif()
else()
file(RELATIVE_PATH rel ${CMAKE_CURRENT_SOURCE_DIR} ${infile})
endif()
Qt5CoreMacros: Sync with CMake project counterpart Port of CMake commits: commit 2622bc3f65162bf6d6cb5838da6999f8b5ca75cf Author: Rolf Eike Beer <eike@sf-mail.de> Date: Sun Apr 6 21:30:00 2014 +0200 Clean up usage of if(... MATCHES regex) followed string(REGEX REPLACE regex) commit 7beba98652212c7a44f291b51dd03681e5193c49 Author: Robert Maynard <robert.maynard@kitware.com> Date: Thu Apr 3 11:27:58 2014 -0400 Qt4Macros: Make QT4_CREATE_MOC_COMMAND a function Change-Id: I5b928d114adb393ed9370163609311b7486e4a36 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-12-21 16:56:55 +00:00
if(WIN32 AND rel MATCHES "^([a-zA-Z]):(.*)$") # absolute path
set(rel "${CMAKE_MATCH_1}_${CMAKE_MATCH_2}")
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
endif()
set(_outfile "${CMAKE_CURRENT_BINARY_DIR}/${rel}")
string(REPLACE ".." "__" _outfile ${_outfile})
get_filename_component(outpath ${_outfile} PATH)
Merge remote-tracking branch 'origin/5.15' into dev Conflicts: examples/widgets/graphicsview/boxes/scene.h src/corelib/Qt5CoreMacros.cmake src/corelib/Qt6CoreMacros.cmake src/network/ssl/qsslsocket.cpp src/network/ssl/qsslsocket.h src/platformsupport/fontdatabases/windows/qwindowsfontenginedirectwrite.cpp src/testlib/CMakeLists.txt src/testlib/.prev_CMakeLists.txt tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp Disabled building manual tests with CMake for now, because qmake doesn't do it, and it confuses people. Done-With: Alexandru Croitor <alexandru.croitor@qt.io> Done-With: Volker Hilsheimer <volker.hilsheimer@qt.io> Change-Id: I865ae347bd01f4e59f16d007b66d175a52f1f152
2020-02-13 08:14:09 +00:00
if(CMAKE_VERSION VERSION_LESS "3.14")
get_filename_component(_outfile_ext ${_outfile} EXT)
get_filename_component(_outfile_ext ${_outfile_ext} NAME_WE)
get_filename_component(_outfile ${_outfile} NAME_WE)
string(APPEND _outfile ${_outfile_ext})
else()
get_filename_component(_outfile ${_outfile} NAME_WLE)
endif()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
file(MAKE_DIRECTORY ${outpath})
set(${outfile} ${outpath}/${prefix}${_outfile}.${ext})
endmacro()
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
macro(_qt_internal_get_moc_flags _moc_flags)
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
set(${_moc_flags})
get_directory_property(_inc_DIRS INCLUDE_DIRECTORIES)
CMake: Improve QT5_GET_MOC_FLAGS macro We need to handle CMAKE_INCLUDE_CURRENT_DIR for include directories. Otherwise generated files located in the current binary directory are not found as expected. e.g. *.json file as meta data for Qt5's plugins generated at build time. Change-Id: I14ae1e7013f9d8b485aa990d50db4a03ca4f4b81 Reviewed-by: Yuchen Deng <loaden@gmail.com> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2012-10-02 10:04:00 +00:00
if(CMAKE_INCLUDE_CURRENT_DIR)
list(APPEND _inc_DIRS ${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR})
endif()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
foreach(_current ${_inc_DIRS})
if("${_current}" MATCHES "\\.framework/?$")
string(REGEX REPLACE "/[^/]+\\.framework" "" framework_path "${_current}")
set(${_moc_flags} ${${_moc_flags}} "-F${framework_path}")
else()
set(${_moc_flags} ${${_moc_flags}} "-I${_current}")
endif()
endforeach()
get_directory_property(_defines COMPILE_DEFINITIONS)
foreach(_current ${_defines})
set(${_moc_flags} ${${_moc_flags}} "-D${_current}")
endforeach()
Use the CMake definition of Windows for CMake macros. Change-Id: I599ddaaf9176f76f2e144c893e607757957dfef2 Reviewed-by: Clinton Stimpson <clinton@elemtech.com> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2012-02-23 00:05:46 +00:00
if(WIN32)
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
set(${_moc_flags} ${${_moc_flags}} -DWIN32)
endif()
Make moc obey the preprocessor environment variable for include paths C preprocessors augment their standard list of include paths from the environment: Unix preprocessors use $C_INCLUDE_PATH (for C) and $CPLUS_INCLUDE_PATH (for C++), plus CPATH for both, whereas MSVC uses the an environment variable simply called "INCLUDE". Handling this for MSVC is particularly important because the VCVARSALL.BAT script sets the necessary #include paths in the environment for important things. Without that being parsed, moc won't find some #defines, like WINAPI_DESKTOP_FAMILY. [ChangeLog][moc] qmake and moc now cooperate to use the Visual Studio environment variables (set by the VCVARSALL.BAT script) to find system include files. A possible consequence is that moc parses application headers slightly differently, depending on #if conditions that depended on macros that previous versions had not seen #define'd. Implementers of other buildsystems are advised to pass the --compiler-flavor=msvc option to moc. Change-Id: I7e06274214d1939b0124e5b4bf169cceaef9ca46 Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
2016-04-14 00:25:37 +00:00
if (MSVC)
Qt5CoreMacros: append the --compiler-flavor=msvc flag Previously, the flags were replaced rather than appended to, losing -I flags and causing `#include` directives to fail. Change-Id: I74609e891ea327a8136c8075ab13176fc85ab111 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2017-02-01 19:05:35 +00:00
set(${_moc_flags} ${${_moc_flags}} --compiler-flavor=msvc)
Make moc obey the preprocessor environment variable for include paths C preprocessors augment their standard list of include paths from the environment: Unix preprocessors use $C_INCLUDE_PATH (for C) and $CPLUS_INCLUDE_PATH (for C++), plus CPATH for both, whereas MSVC uses the an environment variable simply called "INCLUDE". Handling this for MSVC is particularly important because the VCVARSALL.BAT script sets the necessary #include paths in the environment for important things. Without that being parsed, moc won't find some #defines, like WINAPI_DESKTOP_FAMILY. [ChangeLog][moc] qmake and moc now cooperate to use the Visual Studio environment variables (set by the VCVARSALL.BAT script) to find system include files. A possible consequence is that moc parses application headers slightly differently, depending on #if conditions that depended on macros that previous versions had not seen #define'd. Implementers of other buildsystems are advised to pass the --compiler-flavor=msvc option to moc. Change-Id: I7e06274214d1939b0124e5b4bf169cceaef9ca46 Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
2016-04-14 00:25:37 +00:00
endif()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
endmacro()
Install CMake config files from Qt. This includes a BSD licenced file Qt5CoreMacros.cmake which is adapted from Qt4Macros.cmake in the CMake source tree. Change-Id: I54326b808795535490a0489659b351a8da72cdbb Reviewed-by: Clinton Stimpson <clinton@elemtech.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
2011-11-01 13:59:23 +00:00
# helper macro to set up a moc rule
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
function(_qt_internal_create_moc_command infile outfile moc_flags moc_options
moc_target moc_depends out_json_file)
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
# Pass the parameters in a file. Set the working directory to
# be that containing the parameters file and reference it by
# just the file name. This is necessary because the moc tool on
# MinGW builds does not seem to handle spaces in the path to the
# file given with the @ syntax.
get_filename_component(_moc_outfile_name "${outfile}" NAME)
get_filename_component(_moc_outfile_dir "${outfile}" PATH)
if(_moc_outfile_dir)
set(_moc_working_dir WORKING_DIRECTORY ${_moc_outfile_dir})
endif()
set (_moc_parameters_file ${outfile}_parameters)
set (_moc_parameters ${moc_flags} ${moc_options} -o "${outfile}" "${infile}")
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
if(out_json_file)
list(APPEND _moc_parameters --output-json)
set(extra_output_files "${outfile}.json")
set(${out_json_file} "${extra_output_files}" PARENT_SCOPE)
endif()
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
string (REPLACE ";" "\n" _moc_parameters "${_moc_parameters}")
if(moc_target)
CMake: Generate config-specific moc parameters file. When using the visual studio generators, a moc parameters file for each configuration is generated. The content differs because the -DQT_NO_DEBUG may be added or not, depending on the configuration. Change-Id: I52eae536289d451df72df2e4dba709851279694a Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-12-13 14:17:03 +00:00
set(_moc_parameters_file ${_moc_parameters_file}$<$<BOOL:$<CONFIGURATION>>:_$<CONFIGURATION>>)
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
set(targetincludes "$<TARGET_PROPERTY:${moc_target},INCLUDE_DIRECTORIES>")
set(targetdefines "$<TARGET_PROPERTY:${moc_target},COMPILE_DEFINITIONS>")
cmake: moc - remove duplicate includes/defines the generated `-D` and `-I` flags contain quite a number of duplicate entries. since cmake-3.15 it is easy to strip them via a generator expression Change-Id: I83915c9074e0e2e62e79cd932cad2fa07e8a12aa Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-27 14:45:20 +00:00
set(targetincludes "$<$<BOOL:${targetincludes}>:-I$<JOIN:$<REMOVE_DUPLICATES:${targetincludes}>,\n-I>\n>")
set(targetdefines "$<$<BOOL:${targetdefines}>:-D$<JOIN:$<REMOVE_DUPLICATES:${targetdefines}>,\n-D>\n>")
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
file (GENERATE
OUTPUT ${_moc_parameters_file}
CONTENT "${targetdefines}${targetincludes}${_moc_parameters}\n"
)
set(targetincludes)
set(targetdefines)
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
else()
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
file(WRITE ${_moc_parameters_file} "${_moc_parameters}\n")
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
endif()
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
set(_moc_extra_parameters_file @${_moc_parameters_file})
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
add_custom_command(OUTPUT ${outfile} ${extra_output_files}
cmake: Create Qt5 compat targets in config files For now create targets a la "Qt5::Core" to stay compatible with the current Qt5 naming scheme. The name is controllable via a CMake option. Change-Id: If43c058221949b1900c2093f39ccc9d0f38028f1 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-02-12 09:02:15 +00:00
COMMAND ${QT_CMAKE_EXPORT_NAMESPACE}::moc ${_moc_extra_parameters_file}
Add DEPENDS option to qt5_wrap_cpp() Currently the moc rule does not support dependency scanning, so after successful moc file generation it will ignore implicit dependencies in the header file. Although this works in most typical scenarios, at least in one case incremental builds become broken: when using Q_PLUGIN_METADATA() with the FILE argument. If FILE refers to a JSON file and latter was updated, then the expected behavior is to regenerate the moc file. Since CMake add_custom_command() does not support late dependency setup, all dependencies should be explicitly listed in a DEPENDS section. This patch adds the DEPENDS multiarg option to qt5_wrap_cpp(), allowing to specify additional dependencies to the moc rule. Task-number: QTBUG-44009 Change-Id: I2052ce23d3cb0c87c6bd99fcb7e8a71a7be9a330 Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com> Reviewed-by: Daniel Levin <dendy.ua@gmail.com>
2015-01-19 06:18:39 +00:00
DEPENDS ${infile} ${moc_depends}
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
${_moc_working_dir}
VERBATIM)
CMake: Set SKIP_AUTOMOC/AUTOUIC where needed Make sure we don't run into warnings for CMake 3.10 Task-number: QTBUG-63442 Change-Id: Ida004705646f0c32fb4bf6006036d80b1f279fd7 Reviewed-by: David Faure <david.faure@kdab.com> Reviewed-by: Sebastian Holtermann <sebholt@xwmw.org> Reviewed-by: Rolf Eike Beer <eb@emlix.com>
2017-09-29 20:17:10 +00:00
set_source_files_properties(${infile} PROPERTIES SKIP_AUTOMOC ON)
set_source_files_properties(${outfile} PROPERTIES SKIP_AUTOMOC ON)
set_source_files_properties(${outfile} PROPERTIES SKIP_AUTOUIC ON)
Qt5CoreMacros: Sync with CMake project counterpart Port of CMake commits: commit 2622bc3f65162bf6d6cb5838da6999f8b5ca75cf Author: Rolf Eike Beer <eike@sf-mail.de> Date: Sun Apr 6 21:30:00 2014 +0200 Clean up usage of if(... MATCHES regex) followed string(REGEX REPLACE regex) commit 7beba98652212c7a44f291b51dd03681e5193c49 Author: Robert Maynard <robert.maynard@kitware.com> Date: Thu Apr 3 11:27:58 2014 -0400 Qt4Macros: Make QT4_CREATE_MOC_COMMAND a function Change-Id: I5b928d114adb393ed9370163609311b7486e4a36 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
2015-12-21 16:56:55 +00:00
endfunction()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
Fix casing of public API functions Use lower case for the function name as that's cmake style. Change-Id: I6c53166aa3a8cece4abe8a485e06bd359fc12a06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-19 06:45:21 +00:00
function(qt6_generate_moc infile outfile )
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
# get include dirs and flags
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
_qt_internal_get_moc_flags(moc_flags)
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
get_filename_component(abs_infile ${infile} ABSOLUTE)
set(_outfile "${outfile}")
if(NOT IS_ABSOLUTE "${outfile}")
set(_outfile "${CMAKE_CURRENT_BINARY_DIR}/${outfile}")
endif()
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
if ("x${ARGV2}" STREQUAL "xTARGET")
set(moc_target ${ARGV3})
endif()
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
_qt_internal_create_moc_command(${abs_infile} ${_outfile} "${moc_flags}" "" "${moc_target}"
"" # moc_depends
"" # out_json_file
)
Convert macros to functions. Change-Id: I43f4188d1c33cd5a07eb7a12bf3343af7e6a211f Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:30:50 +00:00
endfunction()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_generate_moc)
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(QT_DEFAULT_MAJOR_VERSION EQUAL 5)
qt5_generate_moc(${ARGV})
elseif(QT_DEFAULT_MAJOR_VERSION EQUAL 6)
qt6_generate_moc(${ARGV})
endif()
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
Update public CMake macros' version Update all public Qt macros to use qt6/QT6 instead of qt5/QT6. Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-23 09:39:30 +00:00
# qt6_wrap_cpp(outfiles inputfile ... )
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
Fix casing of public API functions Use lower case for the function name as that's cmake style. Change-Id: I6c53166aa3a8cece4abe8a485e06bd359fc12a06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-19 06:45:21 +00:00
function(qt6_wrap_cpp outfiles )
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
# get include dirs
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
_qt_internal_get_moc_flags(moc_flags)
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
set(options)
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
set(oneValueArgs
TARGET
__QT_INTERNAL_OUTPUT_MOC_JSON_FILES
)
Add DEPENDS option to qt5_wrap_cpp() Currently the moc rule does not support dependency scanning, so after successful moc file generation it will ignore implicit dependencies in the header file. Although this works in most typical scenarios, at least in one case incremental builds become broken: when using Q_PLUGIN_METADATA() with the FILE argument. If FILE refers to a JSON file and latter was updated, then the expected behavior is to regenerate the moc file. Since CMake add_custom_command() does not support late dependency setup, all dependencies should be explicitly listed in a DEPENDS section. This patch adds the DEPENDS multiarg option to qt5_wrap_cpp(), allowing to specify additional dependencies to the moc rule. Task-number: QTBUG-44009 Change-Id: I2052ce23d3cb0c87c6bd99fcb7e8a71a7be9a330 Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com> Reviewed-by: Daniel Levin <dendy.ua@gmail.com>
2015-01-19 06:18:39 +00:00
set(multiValueArgs OPTIONS DEPENDS)
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
cmake_parse_arguments(_WRAP_CPP "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
set(moc_files ${_WRAP_CPP_UNPARSED_ARGUMENTS})
set(moc_options ${_WRAP_CPP_OPTIONS})
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
set(moc_target ${_WRAP_CPP_TARGET})
Add DEPENDS option to qt5_wrap_cpp() Currently the moc rule does not support dependency scanning, so after successful moc file generation it will ignore implicit dependencies in the header file. Although this works in most typical scenarios, at least in one case incremental builds become broken: when using Q_PLUGIN_METADATA() with the FILE argument. If FILE refers to a JSON file and latter was updated, then the expected behavior is to regenerate the moc file. Since CMake add_custom_command() does not support late dependency setup, all dependencies should be explicitly listed in a DEPENDS section. This patch adds the DEPENDS multiarg option to qt5_wrap_cpp(), allowing to specify additional dependencies to the moc rule. Task-number: QTBUG-44009 Change-Id: I2052ce23d3cb0c87c6bd99fcb7e8a71a7be9a330 Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com> Reviewed-by: Daniel Levin <dendy.ua@gmail.com>
2015-01-19 06:18:39 +00:00
set(moc_depends ${_WRAP_CPP_DEPENDS})
CMake: Allow specifying a TARGET in invocations of macros. Forward-port of 9ce60ff509c4ff27fe861fc5b2080f50897a68c4 (Qt4Macros: Allow specifying a TARGET in invokations of macros., 2013-02-26) from cmake.git. This causes the INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS to be used from the specified target when running moc. Change-Id: I868a35ade3c6b059e64d226291cf2046709d86d4 Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2013-06-19 15:56:04 +00:00
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
set(metatypes_json_list "")
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
foreach(it ${moc_files})
get_filename_component(it ${it} ABSOLUTE)
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
_qt_internal_make_output_file(${it} moc_ cpp outfile)
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
set(out_json_file_var "")
if(_WRAP_CPP___QT_INTERNAL_OUTPUT_MOC_JSON_FILES)
set(out_json_file_var "out_json_file")
endif()
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
_qt_internal_create_moc_command(
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
${it} ${outfile} "${moc_flags}" "${moc_options}" "${moc_target}" "${moc_depends}"
"${out_json_file_var}")
Port to list(APPEND) Change-Id: I198622270324eea62dd5ad6343fdf7c89e736e6c Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:27:48 +00:00
list(APPEND ${outfiles} ${outfile})
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
if(_WRAP_CPP___QT_INTERNAL_OUTPUT_MOC_JSON_FILES)
list(APPEND metatypes_json_list "${${out_json_file_var}}")
endif()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
endforeach()
Convert macros to functions. Change-Id: I43f4188d1c33cd5a07eb7a12bf3343af7e6a211f Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:30:50 +00:00
set(${outfiles} ${${outfiles}} PARENT_SCOPE)
CMake: Add option in qt6_wrap_cpp to output a metatypes json file At the moment only the Qt internal qt_manual_moc function allows manually running moc and generating a metatypes json file. There is no such functionality available in the public qt6_wrap_cpp and qt6_generate_moc functions. Change qt6_wrap_cpp to accept a new internal option called __QT_INTERNAL_OUTPUT_MOC_JSON_FILES to allow creating and retrieving the associated json file with metatypes information. This is needed to fix qtremoteobjects CMake API which needs to run moc manually and process the metatypes json file. The option is internal because we don't want to introduce new API in 6.2.0. Task-number: QTBUG-95832 Change-Id: Ic8dd27fc960c3f8dea8c101dfc028db45494953d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io> (cherry picked from commit 90e7d6db1bb44de3629ec2b70df26fbafe4294fa) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-09-17 13:03:55 +00:00
if(metatypes_json_list)
set(${_WRAP_CPP___QT_INTERNAL_OUTPUT_MOC_JSON_FILES}
"${metatypes_json_list}" PARENT_SCOPE)
endif()
Convert macros to functions. Change-Id: I43f4188d1c33cd5a07eb7a12bf3343af7e6a211f Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:30:50 +00:00
endfunction()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
# This will override the CMake upstream command, because that one is for Qt 3.
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_wrap_cpp outfiles)
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(QT_DEFAULT_MAJOR_VERSION EQUAL 5)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
qt5_wrap_cpp("${outfiles}" ${ARGN})
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
elseif(QT_DEFAULT_MAJOR_VERSION EQUAL 6)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
qt6_wrap_cpp("${outfiles}" ${ARGN})
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
set("${outfiles}" "${${outfiles}}" PARENT_SCOPE)
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
Update public CMake macros' version Update all public Qt macros to use qt6/QT6 instead of qt5/QT6. Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-23 09:39:30 +00:00
# _qt6_parse_qrc_file(infile _out_depends _rc_depends)
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
# internal
Fix casing of public API functions Use lower case for the function name as that's cmake style. Change-Id: I6c53166aa3a8cece4abe8a485e06bd359fc12a06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-19 06:45:21 +00:00
function(_qt6_parse_qrc_file infile _out_depends _rc_depends)
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
get_filename_component(rc_path ${infile} PATH)
if(EXISTS "${infile}")
# parse file for dependencies
# all files are absolute paths or relative to the location of the qrc file
file(READ "${infile}" RC_FILE_CONTENTS)
string(REGEX MATCHALL "<file[^<]+" RC_FILES "${RC_FILE_CONTENTS}")
foreach(RC_FILE ${RC_FILES})
string(REGEX REPLACE "^<file[^>]*>" "" RC_FILE "${RC_FILE}")
if(NOT IS_ABSOLUTE "${RC_FILE}")
set(RC_FILE "${rc_path}/${RC_FILE}")
endif()
set(RC_DEPENDS ${RC_DEPENDS} "${RC_FILE}")
endforeach()
# Since this cmake macro is doing the dependency scanning for these files,
# let's make a configured file and add it as a dependency so cmake is run
# again when dependencies need to be recomputed.
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
_qt_internal_make_output_file("${infile}" "" "qrc.depends" out_depends)
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
configure_file("${infile}" "${out_depends}" COPYONLY)
else()
# The .qrc file does not exist (yet). Let's add a dependency and hope
# that it will be generated later
set(out_depends)
endif()
set(${_out_depends} ${out_depends} PARENT_SCOPE)
set(${_rc_depends} ${RC_DEPENDS} PARENT_SCOPE)
endfunction()
Update public CMake macros' version Update all public Qt macros to use qt6/QT6 instead of qt5/QT6. Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-23 09:39:30 +00:00
# qt6_add_binary_resources(target inputfiles ... )
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
Fix casing of public API functions Use lower case for the function name as that's cmake style. Change-Id: I6c53166aa3a8cece4abe8a485e06bd359fc12a06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-19 06:45:21 +00:00
function(qt6_add_binary_resources target )
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
set(options)
set(oneValueArgs DESTINATION)
set(multiValueArgs OPTIONS)
cmake_parse_arguments(_RCC "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
set(rcc_files ${_RCC_UNPARSED_ARGUMENTS})
set(rcc_options ${_RCC_OPTIONS})
set(rcc_destination ${_RCC_DESTINATION})
Add the missing --no-zstd option to the manual rcc calls Add the missing --no-zstd argument when generating resource artifacts using binary or big resources or an existing .qrc file. Task-number: QTBUG-101353 Change-Id: If930f0cb7ba3c89b21b01552aefd6c0e33fe5cb3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-01 11:28:26 +00:00
if(NOT QT_FEATURE_zstd)
list(APPEND rcc_options "--no-zstd")
endif()
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
if(NOT rcc_destination)
set(rcc_destination ${CMAKE_CURRENT_BINARY_DIR}/${target}.rcc)
endif()
foreach(it ${rcc_files})
get_filename_component(infile ${it} ABSOLUTE)
Fix casing of public API functions Use lower case for the function name as that's cmake style. Change-Id: I6c53166aa3a8cece4abe8a485e06bd359fc12a06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-19 06:45:21 +00:00
_qt6_parse_qrc_file(${infile} _out_depends _rc_depends)
CMake: Set SKIP_AUTOMOC/AUTOUIC where needed Make sure we don't run into warnings for CMake 3.10 Task-number: QTBUG-63442 Change-Id: Ida004705646f0c32fb4bf6006036d80b1f279fd7 Reviewed-by: David Faure <david.faure@kdab.com> Reviewed-by: Sebastian Holtermann <sebholt@xwmw.org> Reviewed-by: Rolf Eike Beer <eb@emlix.com>
2017-09-29 20:17:10 +00:00
set_source_files_properties(${infile} PROPERTIES SKIP_AUTORCC ON)
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
set(infiles ${infiles} ${infile})
set(out_depends ${out_depends} ${_out_depends})
set(rc_depends ${rc_depends} ${_rc_depends})
endforeach()
add_custom_command(OUTPUT ${rcc_destination}
Update add_custom_command and add_custom_target dependencies If we don't add the executable used by the custom_target and/or custom_command to list of the command's/target's dependencies (DEPENDS) the generated file will not update should the executable change. Change-Id: Idce30f3dd4f756d9e8f6848c5e16f5dd6c7c8f0a Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-01-31 13:44:52 +00:00
DEPENDS ${QT_CMAKE_EXPORT_NAMESPACE}::rcc
cmake: Create Qt5 compat targets in config files For now create targets a la "Qt5::Core" to stay compatible with the current Qt5 naming scheme. The name is controllable via a CMake option. Change-Id: If43c058221949b1900c2093f39ccc9d0f38028f1 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-02-12 09:02:15 +00:00
COMMAND ${QT_CMAKE_EXPORT_NAMESPACE}::rcc
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
ARGS ${rcc_options} --binary --name ${target} --output ${rcc_destination} ${infiles}
Update add_custom_command and add_custom_target dependencies If we don't add the executable used by the custom_target and/or custom_command to list of the command's/target's dependencies (DEPENDS) the generated file will not update should the executable change. Change-Id: Idce30f3dd4f756d9e8f6848c5e16f5dd6c7c8f0a Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-01-31 13:44:52 +00:00
DEPENDS
${QT_CMAKE_EXPORT_NAMESPACE}::rcc
${rc_depends}
${out_depends}
${infiles}
VERBATIM)
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
add_custom_target(${target} ALL DEPENDS ${rcc_destination})
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_add_binary_resources)
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(QT_DEFAULT_MAJOR_VERSION EQUAL 5)
qt5_add_binary_resources(${ARGV})
elseif(QT_DEFAULT_MAJOR_VERSION EQUAL 6)
qt6_add_binary_resources(${ARGV})
endif()
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
Update public CMake macros' version Update all public Qt macros to use qt6/QT6 instead of qt5/QT6. Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-23 09:39:30 +00:00
# qt6_add_resources(target resourcename ...
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
# or
Update public CMake macros' version Update all public Qt macros to use qt6/QT6 instead of qt5/QT6. Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-23 09:39:30 +00:00
# qt6_add_resources(outfiles inputfile ... )
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
Fix casing of public API functions Use lower case for the function name as that's cmake style. Change-Id: I6c53166aa3a8cece4abe8a485e06bd359fc12a06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-19 06:45:21 +00:00
function(qt6_add_resources outfiles )
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
if (TARGET ${outfiles})
Fix OUTPUT_TARGET propagation in qt6_add_resource() Value was not being propagated to the parent scope when set. This patch also changes OUTPUT_TARGET to OUTPUT_TARGETS since it is possible that two targets can be generated. Change-Id: If489a609ed363a319224fcd6c5a4fc878d0d8617 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-16 07:49:40 +00:00
cmake_parse_arguments(arg "" "OUTPUT_TARGETS" "" ${ARGN})
CMake: Clean up the public API a bit Add some missing versionless functions. Rename some functions that are not meant to be public API, and their usages. Task-number: QTBUG-86827 Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-01 08:58:02 +00:00
_qt_internal_process_resource(${ARGV})
Fix OUTPUT_TARGET propagation in qt6_add_resource() Value was not being propagated to the parent scope when set. This patch also changes OUTPUT_TARGET to OUTPUT_TARGETS since it is possible that two targets can be generated. Change-Id: If489a609ed363a319224fcd6c5a4fc878d0d8617 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-16 07:49:40 +00:00
if (arg_OUTPUT_TARGETS)
set(${arg_OUTPUT_TARGETS} ${${arg_OUTPUT_TARGETS}} PARENT_SCOPE)
endif()
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
else()
set(options)
set(oneValueArgs)
set(multiValueArgs OPTIONS)
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
cmake_parse_arguments(_RCC "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
set(rcc_files ${_RCC_UNPARSED_ARGUMENTS})
set(rcc_options ${_RCC_OPTIONS})
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
if("${rcc_options}" MATCHES "-binary")
Update public CMake macros' version Update all public Qt macros to use qt6/QT6 instead of qt5/QT6. Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-23 09:39:30 +00:00
message(WARNING "Use qt6_add_binary_resources for binary option")
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
endif()
Fix style in cmake macros files. Change-Id: I2806ce63f5948dde9c582740bc2f070900987fb5 Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:17:02 +00:00
Add the missing --no-zstd option to the manual rcc calls Add the missing --no-zstd argument when generating resource artifacts using binary or big resources or an existing .qrc file. Task-number: QTBUG-101353 Change-Id: If930f0cb7ba3c89b21b01552aefd6c0e33fe5cb3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-01 11:28:26 +00:00
if(NOT QT_FEATURE_zstd)
list(APPEND rcc_options "--no-zstd")
endif()
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
foreach(it ${rcc_files})
get_filename_component(outfilename ${it} NAME_WE)
get_filename_component(infile ${it} ABSOLUTE)
set(outfile ${CMAKE_CURRENT_BINARY_DIR}/qrc_${outfilename}.cpp)
Fix casing of public API functions Use lower case for the function name as that's cmake style. Change-Id: I6c53166aa3a8cece4abe8a485e06bd359fc12a06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-19 06:45:21 +00:00
_qt6_parse_qrc_file(${infile} _out_depends _rc_depends)
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
set_source_files_properties(${infile} PROPERTIES SKIP_AUTORCC ON)
add_custom_command(OUTPUT ${outfile}
COMMAND ${QT_CMAKE_EXPORT_NAMESPACE}::rcc
ARGS ${rcc_options} --name ${outfilename} --output ${outfile} ${infile}
MAIN_DEPENDENCY ${infile}
Update add_custom_command and add_custom_target dependencies If we don't add the executable used by the custom_target and/or custom_command to list of the command's/target's dependencies (DEPENDS) the generated file will not update should the executable change. Change-Id: Idce30f3dd4f756d9e8f6848c5e16f5dd6c7c8f0a Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-01-31 13:44:52 +00:00
DEPENDS ${_rc_depends} "${_out_depends}" ${QT_CMAKE_EXPORT_NAMESPACE}::rcc
VERBATIM)
cmake: skip unity build inclusion of generated resources generated resource files contain static variables like `qt_resource_data`. if multiple resources are included in unity builds, we end up with name clashes, so we should exclude them Change-Id: I8cbe73a9e3ce3808a142b7cb6315355a7d4161db Pick-to: 6.2 6.3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-24 01:40:40 +00:00
set_source_files_properties(${outfile} PROPERTIES SKIP_AUTOMOC ON
SKIP_AUTOUIC ON
SKIP_UNITY_BUILD_INCLUSION ON
cmake: skip precompiled headers for generated resources resource compilation is typically not bound by parsing headers, so they don't benefit much from using precompiled headers. otoh, if we don't use precompiled headers for them, we may have better turnaround times, as these sources can be compiled in parallel with the pch compilation and they don't have to be rebuilt when a pch changes Change-Id: Ib4560ff31196e729f8efbcfb83cacfad127d90cd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-11 05:39:49 +00:00
SKIP_PRECOMPILE_HEADERS ON
cmake: skip unity build inclusion of generated resources generated resource files contain static variables like `qt_resource_data`. if multiple resources are included in unity builds, we end up with name clashes, so we should exclude them Change-Id: I8cbe73a9e3ce3808a142b7cb6315355a7d4161db Pick-to: 6.2 6.3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-24 01:40:40 +00:00
)
Extract add_qt_resource into reusable components This patch moves all of the underlying code for add_qt_resource into a common reusable snippet for both the Qt build and user projects. For users, the new API is available under QT5_ADD_RESOURCES. If outfiles is a CMAKE target we will use the new API, otherwise we will fall back to the old behavior. This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to add_qt_module so that module specific cmake files can be installed and loaded by the module's config.cmake. The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake and is injected into Qt{}Core_Config.cmake via the extra cmake includes passed into add_qt_module. To make sure it still works with QtBuild, we do the actual generation of the file from QtBaseGlobalTargets and include the generated file there as well. Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-19 14:19:08 +00:00
list(APPEND ${outfiles} ${outfile})
endforeach()
set(${outfiles} ${${outfiles}} PARENT_SCOPE)
CMake: Introduce qt5_add_binary_resources Optional parameter DESTINATION to set target rcc file Example: qt5_add_binary_resources(GenerateFixture "fixture.qrc") Task-number: QTBUG-41728 Change-Id: I9dc2fe8e7d5e9ad3873b89f75ab84a2a1b9d1d29 Reviewed-by: Stephen Kelly <steveire@gmail.com>
2014-11-13 10:01:31 +00:00
endif()
Convert macros to functions. Change-Id: I43f4188d1c33cd5a07eb7a12bf3343af7e6a211f Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2011-12-19 21:30:50 +00:00
endfunction()
Make the qt5_use_modules public API. This cmake function handles all of the necessary logic for using the include directories of Qt modules, linking to Qt modules, adding the required definitions, and most importantly, adding the position independent flags required on UNIX systems to use Qt by default. The function relies on functionality available in CMake 2.8.8, so it is only available if that version of CMake or greater is used. Change-Id: Ibe698e06819129479348c240844264c41553b5fb Reviewed-by: Alexander Neundorf <neundorf@kde.org> Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
2012-05-05 21:40:19 +00:00
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_add_resources outfiles)
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(QT_DEFAULT_MAJOR_VERSION EQUAL 5)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
qt5_add_resources("${outfiles}" ${ARGN})
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
elseif(QT_DEFAULT_MAJOR_VERSION EQUAL 6)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
qt6_add_resources("${outfiles}" ${ARGN})
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
Fix cases of output variables not being passed back to calling scope Some versionless wrappers were not passing back output variables to their calling scope. Ensure they always are. Fix qt6_extract_metatypes() to set its output variable in the parent scope (it was previously setting it erroneously in the local scope). Some functions had code paths that would not set output variables. This would allow situations where if the variables had an initial value set by a higher up parent scope, the output variable would still have that value in the caller's scope upon return. That could be misleading, so fix these code paths to explicitly set the output variable to an empty string instead. Task-number: QTBUG-96121 Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: I291775813f025cabdccd4372ac077cdfd3ec090e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-06 01:18:06 +00:00
if(TARGET ${outfiles})
cmake_parse_arguments(PARSE_ARGV 1 arg "" "OUTPUT_TARGETS" "")
if (arg_OUTPUT_TARGETS)
set(${arg_OUTPUT_TARGETS} ${${arg_OUTPUT_TARGETS}} PARENT_SCOPE)
endif()
else()
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
set("${outfiles}" "${${outfiles}}" PARENT_SCOPE)
endif()
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
Update public CMake macros' version Update all public Qt macros to use qt6/QT6 instead of qt5/QT6. Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-23 09:39:30 +00:00
# qt6_add_big_resources(outfiles inputfile ... )
Add support for big resources with CMake Task-number: QTBUG-55680 Change-Id: I09570a4e959ffd0e6d378bc315b13d57baaa82e8 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2018-05-18 10:19:38 +00:00
Fix casing of public API functions Use lower case for the function name as that's cmake style. Change-Id: I6c53166aa3a8cece4abe8a485e06bd359fc12a06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-19 06:45:21 +00:00
function(qt6_add_big_resources outfiles )
CMake: Warn when using qt6_add_big_resources on iOS qt6_add_big_resources works by calling rcc to generate a resource .cpp file, compiling it into an object file, then passing the compiled object file to rcc again for further manipulation. The path to the object file is passed to rcc using the $<TARGET_OBJECTS> generator expression. This generator expression does not work when used in add_custom_command / file(GENERATE) when targeting iOS, because CMake claims it does not know where the object file will be on-disk (presumably because the location is controlled by Xcode itself and it can vary based on the active architecture and sysroot). The following error is shown at generation time: Error evaluating generator expression: $<TARGET_OBJECTS:rcc_object_foo> The evaluation of the TARGET_OBJECTS generator expression is only suitable for consumption by CMake (limited under Xcode with multiple architectures). It is not suitable for writing out elsewhere. More details about the issue can be found at https://gitlab.kitware.com/cmake/cmake/-/issues/20516 Trying to work around the issue by manually invoking the compiler instead of using a genex so we know the location of the object file hits similar issues in that we don't know the active arch and sysroot for which to compile the object file. Until the CMake limitation is lifted or we find a different fix, warn that qt6_add_big_resources can't be used when targeting iOS and fall back to using qt6_add_resources instead. Note that qmake CONFIG+=big_resources also falls back to non-big resources mode when targeting Xcode (mac-xcode) and doesn't even show a warning. Another note is that using CMake + Xcode + qt6_add_big_resources does work when targeting macOS, although it generates some warnings warning same member name (qrc_assets.o) in output file used for input files: qrc_assets.o qrc_assets.o (due to use of basename, truncation, blank padding or duplicate input files) So there is some hope this could be fixed for iOS in the future. Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-103497 Change-Id: I91152247651ecd35e8110b8874399cb1b8b394bd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-06-20 09:36:04 +00:00
if(CMAKE_GENERATOR STREQUAL "Xcode" AND IOS)
message(WARNING
"Due to CMake limitations, qt6_add_big_resources can't be used when building for iOS. "
"See https://bugreports.qt.io/browse/QTBUG-103497 for details. "
"Falling back to using qt6_add_resources. "
"Consider using qt6_add_resources directly to silence this warning."
)
qt6_add_resources(${ARGV})
set(${outfiles} ${${outfiles}} PARENT_SCOPE)
return()
endif()
cmake: correct version dependency for qt5_add_big_resources qt5_add_big_resources is only available if using CMake 3.9 and later. This amends cdccd0222bbed1954d5d7fe0da9d2308c202f3b1. Task-number: QTBUG-55680 Task-number: QTBUG-75806 Change-Id: Ibba7af6ee7edfb226368937d543b7ec5cc93eb16 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2019-05-20 09:37:27 +00:00
if (CMAKE_VERSION VERSION_LESS 3.9)
Update public CMake macros' version Update all public Qt macros to use qt6/QT6 instead of qt5/QT6. Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-23 09:39:30 +00:00
message(FATAL_ERROR, "qt6_add_big_resources requires CMake 3.9 or newer")
cmake: correct version dependency for qt5_add_big_resources qt5_add_big_resources is only available if using CMake 3.9 and later. This amends cdccd0222bbed1954d5d7fe0da9d2308c202f3b1. Task-number: QTBUG-55680 Task-number: QTBUG-75806 Change-Id: Ibba7af6ee7edfb226368937d543b7ec5cc93eb16 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2019-05-20 09:37:27 +00:00
endif()
Add support for big resources with CMake Task-number: QTBUG-55680 Change-Id: I09570a4e959ffd0e6d378bc315b13d57baaa82e8 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2018-05-18 10:19:38 +00:00
set(options)
set(oneValueArgs)
set(multiValueArgs OPTIONS)
cmake_parse_arguments(_RCC "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
set(rcc_files ${_RCC_UNPARSED_ARGUMENTS})
set(rcc_options ${_RCC_OPTIONS})
if("${rcc_options}" MATCHES "-binary")
Update public CMake macros' version Update all public Qt macros to use qt6/QT6 instead of qt5/QT6. Change-Id: Ib178f4fa21f37dfb8da7d4d8c097aa0e96c9d9f9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-08-23 09:39:30 +00:00
message(WARNING "Use qt6_add_binary_resources for binary option")
Add support for big resources with CMake Task-number: QTBUG-55680 Change-Id: I09570a4e959ffd0e6d378bc315b13d57baaa82e8 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2018-05-18 10:19:38 +00:00
endif()
Add the missing --no-zstd option to the manual rcc calls Add the missing --no-zstd argument when generating resource artifacts using binary or big resources or an existing .qrc file. Task-number: QTBUG-101353 Change-Id: If930f0cb7ba3c89b21b01552aefd6c0e33fe5cb3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-01 11:28:26 +00:00
if(NOT QT_FEATURE_zstd)
list(APPEND rcc_options "--no-zstd")
endif()
Add support for big resources with CMake Task-number: QTBUG-55680 Change-Id: I09570a4e959ffd0e6d378bc315b13d57baaa82e8 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2018-05-18 10:19:38 +00:00
foreach(it ${rcc_files})
get_filename_component(outfilename ${it} NAME_WE)
Support multiple equally named .qrc files in qt_add_big_resources It is now possible to call qt_add_big_resources with multiple .qrc files that are in different directories but have the same file name. Before, this resulted in target name conflict errors. Pick-to: 6.1 Fixes: QTBUG-93230 Change-Id: Ic3d9d6974a107163aeb7ada0b6f1fa113fb18de0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-20 16:15:49 +00:00
# Provide unique targets and output file names
# in case we add multiple .qrc files with the same base name.
string(MAKE_C_IDENTIFIER "_qt_big_resource_count_${outfilename}" prop)
get_property(count GLOBAL PROPERTY ${prop})
if(count)
string(APPEND outfilename "_${count}")
else()
set(count 0)
endif()
math(EXPR count "${count} + 1")
set_property(GLOBAL PROPERTY ${prop} ${count})
Add support for big resources with CMake Task-number: QTBUG-55680 Change-Id: I09570a4e959ffd0e6d378bc315b13d57baaa82e8 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2018-05-18 10:19:38 +00:00
get_filename_component(infile ${it} ABSOLUTE)
set(tmpoutfile ${CMAKE_CURRENT_BINARY_DIR}/qrc_${outfilename}tmp.cpp)
set(outfile ${CMAKE_CURRENT_BINARY_DIR}/qrc_${outfilename}.o)
Fix casing of public API functions Use lower case for the function name as that's cmake style. Change-Id: I6c53166aa3a8cece4abe8a485e06bd359fc12a06 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-19 06:45:21 +00:00
_qt6_parse_qrc_file(${infile} _out_depends _rc_depends)
Fix qt6_add_big_resources The qt6_add_big_resources command was dysfunctional whenever AUTOMOC was enabled for a target. We passed multiple object files with the --temp argument of the second pass of rcc. We must pass exactly one. The spurious object file was the one that's created by AUTOMOC. Turn off all of AUTOGEN for the C++ source file that's generated in the first pass of rcc. Enable AUTOMOC for tests/auto/cmake/test_add_big_resource to cover this situation. Pick-to: 6.1 Fixes: QTBUG-85051 Change-Id: I6d2ce4953297db0751913456db0a4a126fe33f14 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-20 11:22:28 +00:00
set_source_files_properties(${infile} PROPERTIES SKIP_AUTOGEN ON)
Add support for big resources with CMake Task-number: QTBUG-55680 Change-Id: I09570a4e959ffd0e6d378bc315b13d57baaa82e8 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2018-05-18 10:19:38 +00:00
add_custom_command(OUTPUT ${tmpoutfile}
cmake: Create Qt5 compat targets in config files For now create targets a la "Qt5::Core" to stay compatible with the current Qt5 naming scheme. The name is controllable via a CMake option. Change-Id: If43c058221949b1900c2093f39ccc9d0f38028f1 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-02-12 09:02:15 +00:00
COMMAND ${QT_CMAKE_EXPORT_NAMESPACE}::rcc ${rcc_options} --name ${outfilename} --pass 1 --output ${tmpoutfile} ${infile}
Update add_custom_command and add_custom_target dependencies If we don't add the executable used by the custom_target and/or custom_command to list of the command's/target's dependencies (DEPENDS) the generated file will not update should the executable change. Change-Id: Idce30f3dd4f756d9e8f6848c5e16f5dd6c7c8f0a Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-01-31 13:44:52 +00:00
DEPENDS ${infile} ${_rc_depends} "${out_depends}" ${QT_CMAKE_EXPORT_NAMESPACE}::rcc
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
COMMENT "Running rcc pass 1 for resource ${outfilename}"
Update add_custom_command and add_custom_target dependencies If we don't add the executable used by the custom_target and/or custom_command to list of the command's/target's dependencies (DEPENDS) the generated file will not update should the executable change. Change-Id: Idce30f3dd4f756d9e8f6848c5e16f5dd6c7c8f0a Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-01-31 13:44:52 +00:00
VERBATIM)
Add support for big resources with CMake Task-number: QTBUG-55680 Change-Id: I09570a4e959ffd0e6d378bc315b13d57baaa82e8 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2018-05-18 10:19:38 +00:00
add_custom_target(big_resources_${outfilename} ALL DEPENDS ${tmpoutfile})
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
_qt_internal_add_rcc_pass2(
RESOURCE_NAME ${outfilename}
RCC_OPTIONS ${rcc_options}
OBJECT_LIB rcc_object_${outfilename}
QRC_FILE ${infile}
PASS1_OUTPUT_FILE ${tmpoutfile}
OUT_OBJECT_FILE ${outfile}
)
Add support for big resources with CMake Task-number: QTBUG-55680 Change-Id: I09570a4e959ffd0e6d378bc315b13d57baaa82e8 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2018-05-18 10:19:38 +00:00
add_dependencies(rcc_object_${outfilename} big_resources_${outfilename})
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
list(APPEND ${outfiles} ${outfile})
Add support for big resources with CMake Task-number: QTBUG-55680 Change-Id: I09570a4e959ffd0e6d378bc315b13d57baaa82e8 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
2018-05-18 10:19:38 +00:00
endforeach()
set(${outfiles} ${${outfiles}} PARENT_SCOPE)
endfunction()
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
function(_qt_internal_add_rcc_pass2)
set(options)
set(oneValueArgs
RESOURCE_NAME
OBJECT_LIB
QRC_FILE
PASS1_OUTPUT_FILE
OUT_OBJECT_FILE
)
set(multiValueArgs
RCC_OPTIONS
)
cmake_parse_arguments(arg "${options}" "${oneValueArgs}" "${multiValueArgs}" ${ARGN})
add_library(${arg_OBJECT_LIB} OBJECT ${arg_PASS1_OUTPUT_FILE})
_qt_internal_set_up_static_runtime_library(${arg_OBJECT_LIB})
target_compile_definitions(${arg_OBJECT_LIB} PUBLIC
"$<TARGET_PROPERTY:Qt6::Core,INTERFACE_COMPILE_DEFINITIONS>")
set_target_properties(${arg_OBJECT_LIB} PROPERTIES
AUTOMOC OFF
AUTOUIC OFF)
# The modification of TARGET_OBJECTS needs the following change in cmake
# https://gitlab.kitware.com/cmake/cmake/commit/93c89bc75ceee599ba7c08b8fe1ac5104942054f
add_custom_command(
OUTPUT ${arg_OUT_OBJECT_FILE}
COMMAND ${QT_CMAKE_EXPORT_NAMESPACE}::rcc
${arg_RCC_OPTIONS} --name ${arg_RESOURCE_NAME} --pass 2
--temp $<TARGET_OBJECTS:${arg_OBJECT_LIB}>
--output ${arg_OUT_OBJECT_FILE} ${arg_QRC_FILE}
DEPENDS ${arg_OBJECT_LIB} $<TARGET_OBJECTS:${arg_OBJECT_LIB}>
${QT_CMAKE_EXPORT_NAMESPACE}::rcc
COMMENT "Running rcc pass 2 for resource ${arg_RESOURCE_NAME}"
VERBATIM)
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_add_big_resources outfiles)
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(QT_DEFAULT_MAJOR_VERSION EQUAL 5)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
qt5_add_big_resources(${outfiles} ${ARGN})
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
elseif(QT_DEFAULT_MAJOR_VERSION EQUAL 6)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
qt6_add_big_resources(${outfiles} ${ARGN})
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
set("${outfiles}" "${${outfiles}}" PARENT_SCOPE)
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
function(_qt_internal_apply_win_prefix_and_suffix target)
if(WIN32)
# Table of prefix / suffixes for MSVC libraries as qmake expects them to be created.
# static - Qt6EdidSupport.lib (platform support libraries / or static QtCore, etc)
# shared - Qt6Core.dll
# shared import library - Qt6Core.lib
# module aka Qt plugin - qwindows.dll
# module import library - qwindows.lib
#
# The CMake defaults are fine for us.
# Table of prefix / suffixes for MinGW libraries as qmake expects them to be created.
# static - libQt6EdidSupport.a (platform support libraries / or static QtCore, etc)
# shared - Qt6Core.dll
# shared import library - libQt6Core.a
# module aka Qt plugin - qwindows.dll
# module import library - libqwindows.a
#
# CMake for Windows-GNU platforms defaults the prefix to "lib".
# CMake for Windows-GNU platforms defaults the import suffix to ".dll.a".
# These CMake defaults are not ok for us.
# This should cover both MINGW with GCC and CLANG.
if(NOT MSVC)
set_property(TARGET "${target}" PROPERTY IMPORT_SUFFIX ".a")
get_target_property(target_type ${target} TYPE)
if(target_type STREQUAL "STATIC_LIBRARY")
set_property(TARGET "${target}" PROPERTY PREFIX "lib")
else()
set_property(TARGET "${target}" PROPERTY PREFIX "")
set_property(TARGET "${target}" PROPERTY IMPORT_PREFIX "lib")
endif()
endif()
endif()
endfunction()
Merge remote-tracking branch 'origin/dev' into merge-dev Change-Id: I31b761cfd5ea01373c60d02a5da8c33398d34739
2020-01-22 12:47:08 +00:00
set(_Qt6_COMPONENT_PATH "${CMAKE_CURRENT_LIST_DIR}/..")
CMake: Restore qt5_use_modules() function It appears that in the 5 years since we deprecated this function, people have not stopped using it. The removal of qt5_use_modules() caused lots of troubles in packages still using it when they were compiled against Qt 5.11.0. Instead, let's revive this function and keep it for the Qt5 life time. See discussion on qt-development mailing list: http://lists.qt-project.org/pipermail/development/2018-June/032837.html Change-Id: Ic263e3bb6706268cb9ea38a0711665f166a3aa9e Reviewed-by: David Faure <david.faure@kdab.com> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2018-06-14 12:50:39 +00:00
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
# This function is currently in Technical Preview.
# It's signature and behavior might change.
#
# Wrapper function that adds an executable with some Qt specific behavior.
CMake: Support deferred finalization for qt6_add_executable() Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-08 11:00:22 +00:00
# Some scenarios require steps to be deferred to the end of the current
# directory scope so that the caller has an opportunity to modify certain
# target properties.
CMake: Rename add_qt_gui_executable to qt_add_executable Also adjust pro2cmake to use the new qt_add_executable name instead of add_qt_gui_executable. No compatibility functions provided this time, so we'll need to follow through all repos and regenerate all examples. Two reasons for not providing compaitibility functions: 1) We don't intend add_qt_gui_executable to be public API 2) A previous case with qtquickcontrols2 and qttools pointed out that making top-level builds work with cross-compatibility API is not simple. So just go ahead and regenerate everything. Task-number: QTBUG-87661 Change-Id: I2f228827b786ae03bf7e1bf3908ea02a8794ed52 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-15 15:58:15 +00:00
function(qt6_add_executable target)
CMake: Support deferred finalization for qt6_add_executable() Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-08 11:00:22 +00:00
cmake_parse_arguments(PARSE_ARGV 1 arg "MANUAL_FINALIZATION" "" "")
_qt_internal_create_executable("${target}" ${arg_UNPARSED_ARGUMENTS})
Ensure _qt_is_android_executable is set for internal executables too The _qt_is_android_executable property is normally set by the _qt_internal_create_executable() command. But various other internal commands don't route through that and go through qt_internal_add_executable() instead. The former is used only by the public API, the latter only by the internal API. Refactor both so that the internal one calls the public one. This ensures all targets receive the same base settings, including the _qt_is_android_executable property. Fixes: QTBUG-96085 Pick-to: 6.2 Change-Id: I157356872c9d942d7be5f1abbbcbac97961b1f40 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-16 08:13:25 +00:00
target_link_libraries("${target}" PRIVATE Qt6::Core)
CMake: Support deferred finalization for qt6_add_executable() Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-08 11:00:22 +00:00
if(arg_MANUAL_FINALIZATION)
CMake: Replace qt_finalize_executable with qt_finalize_target It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-18 17:42:55 +00:00
# Caller says they will call qt6_finalize_target() themselves later
CMake: Support deferred finalization for qt6_add_executable() Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-08 11:00:22 +00:00
return()
endif()
# Defer the finalization if we can. When the caller's project requires
# CMake 3.19 or later, this makes the calls to this function concise while
# still allowing target property modification before finalization.
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.19)
# Need to wrap in an EVAL CODE or else ${target} won't be evaluated
# due to special behavior of cmake_language() argument handling
CMake: Replace qt_finalize_executable with qt_finalize_target It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-18 17:42:55 +00:00
cmake_language(EVAL CODE "cmake_language(DEFER CALL qt6_finalize_target ${target})")
CMake: Support deferred finalization for qt6_add_executable() Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-08 11:00:22 +00:00
else()
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
set_target_properties("${target}" PROPERTIES _qt_is_immediately_finalized TRUE)
CMake: Replace qt_finalize_executable with qt_finalize_target It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-18 17:42:55 +00:00
qt6_finalize_target("${target}")
CMake: Support deferred finalization for qt6_add_executable() Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-08 11:00:22 +00:00
endif()
endfunction()
function(_qt_internal_create_executable target)
Fix compiling of examples on Android * Simplify add_qt_gui_executable() to not require WIN32/MACOSX_BUNDLE but provide it implicitly. It's redundant :) * When on Android, build a module (shared library), just like qmake. This requires an additional library destination in the install() call, but that's ignored on other platforms. * Fix typos in the android deployment generation settings function * Use the correct cache variable to determine whether we're inside a Qt build or not. Right now this only works inside Qt builds anyway as QtPlatformAndroid.cmake is not publically accessible. Change-Id: If1c763c31a7a83d0e0d854362ba7901657f63eb5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-06-12 08:21:40 +00:00
if(ANDROID)
Replace ANDROID_ABI argument with the QT_ANDROID_ABI target property This change tries to make the API more user friendly and prevent wrong use of multi-abi API. ANDROID_ABI argument of qt6_add_executable was position-depend and needed to be placed after the executable 'sources'. Using the target property we solve this problem and provide more consistent and common way to enable multi-abi build for the single target. This meanwhile also requires to execute multi-abi build configuration in the finalizer, since the property might be set at any point. Also the priority of the QT_ANDROID_ABI target property now is higher than the priority of the QT_ANDROID_BUILD_ALL_ABIS variable. So target will only build packages with the ABIs specified in QT_ANDROID_ABI property if both are set. Pick-to: 6.3 Task-number: QTBUG-88841 Change-Id: I3515297ed267974498913c59619433dc234ec217 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-17 12:02:04 +00:00
list(REMOVE_ITEM ARGN "WIN32" "MACOSX_BUNDLE")
add_library("${target}" MODULE ${ARGN})
Clean up application module visibility on Android Disable ELF visibility using CMake properties on the shared object that's supposed to contain main(). Change-Id: I9cdbb2a76ad66cf2742280ddfea47908eaff2370 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-26 14:19:13 +00:00
# On our qmake builds we do don't compile the executables with
# visibility=hidden. Not having this flag set will cause the
# executable to have main() hidden and can then no longer be loaded
# through dlopen()
set_property(TARGET "${target}" PROPERTY C_VISIBILITY_PRESET default)
set_property(TARGET "${target}" PROPERTY CXX_VISIBILITY_PRESET default)
cmake: Apply symbol visibility settings to Objective-C/C++ sources Otherwise the Objective-C++ sources will be built with the default compiler visibility (visible), and then linked with moc-generated C++ sources that have the Qt overridden hidden visibility, resulting in linker warnings such as: ld: warning: direct access in function 'X' from file 'moc_foo.cpp.o' to global weak symbol 'Y' from file 'bar.mm.o' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility setting Change-Id: I22e15e7e181a74de8c0a22c73d06e600e582d7fd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-06-24 16:19:15 +00:00
set_property(TARGET "${target}" PROPERTY OBJC_VISIBILITY_PRESET default)
set_property(TARGET "${target}" PROPERTY OBJCXX_VISIBILITY_PRESET default)
CMake: Use versionfull functions within our public API This ensures that the public functions still work even if QT_NO_CREATE_VERSIONLESS_FUNCTIONS is true. Task-number: QTBUG-86827 Change-Id: I5654eb17ffe47a1b8e9d397e0477f5b82a762ae1 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-26 12:47:49 +00:00
qt6_android_apply_arch_suffix("${target}")
CMake: Fix finalizers not being run for android executables Android executables are actually loadable modules, not executables. Instead of checking for the target type if it's a MODULE, be explicit and mark the target with a special qt property that we then use to decide whether the finalizer should run. Amends c4df673dd9034bc6dcd0871d27f13d8524ae829e Change-Id: I5330d80d39488cfda6ebe07e2a1883200a796be8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-25 14:34:16 +00:00
set_property(TARGET "${target}" PROPERTY _qt_is_android_executable TRUE)
Fix compiling of examples on Android * Simplify add_qt_gui_executable() to not require WIN32/MACOSX_BUNDLE but provide it implicitly. It's redundant :) * When on Android, build a module (shared library), just like qmake. This requires an additional library destination in the install() call, but that's ignored on other platforms. * Fix typos in the android deployment generation settings function * Use the correct cache variable to determine whether we're inside a Qt build or not. Right now this only works inside Qt builds anyway as QtPlatformAndroid.cmake is not publically accessible. Change-Id: If1c763c31a7a83d0e0d854362ba7901657f63eb5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-06-12 08:21:40 +00:00
else()
Replace ANDROID_ABI argument with the QT_ANDROID_ABI target property This change tries to make the API more user friendly and prevent wrong use of multi-abi API. ANDROID_ABI argument of qt6_add_executable was position-depend and needed to be placed after the executable 'sources'. Using the target property we solve this problem and provide more consistent and common way to enable multi-abi build for the single target. This meanwhile also requires to execute multi-abi build configuration in the finalizer, since the property might be set at any point. Also the priority of the QT_ANDROID_ABI target property now is higher than the priority of the QT_ANDROID_BUILD_ALL_ABIS variable. So target will only build packages with the ABIs specified in QT_ANDROID_ABI property if both are set. Pick-to: 6.3 Task-number: QTBUG-88841 Change-Id: I3515297ed267974498913c59619433dc234ec217 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-17 12:02:04 +00:00
add_executable("${target}" ${ARGN})
Fix compiling of examples on Android * Simplify add_qt_gui_executable() to not require WIN32/MACOSX_BUNDLE but provide it implicitly. It's redundant :) * When on Android, build a module (shared library), just like qmake. This requires an additional library destination in the install() call, but that's ignored on other platforms. * Fix typos in the android deployment generation settings function * Use the correct cache variable to determine whether we're inside a Qt build or not. Right now this only works inside Qt builds anyway as QtPlatformAndroid.cmake is not publically accessible. Change-Id: If1c763c31a7a83d0e0d854362ba7901657f63eb5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2019-06-12 08:21:40 +00:00
endif()
CMake: Support deferred finalization for qt6_add_executable() Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-08 11:00:22 +00:00
Use correct MSVC runtime library for targets created by qt_add_*() Use _qt_internal_set_up_static_runtime_library() to set correct MSVC runtime library for targets created by qt_add_executable(), qt_add_library(), qt_add_plugin() and qt_add_big_resources(), to bring convenience to user projects. Pick-to: 6.2 Change-Id: Ia49f1e90989c464820824be3e1eef3df1351cdcf Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-29 09:53:03 +00:00
_qt_internal_set_up_static_runtime_library("${target}")
CMake: Support deferred finalization for qt6_add_executable() Some parts of qt6_add_executable() need to take into account certain target properties, but the target is created within the function. The caller doesn't get the opportunity to modify those properties before they are used. This change provides a way to defer those property-using steps until either the project explicitly calls a function to finalize the target or the end of the current directory scope is reached. Automatic deferral to end of scope is only supported for CMake 3.19+. With CMake 3.18 or earlier, deferring the finalization step has to be explicitly requested with the new MANUAL_FINALIZATION keyword. The caller is then responsible for also calling qt6_finalize_executable() later. When the keyword is given, automatic finalization is disabled even when using CMake 3.19+. Note that while this could be implemented without CMake 3.19 features, other work relating to qt6_import_qml_plugins() will require it so we may as well use this method now. Fixes: QTBUG-88840 Task-number: QTBUG-86669 Pick-to: 6.0 Change-Id: Ic3854672ba18cff5af2ffd7f63596aa3ac492f33 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-12-08 11:00:22 +00:00
endfunction()
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
CMake: Replace qt_finalize_executable with qt_finalize_target It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-18 17:42:55 +00:00
function(_qt_internal_finalize_executable target)
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
get_target_property(is_finalized "${target}" _qt_executable_is_finalized)
if(is_finalized)
message(AUTHOR_WARNING
CMake: Replace qt_finalize_executable with qt_finalize_target It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-18 17:42:55 +00:00
"Tried to call qt6_finalize_target twice on executable: '${target}'. \
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
Did you forget to specify MANUAL_FINALIZATION to qt6_add_executable?")
return()
endif()
qt6_finalize_executable(): Enable finalizers to be set per-target Some plugins need to append additional processing to targets that use them. This is most commonly needed for static builds to identify additional plugins that need to be linked, but which cannot be determined automatically by CMake as part of its transitive dependency handling. Check for finalizers on directly linked targets as a way to help automate common scenarios. Because we need to lookup dependency targets and these may have visibility limited to the depender target's scope, we now formally document that finalizers should be called from the same scope as the one in which the target was created. This was loosely expected before, but is now made explicit. Task-number: QTBUG-90819 Task-number: QTBUG-86669 Pick-to: 6.1 Change-Id: I065a3f3a4ab6eeff6a98a655835427949e2fe0f1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-02-15 07:59:08 +00:00
# We can't evaluate generator expressions at configure time, so we can't
# ask for any transitive properties or even the full library dependency
CMake: Walk link dependencies recursively to work out finalizers When versionless targets are used, they are defined as INTERFACE IMPORTED targets. These will sit between the executable target created by qt6_add_executable() and the underlying Qt6::XXX module library where the finalizers are defined. We need to recurse through the link dependencies to ensure we pick up these finalizers. This will also ensure we pick up finalizers in deeper targets from transitive dependencies. Fixes: QTBUG-93387 Change-Id: If8524ebf0e75c8790858dd7e42aa1cf4ebdfd989 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-04 07:09:47 +00:00
# chain.
# We can still look at the immediate dependencies
# (and recursively their dependencies) and query
qt6_finalize_executable(): Enable finalizers to be set per-target Some plugins need to append additional processing to targets that use them. This is most commonly needed for static builds to identify additional plugins that need to be linked, but which cannot be determined automatically by CMake as part of its transitive dependency handling. Check for finalizers on directly linked targets as a way to help automate common scenarios. Because we need to lookup dependency targets and these may have visibility limited to the depender target's scope, we now formally document that finalizers should be called from the same scope as the one in which the target was created. This was loosely expected before, but is now made explicit. Task-number: QTBUG-90819 Task-number: QTBUG-86669 Pick-to: 6.1 Change-Id: I065a3f3a4ab6eeff6a98a655835427949e2fe0f1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-02-15 07:59:08 +00:00
# any that are not expressed as generator expressions. For any we can
# identify as a CMake target known to the current scope, we can check if
# that target has a finalizer to be called. This is expected to cover the
# vast majority of use cases, since projects will typically link directly
# to Qt::* targets. For the cases where this isn't so, the project will be
# responsible for calling any relevant functions themselves instead of
# relying on these automatic finalization calls.
set(finalizers)
CMake: Walk link dependencies recursively to work out finalizers When versionless targets are used, they are defined as INTERFACE IMPORTED targets. These will sit between the executable target created by qt6_add_executable() and the underlying Qt6::XXX module library where the finalizers are defined. We need to recurse through the link dependencies to ensure we pick up these finalizers. This will also ensure we pick up finalizers in deeper targets from transitive dependencies. Fixes: QTBUG-93387 Change-Id: If8524ebf0e75c8790858dd7e42aa1cf4ebdfd989 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-04 07:09:47 +00:00
__qt_internal_collect_all_target_dependencies("${target}" dep_targets)
if(dep_targets)
foreach(dep IN LISTS dep_targets)
qt6_finalize_executable(): Enable finalizers to be set per-target Some plugins need to append additional processing to targets that use them. This is most commonly needed for static builds to identify additional plugins that need to be linked, but which cannot be determined automatically by CMake as part of its transitive dependency handling. Check for finalizers on directly linked targets as a way to help automate common scenarios. Because we need to lookup dependency targets and these may have visibility limited to the depender target's scope, we now formally document that finalizers should be called from the same scope as the one in which the target was created. This was loosely expected before, but is now made explicit. Task-number: QTBUG-90819 Task-number: QTBUG-86669 Pick-to: 6.1 Change-Id: I065a3f3a4ab6eeff6a98a655835427949e2fe0f1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-02-15 07:59:08 +00:00
get_target_property(dep_finalizers ${dep}
INTERFACE_QT_EXECUTABLE_FINALIZERS
)
if(dep_finalizers)
list(APPEND finalizers ${dep_finalizers})
endif()
endforeach()
list(REMOVE_DUPLICATES finalizers)
endif()
CMake: Walk link dependencies recursively to work out finalizers When versionless targets are used, they are defined as INTERFACE IMPORTED targets. These will sit between the executable target created by qt6_add_executable() and the underlying Qt6::XXX module library where the finalizers are defined. We need to recurse through the link dependencies to ensure we pick up these finalizers. This will also ensure we pick up finalizers in deeper targets from transitive dependencies. Fixes: QTBUG-93387 Change-Id: If8524ebf0e75c8790858dd7e42aa1cf4ebdfd989 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-04 07:09:47 +00:00
qt6_finalize_executable(): Enable finalizers to be set per-target Some plugins need to append additional processing to targets that use them. This is most commonly needed for static builds to identify additional plugins that need to be linked, but which cannot be determined automatically by CMake as part of its transitive dependency handling. Check for finalizers on directly linked targets as a way to help automate common scenarios. Because we need to lookup dependency targets and these may have visibility limited to the depender target's scope, we now formally document that finalizers should be called from the same scope as the one in which the target was created. This was loosely expected before, but is now made explicit. Task-number: QTBUG-90819 Task-number: QTBUG-86669 Pick-to: 6.1 Change-Id: I065a3f3a4ab6eeff6a98a655835427949e2fe0f1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-02-15 07:59:08 +00:00
if(finalizers)
if(CMAKE_VERSION VERSION_LESS 3.18)
Fall back to include() method for finalizers with CMake 3.17 or earlier Functionality is being added in other repos which require finalizers to be run for non-static builds. That means we now need to ensure finalizers always run even with CMake versions before cmake_language() was added. The fallback method of writing to a file and including it is slower, but that's better than missing important functionality altogether. Task-number: QTBUG-98545 Pick-to: 6.2 Change-Id: Ic8668c91c26d0c30de084b1b803032088c10fcf4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-11-30 01:10:19 +00:00
# cmake_language() not available, fall back to the slower method of
# writing a file and including it
set(contents "")
foreach(finalizer_func IN LISTS finalizers)
string(APPEND contents "${finalizer_func}(${target})\n")
endforeach()
set(finalizer_file "${CMAKE_CURRENT_BINARY_DIR}/.qt/finalize_${target}.cmake")
file(WRITE ${finalizer_file} "${contents}")
include(${finalizer_file})
qt6_finalize_executable(): Enable finalizers to be set per-target Some plugins need to append additional processing to targets that use them. This is most commonly needed for static builds to identify additional plugins that need to be linked, but which cannot be determined automatically by CMake as part of its transitive dependency handling. Check for finalizers on directly linked targets as a way to help automate common scenarios. Because we need to lookup dependency targets and these may have visibility limited to the depender target's scope, we now formally document that finalizers should be called from the same scope as the one in which the target was created. This was loosely expected before, but is now made explicit. Task-number: QTBUG-90819 Task-number: QTBUG-86669 Pick-to: 6.1 Change-Id: I065a3f3a4ab6eeff6a98a655835427949e2fe0f1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-02-15 07:59:08 +00:00
else()
foreach(finalizer_func IN LISTS finalizers)
cmake_language(CALL ${finalizer_func} ${target})
endforeach()
endif()
endif()
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 08:29:41 +00:00
if(EMSCRIPTEN)
CMake: Make qt6_wasm_add_target_helpers an internal function This function is called by qt_add_executable. There is no need to expose it as public function. Fixes: QTBUG-95172 Change-Id: I85a1d906ecda42458e226db225e47c1d348a72f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-08-04 07:44:55 +00:00
_qt_internal_wasm_add_target_helpers("${target}")
wasm: add cmake build support A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-09-03 08:29:41 +00:00
endif()
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
if(IOS)
CMake: Rename qt6_finalize_ios_app to be internal For now, it's not meant to be called manually. It's called in qt_add_executable automatically for iOS. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 Task-number: QTBUG-88763 Change-Id: I90dfcf86f53a3c8e48a813435f7400db232b21f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-17 14:00:08 +00:00
_qt_internal_finalize_ios_app("${target}")
Add CMake deployment support Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-29 23:29:34 +00:00
elseif(APPLE)
_qt_internal_finalize_macos_app("${target}")
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endif()
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
# For finalizer mode of plugin importing to work safely, we need to know the list of Qt
# dependencies the target has, but those might be added later than the qt_add_executable call.
# Most of our examples are like that. Only enable finalizer mode when we are sure that the user
CMake: Revise plugin finalizer mode usage Only use plugin finalizer mode if qt_finalize_target is called at the end of the user project (which we can't really check, the user has to ensure that) or when qt_finalize_target is automatically defer-called by CMake 3.19+ (which is done by qt_add_executable). This removes the previous behavior of using the finalizer mode if qt_import_plugins is called. Instead the old regular mode is used if the above preconditions are not met. The removed behavior had ordering issues if qt_import_plugins was called before target_link_libraries. The dependency walking would be done before Qt dependencies were added and thus no plugins would be linked. Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Task-number: QTBUG-94030 Change-Id: I78702b653a35596f5581c2f4282b2336f0124e60 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-26 15:19:08 +00:00
# manually called qt_finalize_target at the end of their CMake project, or it was automatically
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 17:01:35 +00:00
# done via a deferred call. This is also applicable to the resource object finalizer.
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
get_target_property(is_immediately_finalized "${target}" _qt_is_immediately_finalized)
if(NOT is_immediately_finalized)
__qt_internal_apply_plugin_imports_finalizer_mode("${target}")
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
__qt_internal_process_dependency_object_libraries("${target}")
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
endif()
set_target_properties(${target} PROPERTIES _qt_executable_is_finalized TRUE)
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endfunction()
Allow finalizers to be delayed to later in the same directory scope Deferred CMake calls are executed in the order they are created. Sometimes, a deferred call created after a call to qt_add_executable() or qt_add_library() needs to be executed before target finalization. For example, a file may be written using a deferred write, but the finalizers might need that file to exist. Provide an internal _qt_internal_delay_finalization_until_after() command that can be called to let finalization know it has to defer to later. Target finalizers will check an internal property for IDs recorded by that command and will re-defer itself if it detects that any of those haven't run yet. Task-number: QTBUG-96290 Pick-to: 6.2 Change-Id: Ia791e99339bab351eff0d675a552393e524490e8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-13 05:54:00 +00:00
# If a task needs to run before any targets are finalized in the current directory
# scope, call this function and pass the ID of that task as the argument.
function(_qt_internal_delay_finalization_until_after defer_id)
set_property(DIRECTORY APPEND PROPERTY qt_internal_finalizers_wait_for_ids "${defer_id}")
endfunction()
CMake: Replace qt_finalize_executable with qt_finalize_target It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-18 17:42:55 +00:00
function(qt6_finalize_target target)
Allow finalizers to be delayed to later in the same directory scope Deferred CMake calls are executed in the order they are created. Sometimes, a deferred call created after a call to qt_add_executable() or qt_add_library() needs to be executed before target finalization. For example, a file may be written using a deferred write, but the finalizers might need that file to exist. Provide an internal _qt_internal_delay_finalization_until_after() command that can be called to let finalization know it has to defer to later. Target finalizers will check an internal property for IDs recorded by that command and will re-defer itself if it detects that any of those haven't run yet. Task-number: QTBUG-96290 Pick-to: 6.2 Change-Id: Ia791e99339bab351eff0d675a552393e524490e8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-13 05:54:00 +00:00
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.19")
cmake_language(DEFER GET_CALL_IDS ids_queued)
get_directory_property(wait_for_ids qt_internal_finalizers_wait_for_ids)
while(wait_for_ids)
list(GET wait_for_ids 0 id_to_wait_for)
if(id_to_wait_for IN_LIST ids_queued)
# Something else needs to run before we finalize targets.
# Try again later by re-deferring ourselves, which effectively
# puts us at the end of the current list of deferred actions.
cmake_language(EVAL CODE "cmake_language(DEFER CALL ${CMAKE_CURRENT_FUNCTION} ${ARGV})")
set_directory_properties(PROPERTIES
qt_internal_finalizers_wait_for_ids "${wait_for_ids}"
)
return()
endif()
list(POP_FRONT wait_for_ids)
endwhile()
# No other deferred tasks to wait for
set_directory_properties(PROPERTIES qt_internal_finalizers_wait_for_ids "")
endif()
CMake: Replace qt_finalize_executable with qt_finalize_target It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-18 17:42:55 +00:00
if(NOT TARGET "${target}")
message(FATAL_ERROR "No target '${target}' found in current scope.")
endif()
get_target_property(target_type ${target} TYPE)
CMake: Fix finalizers not being run for android executables Android executables are actually loadable modules, not executables. Instead of checking for the target type if it's a MODULE, be explicit and mark the target with a special qt property that we then use to decide whether the finalizer should run. Amends c4df673dd9034bc6dcd0871d27f13d8524ae829e Change-Id: I5330d80d39488cfda6ebe07e2a1883200a796be8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-25 14:34:16 +00:00
get_target_property(is_android_executable "${target}" _qt_is_android_executable)
if(target_type STREQUAL "EXECUTABLE" OR is_android_executable)
CMake: Replace qt_finalize_executable with qt_finalize_target It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-18 17:42:55 +00:00
_qt_internal_finalize_executable(${ARGV})
endif()
endfunction()
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
function(_qt_internal_handle_ios_launch_screen target)
# Check if user provided a launch screen path via a variable.
set(launch_screen "")
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
# Check if the project provided a launch screen path via a variable.
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
# This variable is currently in Technical Preview.
if(QT_IOS_LAUNCH_SCREEN)
set(launch_screen "${QT_IOS_LAUNCH_SCREEN}")
endif()
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
# Check if the project provided a launch screen path via a target property, it takes precedence
# over the variable.
# This property is currently in Technical Preview.
get_target_property(launch_screen_from_prop "${target}" QT_IOS_LAUNCH_SCREEN)
if(launch_screen_from_prop)
set(launch_screen "${launch_screen_from_prop}")
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
endif()
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
# If the project hasn't provided a launch screen file path, use a copy of the template
# that qmake uses.
# It needs to be a copy because configure_file can't handle all the escaped double quotes
# present in the qmake template file.
set(is_default_launch_screen FALSE)
if(NOT launch_screen AND NOT QT_NO_SET_DEFAULT_IOS_LAUNCH_SCREEN)
set(is_default_launch_screen TRUE)
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
set(launch_screen
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
"${__qt_internal_cmake_ios_support_files_path}/LaunchScreen.storyboard")
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
endif()
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
# Check that the launch screen exists.
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
if(launch_screen)
if(NOT IS_ABSOLUTE "${launch_screen}")
message(FATAL_ERROR
"Provided launch screen value should be an absolute path: '${launch_screen}'")
endif()
if(NOT EXISTS "${launch_screen}")
message(FATAL_ERROR
"Provided launch screen file does not exist: '${launch_screen}'")
endif()
endif()
if(launch_screen AND NOT QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE)
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
get_filename_component(launch_screen_name "${launch_screen}" NAME)
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
# Make a copy of the default launch screen template for this target and replace the
# label inside the template with the target name.
if(is_default_launch_screen)
# Configure our default template and place it in the build dir.
set(launch_screen_in_path "${launch_screen}")
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
string(MAKE_C_IDENTIFIER "${target}" target_identifier)
set(launch_screen_out_dir
"${CMAKE_CURRENT_BINARY_DIR}/.qt/launch_screen_storyboards/${target_identifier}")
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
set(launch_screen_out_path
"${launch_screen_out_dir}/${launch_screen_name}")
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
file(MAKE_DIRECTORY "${launch_screen_out_dir}")
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
# Replaces the value in the default template.
set(QT_IOS_LAUNCH_SCREEN_TEXT "${target}")
configure_file(
"${launch_screen_in_path}"
"${launch_screen_out_path}"
@ONLY
)
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
set(final_launch_screen_path "${launch_screen_out_path}")
else()
set(final_launch_screen_path "${launch_screen}")
endif()
# Add the launch screen storyboard file as a source file, otherwise CMake doesn't consider
# it as a resource file and MACOSX_PACKAGE_LOCATION processing will be skipped.
target_sources("${target}" PRIVATE "${final_launch_screen_path}")
# Ensure Xcode compiles the storyboard file and installs the compiled storyboard .nib files
# into the app bundle.
# We use target_sources and the MACOSX_PACKAGE_LOCATION source file property for that
# instead of the RESOURCE target property, becaues the latter could potentially end up
# needlessly installing the source storyboard file.
#
# We can't rely on policy CMP0118 since user project controls it.
set(scope_args)
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.18")
set(scope_args TARGET_DIRECTORY ${target})
endif()
set_source_files_properties("${final_launch_screen_path}" ${scope_args}
PROPERTIES MACOSX_PACKAGE_LOCATION Resources)
# Save the launch screen name, so its value is added as an UILaunchStoryboardName entry
# in the Qt generated Info.plist file.
set_target_properties("${target}" PROPERTIES
_qt_ios_launch_screen_name "${launch_screen_name}"
_qt_ios_launch_screen_path "${final_launch_screen_path}")
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
endif()
endfunction()
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
function(_qt_internal_find_ios_development_team_id out_var)
get_property(team_id GLOBAL PROPERTY _qt_internal_ios_development_team_id)
get_property(team_id_computed GLOBAL PROPERTY _qt_internal_ios_development_team_id_computed)
if(team_id_computed)
# Just in case if the value is non-empty but still booly FALSE.
if(NOT team_id)
set(team_id "")
endif()
set("${out_var}" "${team_id}" PARENT_SCOPE)
return()
endif()
set_property(GLOBAL PROPERTY _qt_internal_ios_development_team_id_computed "TRUE")
set(home_dir "$ENV{HOME}")
set(xcode_preferences_path "${home_dir}/Library/Preferences/com.apple.dt.Xcode.plist")
# Extract the first account name (email) from the user's Xcode preferences
message(DEBUG "Trying to extract an Xcode development team id from '${xcode_preferences_path}'")
execute_process(COMMAND "/usr/libexec/PlistBuddy"
-x -c "print IDEProvisioningTeams" "${xcode_preferences_path}"
OUTPUT_VARIABLE teams_xml
ERROR_VARIABLE plist_error)
CMake: Pick first non-free team id for iOS Xcode projects Previously we picked the first reported team id as found in the Xcode settings file. Now we pick the first non-free team id if there is one, otherwise we pick the first free one. This aligns with qmake behavior. Using a non-free team id usually leads to fewer issues with automatic code-signing. [ChangeLog][iOS][CMake] A non-free Xcode team id is now preferred for project signing. Pick-to: 6.2 6.3 Fixes: QTBUG-96341 Change-Id: I58618fe5c6ca04184812e9bf955a9cb0b3842447 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-05 12:39:10 +00:00
# Parsing state.
set(is_free "")
set(current_team_id "")
set(parsing_is_free FALSE)
set(parsing_team_id FALSE)
set(first_team_id "")
# Parse the xml output and return the first encountered non-free team id. If no non-free team id
# is found, return the first encountered free team id.
# If no team is found, return an empty string.
#
# Example input:
#<plist version="1.0">
#<dict>
# <key>marty@planet.local</key>
# <array>
# <dict>
# <key>isFreeProvisioningTeam</key>
# <false/>
# <key>teamID</key>
# <string>AAA</string>
# ...
# </dict>
# <dict>
# <key>isFreeProvisioningTeam</key>
# <true/>
# <key>teamID</key>
# <string>BBB</string>
# ...
# </dict>
# </array>
#</dict>
#</plist>
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
if(teams_xml AND NOT plist_error)
string(REPLACE "\n" ";" teams_xml_lines "${teams_xml}")
CMake: Pick first non-free team id for iOS Xcode projects Previously we picked the first reported team id as found in the Xcode settings file. Now we pick the first non-free team id if there is one, otherwise we pick the first free one. This aligns with qmake behavior. Using a non-free team id usually leads to fewer issues with automatic code-signing. [ChangeLog][iOS][CMake] A non-free Xcode team id is now preferred for project signing. Pick-to: 6.2 6.3 Fixes: QTBUG-96341 Change-Id: I58618fe5c6ca04184812e9bf955a9cb0b3842447 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-05 12:39:10 +00:00
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
foreach(xml_line ${teams_xml_lines})
CMake: Pick first non-free team id for iOS Xcode projects Previously we picked the first reported team id as found in the Xcode settings file. Now we pick the first non-free team id if there is one, otherwise we pick the first free one. This aligns with qmake behavior. Using a non-free team id usually leads to fewer issues with automatic code-signing. [ChangeLog][iOS][CMake] A non-free Xcode team id is now preferred for project signing. Pick-to: 6.2 6.3 Fixes: QTBUG-96341 Change-Id: I58618fe5c6ca04184812e9bf955a9cb0b3842447 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-05 12:39:10 +00:00
string(STRIP "${xml_line}" xml_line)
if(xml_line STREQUAL "<dict>")
# Clean any previously found values when a new team dict is matched.
set(is_free "")
set(current_team_id "")
elseif(xml_line STREQUAL "<key>isFreeProvisioningTeam</key>")
set(parsing_is_free TRUE)
elseif(parsing_is_free)
set(parsing_is_free FALSE)
if(xml_line MATCHES "true")
set(is_free TRUE)
else()
set(is_free FALSE)
endif()
elseif(xml_line STREQUAL "<key>teamID</key>")
set(parsing_team_id TRUE)
elseif(parsing_team_id)
set(parsing_team_id FALSE)
if(xml_line MATCHES "<string>([^<]+)</string>")
set(current_team_id "${CMAKE_MATCH_1}")
else()
continue()
endif()
string(STRIP "${current_team_id}" current_team_id)
# If this is the first team id we found so far, remember that, regardless if's free
# or not.
if(NOT first_team_id AND current_team_id)
set(first_team_id "${current_team_id}")
endif()
# Break early if we found a non-free team id and use it, because we prefer
# a non-free team for signing, just like qmake.
if(NOT is_free AND current_team_id)
set(first_team_id "${current_team_id}")
break()
endif()
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endif()
endforeach()
endif()
CMake: Pick first non-free team id for iOS Xcode projects Previously we picked the first reported team id as found in the Xcode settings file. Now we pick the first non-free team id if there is one, otherwise we pick the first free one. This aligns with qmake behavior. Using a non-free team id usually leads to fewer issues with automatic code-signing. [ChangeLog][iOS][CMake] A non-free Xcode team id is now preferred for project signing. Pick-to: 6.2 6.3 Fixes: QTBUG-96341 Change-Id: I58618fe5c6ca04184812e9bf955a9cb0b3842447 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-05 12:39:10 +00:00
if(NOT first_team_id)
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
message(DEBUG "Failed to extract an Xcode development team id.")
Fix cases of output variables not being passed back to calling scope Some versionless wrappers were not passing back output variables to their calling scope. Ensure they always are. Fix qt6_extract_metatypes() to set its output variable in the parent scope (it was previously setting it erroneously in the local scope). Some functions had code paths that would not set output variables. This would allow situations where if the variables had an initial value set by a higher up parent scope, the output variable would still have that value in the caller's scope upon return. That could be misleading, so fix these code paths to explicitly set the output variable to an empty string instead. Task-number: QTBUG-96121 Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: I291775813f025cabdccd4372ac077cdfd3ec090e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-06 01:18:06 +00:00
set("${out_var}" "" PARENT_SCOPE)
CMake: Pick first non-free team id for iOS Xcode projects Previously we picked the first reported team id as found in the Xcode settings file. Now we pick the first non-free team id if there is one, otherwise we pick the first free one. This aligns with qmake behavior. Using a non-free team id usually leads to fewer issues with automatic code-signing. [ChangeLog][iOS][CMake] A non-free Xcode team id is now preferred for project signing. Pick-to: 6.2 6.3 Fixes: QTBUG-96341 Change-Id: I58618fe5c6ca04184812e9bf955a9cb0b3842447 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-05 12:39:10 +00:00
else()
message(DEBUG "Successfully extracted the first encountered Xcode development team id.")
set_property(GLOBAL PROPERTY _qt_internal_ios_development_team_id "${first_team_id}")
set("${out_var}" "${first_team_id}" PARENT_SCOPE)
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endif()
endfunction()
function(_qt_internal_get_ios_bundle_identifier_prefix out_var)
get_property(prefix GLOBAL PROPERTY _qt_internal_ios_bundle_identifier_prefix)
get_property(prefix_computed GLOBAL PROPERTY
_qt_internal_ios_bundle_identifier_prefix_computed)
if(prefix_computed)
# Just in case if the value is non-empty but still booly FALSE.
if(NOT prefix)
set(prefix "")
endif()
set("${out_var}" "${prefix}" PARENT_SCOPE)
return()
endif()
set_property(GLOBAL PROPERTY _qt_internal_ios_bundle_identifier_prefix_computed "TRUE")
set(home_dir "$ENV{HOME}")
set(xcode_preferences_path "${home_dir}/Library/Preferences/com.apple.dt.Xcode.plist")
message(DEBUG "Trying to extract the default bundle identifier prefix from Xcode preferences.")
execute_process(COMMAND "/usr/libexec/PlistBuddy"
-c "print IDETemplateOptions:bundleIdentifierPrefix"
"${xcode_preferences_path}"
OUTPUT_VARIABLE prefix
ERROR_VARIABLE prefix_error)
if(prefix AND NOT prefix_error)
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
message(DEBUG "Successfully extracted the default bundle identifier prefix.")
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
string(STRIP "${prefix}" prefix)
else()
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
message(DEBUG "Failed to extract the default bundle identifier prefix.")
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endif()
CMake: Fix automatic iOS bundle id extraction If no Xcode preferences file was found, _qt_internal_get_ios_bundle_identifier_prefix accidentally assigned the error output of running PlistBuddy to the bundle id property. That resulted in a bundle id called '${team_id}.Doesn't Exist, Will Create: /Users/qt/Library/Preferences/com.apple.dt.Xcode.plist\n.app' Check that the error variable is empty before assigning. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.1 6.2 Task-number: QTBUG-95838 Change-Id: I3a7241528590ae3e9986cfa1f3e91ac983ef54f6 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-20 12:27:25 +00:00
if(prefix AND NOT prefix_error)
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
set_property(GLOBAL PROPERTY _qt_internal_ios_bundle_identifier_prefix "${prefix}")
set("${out_var}" "${prefix}" PARENT_SCOPE)
Fix cases of output variables not being passed back to calling scope Some versionless wrappers were not passing back output variables to their calling scope. Ensure they always are. Fix qt6_extract_metatypes() to set its output variable in the parent scope (it was previously setting it erroneously in the local scope). Some functions had code paths that would not set output variables. This would allow situations where if the variables had an initial value set by a higher up parent scope, the output variable would still have that value in the caller's scope upon return. That could be misleading, so fix these code paths to explicitly set the output variable to an empty string instead. Task-number: QTBUG-96121 Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: I291775813f025cabdccd4372ac077cdfd3ec090e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-06 01:18:06 +00:00
else()
set("${out_var}" "" PARENT_SCOPE)
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endif()
endfunction()
CMake: Improve iOS bundle identifier handling Developers could use two different CMake properties / variables to specify the bundle identifier of an application. One would be written into the Info.plist file and the other into the Xcode project as a project property. The previous implementation forced developers to set both of them to the same value to have consistency in the project. This is not nice behavior. The new logic allows setting only one of the two, which will then be reused for the one left unspecified. This is more user friendly. Finally the bundle identifier prefix was never escaped, which could cause issues during code signing if it had invalid characters. Now we escape the prefix to ensure the whole identifier is valid. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Task-number: QTBUG-95838 Change-Id: I1448bd643893751c281cc0ea41c763d1bd03360e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-11 11:34:02 +00:00
function(_qt_internal_escape_rfc_1034_identifier value out_var)
# According to https://datatracker.ietf.org/doc/html/rfc1034#section-3.5
# we can only use letters, digits, dot (.) and hyphens (-).
# Underscores are not allowed.
string(REGEX REPLACE "[^A-Za-z0-9.]" "-" value "${value}")
set("${out_var}" "${value}" PARENT_SCOPE)
endfunction()
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
function(_qt_internal_get_default_ios_bundle_identifier out_var)
_qt_internal_get_ios_bundle_identifier_prefix(prefix)
if(NOT prefix)
set(prefix "com.yourcompany")
CMake: Ensure creation of a unique iOS bundle identifier Apple ties iOS application bundle identifiers to Apple accounts. When building against the device SDK, the bundle identifier must be unique, so that Xcode can register the id with the used developer account and create an appropriate provisioning profile for the used device. If it's not unique (was previously used on a machine with a different developer account), in the best case you get an error explaining that. In the worst case you get an error about automatic signing not being enabled (at least on the command line). When building an Xcode project for the first time on a fresh machine, the organization bundle identifier prefix might not be set. Opening a Qt example project on such a machine might result in generating the same bundle identifier, leading to the error described above. Warn project builders that they should either specify a prefix or an entire unique identifier. To ensure building still works in such a case, try to hash the team id if it is present and add it as an infix to the auto-generated bundle identifier. Note that simulator builds are not affected by id uniqueness because apps deployed to the simulator do not require a provisioning profile from Apple. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e [ChangeLog][iOS][CMake] The build system tries to create a unique bundle identifier based on the team id if no organization prefix can be retrieved from Xcode preferences. Pick-to: 6.2 6.3 Task-number: QTBUG-95838 Change-Id: I6ad10076751acf43064330a6e53d6c4e973ec362 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-05-13 12:34:36 +00:00
# For a better out-of-the-box experience, try to create a unique prefix by appending
# the sha1 of the team id, if one is found.
_qt_internal_find_ios_development_team_id(team_id)
if(team_id)
string(SHA1 hash "${team_id}")
string(SUBSTRING "${hash}" 0 8 infix)
string(APPEND prefix ".${infix}")
else()
message(WARNING
"No organization bundle identifier prefix could be retrieved from Xcode "
"preferences. This can lead to code signing issues due to a non-unique bundle "
"identifier. Please set up an organization prefix by creating a new project within "
"Xcode, or consider providing a custom bundle identifier by specifying the "
"XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER property."
)
endif()
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endif()
CMake: Improve iOS bundle identifier handling Developers could use two different CMake properties / variables to specify the bundle identifier of an application. One would be written into the Info.plist file and the other into the Xcode project as a project property. The previous implementation forced developers to set both of them to the same value to have consistency in the project. This is not nice behavior. The new logic allows setting only one of the two, which will then be reused for the one left unspecified. This is more user friendly. Finally the bundle identifier prefix was never escaped, which could cause issues during code signing if it had invalid characters. Now we escape the prefix to ensure the whole identifier is valid. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Task-number: QTBUG-95838 Change-Id: I1448bd643893751c281cc0ea41c763d1bd03360e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-11 11:34:02 +00:00
# Escape the prefix according to rfc 1034, it's important for code-signing. If an invalid
# identifier is used, calling xcodebuild on the command line says that no provisioning profile
# could be found, with no additional error message. If one opens the generated project with
# Xcode and clicks on 'Try again' to get a new profile, it shows a semi-useful error message
# that the identifier is invalid.
_qt_internal_escape_rfc_1034_identifier("${prefix}" prefix)
set(identifier "${prefix}.\${PRODUCT_NAME:rfc1034identifier}")
set("${out_var}" "${identifier}" PARENT_SCOPE)
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endfunction()
CMake: Set a placeholder bundle version for iOS apps Without a bundle version and short version string string, the iOS simulator will refuse to launch the app. Set a placeholder "0.0.1" version for both fields if they were not set by the project. Allow opt-out via a QT_NO_SET_XCODE_BUNDLE_VERSION variable. Pick-to: 6.2 Fixes: QTBUG-95836 Task-number: QTBUG-95838 Change-Id: I3e959766c7fa13f23ad12882f8bd14cd45e7096c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 09:21:01 +00:00
function(_qt_internal_set_placeholder_apple_bundle_version target)
# If user hasn't provided neither a bundle version nor a bundle short version string for the
# app, set a placeholder value for both which will add them to the generated Info.plist file.
# This is required so that the app launches in the simulator (but apparently not for running
# on-device).
get_target_property(bundle_version "${target}" MACOSX_BUNDLE_BUNDLE_VERSION)
get_target_property(bundle_short_version "${target}" MACOSX_BUNDLE_SHORT_VERSION_STRING)
if(NOT MACOSX_BUNDLE_BUNDLE_VERSION AND
NOT MACOSX_BUNDLE_SHORT_VERSION_STRING AND
NOT bundle_version AND
NOT bundle_short_version AND
NOT QT_NO_SET_XCODE_BUNDLE_VERSION
cmake: Set CURRENT_PROJECT_VERSION and MARKETING_VERSION for Xcode projects This provides a better user-experience, as the two settings have dedicated fields in the project UI, and matches how new projects are generated by Xcode itself. Pick-to: 6.4 Change-Id: I23acc7c6506f1818ef4a90f6f595bc449f83c57b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 11:00:02 +00:00
)
cmake: Pick up project and target version when setting bundle versions And update the default version number to 1.0, which more closely matches the Xcode default. Pick-to: 6.4 Change-Id: I2cd785fffe8b960e5fa5db4803eaeee10791b7aa Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
2022-07-14 11:48:45 +00:00
get_target_property(version "${target}" VERSION)
if(NOT version)
set(version "${PROJECT_VERSION}")
if(NOT version)
set(version "1.0.0")
endif()
endif()
# Use x.y for short version and x.y.z for full version
# Any versions longer than this will fail App Store
# submission.
string(REPLACE "." ";" version_list ${version})
list(LENGTH version_list version_list_length)
list(GET version_list 0 version_major)
set(bundle_short_version "${version_major}")
if(version_list_length GREATER 1)
list(GET version_list 1 version_minor)
string(APPEND bundle_short_version ".${version_minor}")
endif()
set(bundle_version "${bundle_short_version}")
if(version_list_length GREATER 2)
list(GET version_list 2 version_patch)
string(APPEND bundle_version ".${version_patch}")
endif()
cmake: Set CURRENT_PROJECT_VERSION and MARKETING_VERSION for Xcode projects This provides a better user-experience, as the two settings have dedicated fields in the project UI, and matches how new projects are generated by Xcode itself. Pick-to: 6.4 Change-Id: I23acc7c6506f1818ef4a90f6f595bc449f83c57b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 11:00:02 +00:00
if(NOT CMAKE_XCODE_ATTRIBUTE_MARKETING_VERSION
AND NOT QT_NO_SET_XCODE_ATTRIBUTE_MARKETING_VERSION
AND NOT CMAKE_XCODE_ATTRIBUTE_CURRENT_PROJECT_VERSION
AND NOT QT_NO_SET_XCODE_ATTRIBUTE_CURRENT_PROJECT_VERSION)
get_target_property(marketing_version "${target}"
XCODE_ATTRIBUTE_MARKETING_VERSION)
get_target_property(current_project_version "${target}"
XCODE_ATTRIBUTE_CURRENT_PROJECT_VERSION)
if(NOT marketing_version AND NOT current_project_version)
set_target_properties("${target}"
PROPERTIES
XCODE_ATTRIBUTE_CURRENT_PROJECT_VERSION "${bundle_version}"
XCODE_ATTRIBUTE_MARKETING_VERSION "${bundle_short_version}"
)
set(bundle_version "$(CURRENT_PROJECT_VERSION)")
set(bundle_short_version "$(MARKETING_VERSION)")
endif()
endif()
set_target_properties("${target}"
CMake: Set a placeholder bundle version for iOS apps Without a bundle version and short version string string, the iOS simulator will refuse to launch the app. Set a placeholder "0.0.1" version for both fields if they were not set by the project. Allow opt-out via a QT_NO_SET_XCODE_BUNDLE_VERSION variable. Pick-to: 6.2 Fixes: QTBUG-95836 Task-number: QTBUG-95838 Change-Id: I3e959766c7fa13f23ad12882f8bd14cd45e7096c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 09:21:01 +00:00
PROPERTIES
MACOSX_BUNDLE_BUNDLE_VERSION "${bundle_version}"
MACOSX_BUNDLE_SHORT_VERSION_STRING "${bundle_short_version}"
)
endif()
endfunction()
CMake: Split some iOS handling code into separate functions Pick-to: 6.2 6.3 Change-Id: I722194c11ce2588ada78597129b5a185f1e9fc69 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-04 13:59:24 +00:00
function(_qt_internal_set_xcode_development_team_id target)
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
# If user hasn't provided a development team id, try to find the first one specified
# in the Xcode preferences.
if(NOT CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM AND NOT QT_NO_SET_XCODE_DEVELOPMENT_TEAM_ID)
get_target_property(existing_team_id "${target}" XCODE_ATTRIBUTE_DEVELOPMENT_TEAM)
if(NOT existing_team_id)
_qt_internal_find_ios_development_team_id(team_id)
set_target_properties("${target}"
PROPERTIES XCODE_ATTRIBUTE_DEVELOPMENT_TEAM "${team_id}")
endif()
endif()
CMake: Split some iOS handling code into separate functions Pick-to: 6.2 6.3 Change-Id: I722194c11ce2588ada78597129b5a185f1e9fc69 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-04 13:59:24 +00:00
endfunction()
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
CMake: Split some iOS handling code into separate functions Pick-to: 6.2 6.3 Change-Id: I722194c11ce2588ada78597129b5a185f1e9fc69 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-04 13:59:24 +00:00
function(_qt_internal_set_xcode_bundle_identifier target)
CMake: Improve iOS bundle identifier handling Developers could use two different CMake properties / variables to specify the bundle identifier of an application. One would be written into the Info.plist file and the other into the Xcode project as a project property. The previous implementation forced developers to set both of them to the same value to have consistency in the project. This is not nice behavior. The new logic allows setting only one of the two, which will then be reused for the one left unspecified. This is more user friendly. Finally the bundle identifier prefix was never escaped, which could cause issues during code signing if it had invalid characters. Now we escape the prefix to ensure the whole identifier is valid. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Task-number: QTBUG-95838 Change-Id: I1448bd643893751c281cc0ea41c763d1bd03360e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-11 11:34:02 +00:00
# Skip all logic if requested.
if(QT_NO_SET_XCODE_BUNDLE_IDENTIFIER)
return()
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endif()
CMake: Improve iOS bundle identifier handling Developers could use two different CMake properties / variables to specify the bundle identifier of an application. One would be written into the Info.plist file and the other into the Xcode project as a project property. The previous implementation forced developers to set both of them to the same value to have consistency in the project. This is not nice behavior. The new logic allows setting only one of the two, which will then be reused for the one left unspecified. This is more user friendly. Finally the bundle identifier prefix was never escaped, which could cause issues during code signing if it had invalid characters. Now we escape the prefix to ensure the whole identifier is valid. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Task-number: QTBUG-95838 Change-Id: I1448bd643893751c281cc0ea41c763d1bd03360e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-11 11:34:02 +00:00
# There are two fields to consider: the CFBundleIdentifier key (CFBI) to be written to
# Info.plist
# and the PRODUCT_BUNDLE_IDENTIFIER (PBI) property to set in the Xcode project.
# The following logic enables the best out-of-the-box experience combined with maximum
# customization.
# 1) If values for both fields are not provided, assign ${PRODUCT_BUNDLE_IDENTIFIER} to CFBI
# (which is expanded by xcodebuild at build time and will use the value of PBI) and
# auto-compute a default PBI from Xcode's ${PRODUCT_NAME}.
# 2) If CFBI is set and PBI isn't, use given CFBI and keep PBI empty.
# 3) If PBI is set and CFBI isn't, assign ${PRODUCT_BUNDLE_IDENTIFIER} to CFBI and use
# the given PBI.
# 4) If both are set, use both given values.
# TLDR:
# cfbi pbi -> result_cfbi result_pbi
# unset unset computed computed
# set unset given_val unset
# unset set computed given_val
# set set given_val given_val
get_target_property(existing_cfbi "${target}" MACOSX_BUNDLE_GUI_IDENTIFIER)
if(NOT MACOSX_BUNDLE_GUI_IDENTIFIER AND NOT existing_cfbi)
set(is_cfbi_given FALSE)
else()
set(is_cfbi_given TRUE)
endif()
if(NOT is_cfbi_given)
set_target_properties("${target}"
PROPERTIES
MACOSX_BUNDLE_GUI_IDENTIFIER "\${PRODUCT_BUNDLE_IDENTIFIER}")
endif()
get_target_property(existing_pbi "${target}" XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER)
if(NOT CMAKE_XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER AND NOT existing_pbi)
set(is_pbi_given FALSE)
else()
set(is_pbi_given TRUE)
endif()
if(NOT is_pbi_given AND NOT is_cfbi_given)
_qt_internal_get_default_ios_bundle_identifier(bundle_id)
set_target_properties("${target}"
PROPERTIES
XCODE_ATTRIBUTE_PRODUCT_BUNDLE_IDENTIFIER "${bundle_id}")
CMake: Generate better Xcode iOS projects Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-14 16:16:44 +00:00
endif()
CMake: Split some iOS handling code into separate functions Pick-to: 6.2 6.3 Change-Id: I722194c11ce2588ada78597129b5a185f1e9fc69 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-04 13:59:24 +00:00
endfunction()
CMake: Set default xcode device family to iPhone and iPad This matches what we do with qmake, which means a build application can be deployed to either an iPhone or an iPad by default, without having to fiddle with Xcode settings. The device family will not be set if the target XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY property or the CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY variable has a value. There's also an opt-out variable called QT_NO_SET_XCODE_TARGETED_DEVICE_FAMILY Pick-to: 6.2 6.3 Fixes: QTBUG-100833 Change-Id: I8cde10975b44af81cfa18f985523c8ec1529386d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-03 16:17:37 +00:00
function(_qt_internal_set_xcode_targeted_device_family target)
if(NOT CMAKE_XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY
AND NOT QT_NO_SET_XCODE_TARGETED_DEVICE_FAMILY)
get_target_property(existing_device_family
"${target}" XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY)
if(NOT existing_device_family)
set(device_family_iphone_and_ipad "1,2")
set_target_properties("${target}"
PROPERTIES
XCODE_ATTRIBUTE_TARGETED_DEVICE_FAMILY
"${device_family_iphone_and_ipad}")
endif()
endif()
endfunction()
CMake: Set iOS default code style signing to Automatic As far as I can see, the default is already 'Automatic' when it is not specified, but it does improve some xcodebuild error messages in certain edge cases if the option is specified explicitly. Note that setting the style to Automatic will not suffice in order to build the project from the command line with xcodebuild, if there is no existing provisioning profile for the project in ~/Library/MobileDevice/Provisioning Profiles You either need to build it once via the Xcode GUI, or you need to call xcodebuild -allowProvisioningUpdates which will try to create / download a provisioning profile from Apple's server. This implies that Xcode must have been launched at least once, and configured with a valid Apple developer account, including a free account. qmake already generates a Makefile that calls xcodebuild -allowProvisioningUpdates. CMake doesn't have a Makefile wrapper, so calling cmake --build . will call xcodebuild directly, which again means users need to pass -allowProvisioningUpdates explicitly. It does not look like CMake intends to call it automatically any time soon, see https://gitlab.kitware.com/cmake/cmake/-/issues/22615 We intend to teach Qt Creator to add the -allowProvisioningUpdate option when building a project using CMake. The code sign style will not be set if the target XCODE_ATTRIBUTE_CODE_SIGN_STYLE property or the CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_STYLE variable has a value. There's also an opt-out variable called QT_NO_SET_XCODE_CODE_SIGN_STYLE Pick-to: 6.2 6.3 Fixes: QTBUG-96347 Change-Id: If65ccb8a0393ff6d80e6caea3b8003fc59a8a62a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-04 13:42:06 +00:00
function(_qt_internal_set_xcode_code_sign_style target)
if(NOT CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_STYLE
AND NOT QT_NO_SET_XCODE_CODE_SIGN_STYLE)
get_target_property(existing_code_style
"${target}" XCODE_ATTRIBUTE_CODE_SIGN_STYLE)
if(NOT existing_code_style)
set(existing_code_style "Automatic")
set_target_properties("${target}"
PROPERTIES
XCODE_ATTRIBUTE_CODE_SIGN_STYLE
"${existing_code_style}")
endif()
endif()
endfunction()
cmake: Work around bug in CMake's Xcode generator setting INSTALL_PATH CMake will set the INSTALL_PATH for applications to an empty string, which confuses Xcode and results in application archives that can't be distributed on the App Store. https://gitlab.kitware.com/cmake/cmake/-/issues/15183 Pick-to: 6.2 6.3 6.4 Change-Id: Ie19f41c20fdca1e98b368e3ce4cc524c8df0b23b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-13 22:36:32 +00:00
# Workaround for https://gitlab.kitware.com/cmake/cmake/-/issues/15183
function(_qt_internal_set_xcode_install_path target)
if(NOT CMAKE_XCODE_ATTRIBUTE_INSTALL_PATH
AND NOT QT_NO_SET_XCODE_INSTALL_PATH)
get_target_property(existing_install_path
"${target}" XCODE_ATTRIBUTE_INSTALL_PATH)
if(NOT existing_install_path)
set_target_properties("${target}"
PROPERTIES
XCODE_ATTRIBUTE_INSTALL_PATH
"$(inherited)")
endif()
endif()
endfunction()
CMake: Use the PRODUCT_NAME for the iOS display name like qmake This ensures that the Xcode 'Display name' input under ${target} -> General -> Identity -> Display name is not empty. Because adding ${PRODUCT_NAME} directly in the Info.plist.in template will cause CMake to evaluate it as variable expansion, work around the issue by putting the dollar sign into a separate cache variable that after evaluation will result in ${PRODUCT_NAME} being in the file verbatim, so that Xcode evaluate it at build time. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Task-number: QTBUG-95838 Change-Id: I2d1090cc8e84b32442f7daca2d4ce5e3ad413c68 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-05-11 11:15:20 +00:00
function(_qt_internal_set_xcode_bundle_display_name target)
# We want the value of CFBundleDisplayName to be ${PRODUCT_NAME}, but we can't put that
# into the Info.plist.in template file directly, because the implicit configure_file(Info.plist)
# done by CMake is not using the @ONLY option, so CMake would treat the assignment as
# variable expansion. Escaping using backslashes does not help.
# Work around it by assigning the dollar char to a separate cache var, and expand it, so that
# the final value in the file will be ${PRODUCT_NAME}, to be evaluated at build time by Xcode.
set(QT_INTERNAL_DOLLAR_VAR "$" CACHE STRING "")
endfunction()
Explicitly disable bitcode for iOS applications We disabled building Qt with bitcode in e27a0d5a0f8818653ff125409db81, but the default in Xcode 13 is still to build applications with bitcode, leading to build issues when built against a non-bitcode-enabled Qt. For qmake we already explicitly disable bitcode, so do the same for CMake. Pick-to: 6.2 6.3 6.4 Change-Id: I3fd542373c3e1326eb1088a173e70955e61ff608 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-12 13:56:47 +00:00
function(_qt_internal_set_xcode_bitcode_enablement target)
if(CMAKE_XCODE_ATTRIBUTE_ENABLE_BITCODE
OR QT_NO_SET_XCODE_ENABLE_BITCODE)
return()
endif()
get_target_property(existing_bitcode_enablement
"${target}" XCODE_ATTRIBUTE_ENABLE_BITCODE)
if(NOT existing_bitcode_enablement MATCHES "-NOTFOUND")
return()
endif()
# Disable bitcode to match Xcode 14's new default
set_target_properties("${target}"
PROPERTIES
XCODE_ATTRIBUTE_ENABLE_BITCODE
"NO")
endfunction()
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
function(_qt_internal_generate_ios_info_plist target)
# If the project already specifies a custom file, we don't override it.
get_target_property(existing_plist "${target}" MACOSX_BUNDLE_INFO_PLIST)
if(existing_plist)
return()
endif()
set(info_plist_in "${__qt_internal_cmake_ios_support_files_path}/Info.plist.app.in")
string(MAKE_C_IDENTIFIER "${target}" target_identifier)
set(info_plist_out_dir
"${CMAKE_CURRENT_BINARY_DIR}/.qt/info_plist/${target_identifier}")
set(info_plist_out "${info_plist_out_dir}/Info.plist")
# Check if we need to specify a custom launch screen storyboard entry.
get_target_property(launch_screen_name "${target}" _qt_ios_launch_screen_name)
if(launch_screen_name)
set(qt_ios_launch_screen_plist_entry "${launch_screen_name}")
endif()
# Call configure_file to substitute Qt-specific @FOO@ values, not ${FOO} values.
#
# The output file will be another template file to be fed to CMake via the
# MACOSX_BUNDLE_INFO_PLIST property. CMake will then call configure_file on it to provide
# content for regular entries like CFBundleName, etc.
#
# We require this extra configure_file call so we can create unique Info.plist files for each
# target in a project, while also providing a way to add Qt specific entries that CMake
# does not support out of the box (e.g. a launch screen name).
configure_file(
"${info_plist_in}"
"${info_plist_out}"
@ONLY
)
set_target_properties("${target}" PROPERTIES MACOSX_BUNDLE_INFO_PLIST "${info_plist_out}")
endfunction()
CMake: Override simulator architecture to x86_64 for Xcode generator The simulator build of Qt for iOS is currently x86_64 only, instead of universal builds with an arm64 slice as well, since we don't support xcframeworks. This means we can't rely on Xcode's default simulator arch settings, which on an Apple Silicon Mac will be arm64. Instead we override the simulator arch, like we do for qmake. Pick-to: 6.4 6.3 6.2 Change-Id: I8b52389db1b83f4f9679c724bcde53b44dbc76f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 14:51:34 +00:00
function(_qt_internal_set_ios_simulator_arch target)
if(CMAKE_XCODE_ATTRIBUTE_ARCHS
OR QT_NO_SET_XCODE_ARCHS)
return()
endif()
get_target_property(existing_archs
"${target}" XCODE_ATTRIBUTE_ARCHS)
if(NOT existing_archs MATCHES "-NOTFOUND")
return()
endif()
if(NOT x86_64 IN_LIST QT_OSX_ARCHITECTURES)
return()
endif()
if(CMAKE_OSX_ARCHITECTURES AND NOT x86_64 IN_LIST CMAKE_OSX_ARCHITECTURES)
return()
endif()
set_target_properties("${target}"
PROPERTIES
"XCODE_ATTRIBUTE_ARCHS[sdk=iphonesimulator*]"
"x86_64")
endfunction()
cmake: Share most finalizers between macOS and iOS apps The macOS app code path was missing a bunch of finalizers that also makes sense for macOS apps. Pick-to: 6.4 Change-Id: I2b779a1d64086824f43e304f2c7d3b1cd2780070 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 10:12:54 +00:00
function(_qt_internal_finalize_apple_app target)
# Shared between macOS and iOS apps
CMake: Split some iOS handling code into separate functions Pick-to: 6.2 6.3 Change-Id: I722194c11ce2588ada78597129b5a185f1e9fc69 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-04 13:59:24 +00:00
_qt_internal_set_xcode_development_team_id("${target}")
_qt_internal_set_xcode_bundle_identifier("${target}")
CMake: Set iOS default code style signing to Automatic As far as I can see, the default is already 'Automatic' when it is not specified, but it does improve some xcodebuild error messages in certain edge cases if the option is specified explicitly. Note that setting the style to Automatic will not suffice in order to build the project from the command line with xcodebuild, if there is no existing provisioning profile for the project in ~/Library/MobileDevice/Provisioning Profiles You either need to build it once via the Xcode GUI, or you need to call xcodebuild -allowProvisioningUpdates which will try to create / download a provisioning profile from Apple's server. This implies that Xcode must have been launched at least once, and configured with a valid Apple developer account, including a free account. qmake already generates a Makefile that calls xcodebuild -allowProvisioningUpdates. CMake doesn't have a Makefile wrapper, so calling cmake --build . will call xcodebuild directly, which again means users need to pass -allowProvisioningUpdates explicitly. It does not look like CMake intends to call it automatically any time soon, see https://gitlab.kitware.com/cmake/cmake/-/issues/22615 We intend to teach Qt Creator to add the -allowProvisioningUpdate option when building a project using CMake. The code sign style will not be set if the target XCODE_ATTRIBUTE_CODE_SIGN_STYLE property or the CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_STYLE variable has a value. There's also an opt-out variable called QT_NO_SET_XCODE_CODE_SIGN_STYLE Pick-to: 6.2 6.3 Fixes: QTBUG-96347 Change-Id: If65ccb8a0393ff6d80e6caea3b8003fc59a8a62a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-04 13:42:06 +00:00
_qt_internal_set_xcode_code_sign_style("${target}")
CMake: Use the PRODUCT_NAME for the iOS display name like qmake This ensures that the Xcode 'Display name' input under ${target} -> General -> Identity -> Display name is not empty. Because adding ${PRODUCT_NAME} directly in the Info.plist.in template will cause CMake to evaluate it as variable expansion, work around the issue by putting the dollar sign into a separate cache variable that after evaluation will result in ${PRODUCT_NAME} being in the file verbatim, so that Xcode evaluate it at build time. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Task-number: QTBUG-95838 Change-Id: I2d1090cc8e84b32442f7daca2d4ce5e3ad413c68 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-05-11 11:15:20 +00:00
_qt_internal_set_xcode_bundle_display_name("${target}")
cmake: Work around bug in CMake's Xcode generator setting INSTALL_PATH CMake will set the INSTALL_PATH for applications to an empty string, which confuses Xcode and results in application archives that can't be distributed on the App Store. https://gitlab.kitware.com/cmake/cmake/-/issues/15183 Pick-to: 6.2 6.3 6.4 Change-Id: Ie19f41c20fdca1e98b368e3ce4cc524c8df0b23b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-13 22:36:32 +00:00
_qt_internal_set_xcode_install_path("${target}")
cmake: Share most finalizers between macOS and iOS apps The macOS app code path was missing a bunch of finalizers that also makes sense for macOS apps. Pick-to: 6.4 Change-Id: I2b779a1d64086824f43e304f2c7d3b1cd2780070 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 10:12:54 +00:00
_qt_internal_set_placeholder_apple_bundle_version("${target}")
endfunction()
function(_qt_internal_finalize_ios_app target)
_qt_internal_finalize_apple_app("${target}")
CMake: Set a placeholder bundle version for iOS apps Without a bundle version and short version string string, the iOS simulator will refuse to launch the app. Set a placeholder "0.0.1" version for both fields if they were not set by the project. Allow opt-out via a QT_NO_SET_XCODE_BUNDLE_VERSION variable. Pick-to: 6.2 Fixes: QTBUG-95836 Task-number: QTBUG-95838 Change-Id: I3e959766c7fa13f23ad12882f8bd14cd45e7096c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-17 09:21:01 +00:00
cmake: Share most finalizers between macOS and iOS apps The macOS app code path was missing a bunch of finalizers that also makes sense for macOS apps. Pick-to: 6.4 Change-Id: I2b779a1d64086824f43e304f2c7d3b1cd2780070 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 10:12:54 +00:00
_qt_internal_set_xcode_targeted_device_family("${target}")
_qt_internal_set_xcode_bitcode_enablement("${target}")
CMake: Add default launch screen storyboard for iOS apps Bundle a default LaunchScreen.storyboard file for an iOS app and make sure it's referenced in the generated Info.plist file. When launching Qt examples, it ensures the app uses the whole screen space on the device rather than just a square-ish part of it. The storyboard file is a copy of the qmake one, which qmake adds to the Xcode projects it generates. A custom launch screen can be provided either by setting the QT_IOS_LAUNCH_SCREEN variable or by setting the QT_IOS_LAUNCH_SCREEN target property. The value must be an absolute path to the launch screen file. The automatic addition of the launch screen entry in the Info.plist file can be prevented by setting the QT_NO_SET_IOS_LAUNCH_SCREEN variable to TRUE. The automatic bundling of the launch screen file in the application bundle can be prevented by setting the QT_NO_ADD_IOS_LAUNCH_SCREEN_TO_BUNDLE variable to TRUE. The current implementation has a limitation that only one launch screen storyboard and one iOS executable can exist within a project. If there are multiple executables in the project, all of them will use the launch screen that is specified last (the last qt_add_executable call). Because of this limitation, the API is marked as Technical Preview, to be improved upon in the future. For now it simply serves as an improvement to the out-of-the-box experience of iOS apps built with CMake. Amends 4d838dae5a821e9e5f013ba1d5a494ece1b5180e Pick-to: 6.2 6.3 Fixes: QTBUG-95837 Change-Id: I6b067d703d635122959a1ef17fcca713da694a86 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-07-15 14:20:20 +00:00
_qt_internal_handle_ios_launch_screen("${target}")
CMake: Add per-target support for iOS launch screens To support per-target iOS launch screens we need a way to specify custom Info.plist entries without using cache variables, which we were forced to use due to the implicit configure_file done for MACOSX_BUNDLE_INFO_PLIST. We now introduce an extra configure_file call done in a finalizer, before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST. This extra configure_file call allows us to insert / substitute additional Info.plist entries that CMake does not allow setting. If a custom Info.plist file is provided, the finalizer will simply skip the logic for creating a new one. Amends e5b3436255ce095af58608b03b913fc9bcb8e61f Pick-to: 6.4 Fixes: QTBUG-101064 Change-Id: I65496da146c9430a949a8163817021d54da28386 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-06 15:19:52 +00:00
_qt_internal_generate_ios_info_plist("${target}")
CMake: Override simulator architecture to x86_64 for Xcode generator The simulator build of Qt for iOS is currently x86_64 only, instead of universal builds with an arm64 slice as well, since we don't support xcframeworks. This means we can't rely on Xcode's default simulator arch settings, which on an Apple Silicon Mac will be arm64. Instead we override the simulator arch, like we do for qmake. Pick-to: 6.4 6.3 6.2 Change-Id: I8b52389db1b83f4f9679c724bcde53b44dbc76f1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-08-03 14:51:34 +00:00
_qt_internal_set_ios_simulator_arch("${target}")
Fix linking of examples Provide add_qt_gui_executable() as function in our public API that takes care of automaticWinMain linkage. We can use this in the future to encapsulate similarplatform-specific behavior and adjustments, such as module generation onAndroid. In order for the examples to see the function in Qt5CoreMacros, three more additional fixes were required: * Do the build_repo_end() call _before_ attempting to build the examples, as we need the build_repo_end() to include QtPostProcess and complete the creation of all the target config files. Otherwise the find_package() calls in the examples see something incomplete. * Add more QT_NO_CREATE_TARGET guards * Always call find_dependency on the dependencies, regardless of the target creation mode. This way a find_package(Qt5 COMPONENTS Widgets) will still load Qt5CoreMacros. Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-11 13:46:31 +00:00
endfunction()
Add CMake deployment support Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-29 23:29:34 +00:00
function(_qt_internal_finalize_macos_app target)
get_target_property(is_bundle ${target} MACOSX_BUNDLE)
if(NOT is_bundle)
return()
endif()
cmake: Share most finalizers between macOS and iOS apps The macOS app code path was missing a bunch of finalizers that also makes sense for macOS apps. Pick-to: 6.4 Change-Id: I2b779a1d64086824f43e304f2c7d3b1cd2780070 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 10:12:54 +00:00
_qt_internal_finalize_apple_app("${target}")
Add CMake deployment support Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-29 23:29:34 +00:00
# Make sure the install rpath has at least the minimum needed if the app
# has any non-static frameworks. We can't rigorously know if the app will
# have any, even with a static Qt, so always add this. If there are no
# frameworks, it won't do any harm.
get_property(install_rpath TARGET ${target} PROPERTY INSTALL_RPATH)
list(APPEND install_rpath "@executable_path/../Frameworks")
list(REMOVE_DUPLICATES install_rpath)
set_property(TARGET ${target} PROPERTY INSTALL_RPATH "${install_rpath}")
endfunction()
CMake: Rename add_qt_gui_executable to qt_add_executable Also adjust pro2cmake to use the new qt_add_executable name instead of add_qt_gui_executable. No compatibility functions provided this time, so we'll need to follow through all repos and regenerate all examples. Two reasons for not providing compaitibility functions: 1) We don't intend add_qt_gui_executable to be public API 2) A previous case with qtquickcontrols2 and qttools pointed out that making top-level builds work with cross-compatibility API is not simple. So just go ahead and regenerate everything. Task-number: QTBUG-87661 Change-Id: I2f228827b786ae03bf7e1bf3908ea02a8794ed52 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-15 15:58:15 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_add_executable)
CMake: Rename add_qt_gui_executable to qt_add_executable Also adjust pro2cmake to use the new qt_add_executable name instead of add_qt_gui_executable. No compatibility functions provided this time, so we'll need to follow through all repos and regenerate all examples. Two reasons for not providing compaitibility functions: 1) We don't intend add_qt_gui_executable to be public API 2) A previous case with qtquickcontrols2 and qttools pointed out that making top-level builds work with cross-compatibility API is not simple. So just go ahead and regenerate everything. Task-number: QTBUG-87661 Change-Id: I2f228827b786ae03bf7e1bf3908ea02a8794ed52 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-15 15:58:15 +00:00
qt6_add_executable(${ARGV})
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
function(qt_finalize_target)
CMake: Replace qt_finalize_executable with qt_finalize_target It's very likely that we'll have to run certain finalizer code for targets other than executables. Rename qt_finalize_executable to _qt_internal_finalize_executable so it's internal. Introduce a new function qt_finalize_target which will call the above internal one when the target is an executable. This should future proof the API so we have a hook to call code for any user CMake project that intends to use Qt CMake API. Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-18 17:42:55 +00:00
qt6_finalize_target(${ARGV})
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
Bring back qt_finalize_executable qt_finalize_executable was renamed to qt_finalize_target in commit c4df673dd903. Anyhow, app wizards in Qt Creator 4.15 already use it, so let's keep it as an synonym API for the time being. Fixes: QTBUG-94156 Change-Id: I468443c80c027ac49a21208a9b15af1dbb4a5f84 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:08:35 +00:00
# Kept for compatibility with Qt Creator 4.15 wizards
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_finalize_executable)
Bring back qt_finalize_executable qt_finalize_executable was renamed to qt_finalize_target in commit c4df673dd903. Anyhow, app wizards in Qt Creator 4.15 already use it, so let's keep it as an synonym API for the time being. Fixes: QTBUG-94156 Change-Id: I468443c80c027ac49a21208a9b15af1dbb4a5f84 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-02 15:08:35 +00:00
qt6_finalize_target(${ARGV})
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
CMake: Rename add_qt_gui_executable to qt_add_executable Also adjust pro2cmake to use the new qt_add_executable name instead of add_qt_gui_executable. No compatibility functions provided this time, so we'll need to follow through all repos and regenerate all examples. Two reasons for not providing compaitibility functions: 1) We don't intend add_qt_gui_executable to be public API 2) A previous case with qtquickcontrols2 and qttools pointed out that making top-level builds work with cross-compatibility API is not simple. So just go ahead and regenerate everything. Task-number: QTBUG-87661 Change-Id: I2f228827b786ae03bf7e1bf3908ea02a8794ed52 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-15 15:58:15 +00:00
endif()
Fix qt_import_plugins compatibility with Qt 5 Handle versionless plugin names passed to qt_import_plugins. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: Ic7fb6e54d2822c7eb58a7874b4a1c137f0c101d9 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-01-22 15:28:57 +00:00
function(_qt_get_plugin_name_with_version target out_var)
string(REGEX REPLACE "^Qt::(.+)" "Qt${QT_DEFAULT_MAJOR_VERSION}::\\1"
qt_plugin_with_version "${target}")
if(TARGET "${qt_plugin_with_version}")
set("${out_var}" "${qt_plugin_with_version}" PARENT_SCOPE)
else()
set("${out_var}" "" PARENT_SCOPE)
endif()
endfunction()
cmake: allow client apps to load static plug-ins Based in part on Kyle Edwards's implementation : https://codereview.qt-project.org/c/qt/qtbase/+/243731 Example : ``` cmake_minimum_required(VERSION 3.15) project(foo) add_executable(foo main.cpp) find_package(ICU COMPONENTS i18n uc data REQUIRED) find_package(Qt6 COMPONENTS Core Gui REQUIRED) target_link_libraries(foo Qt6::Core Qt6::Gui) qt_import_plugins(foo INCLUDE Qt6::qxcb EXCLUDE Qt6::qgtk3 Qt6::qeglfs-kms-integration Qt6::qjpeg ) ``` Change-Id: If7736c42f669f7d7f43052cae59c28fc7fcb4156 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-07 07:13:31 +00:00
macro(_qt_import_plugin target plugin)
Fix qt_import_plugins compatibility with Qt 5 Handle versionless plugin names passed to qt_import_plugins. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: Ic7fb6e54d2822c7eb58a7874b4a1c137f0c101d9 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-01-22 15:28:57 +00:00
set(_final_plugin_name "${plugin}")
if(NOT TARGET "${plugin}")
_qt_get_plugin_name_with_version("${plugin}" _qt_plugin_with_version_name)
if(TARGET "${_qt_plugin_with_version_name}")
set(_final_plugin_name "${_qt_plugin_with_version_name}")
endif()
endif()
if(NOT TARGET "${_final_plugin_name}")
message(
"Warning: plug-in ${_final_plugin_name} is not known to the current Qt installation.")
else()
get_target_property(_plugin_class_name "${_final_plugin_name}" QT_PLUGIN_CLASS_NAME)
if(_plugin_class_name)
set_property(TARGET "${target}" APPEND PROPERTY QT_PLUGINS "${plugin}")
endif()
cmake: allow client apps to load static plug-ins Based in part on Kyle Edwards's implementation : https://codereview.qt-project.org/c/qt/qtbase/+/243731 Example : ``` cmake_minimum_required(VERSION 3.15) project(foo) add_executable(foo main.cpp) find_package(ICU COMPONENTS i18n uc data REQUIRED) find_package(Qt6 COMPONENTS Core Gui REQUIRED) target_link_libraries(foo Qt6::Core Qt6::Gui) qt_import_plugins(foo INCLUDE Qt6::qxcb EXCLUDE Qt6::qgtk3 Qt6::qeglfs-kms-integration Qt6::qjpeg ) ``` Change-Id: If7736c42f669f7d7f43052cae59c28fc7fcb4156 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-07 07:13:31 +00:00
endif()
endmacro()
CMake: Disable static plugin imports for non-executable targets There is no point in generating cpp files containing Q_IMPORT_PLUGIN() macro calls for non-executable targets like modules, plugins and object libraries in a static Qt build. It causes unnecessary compiling of 10+ files for each of those targets. In a static Qt build, plugin imports should only be done for executables, tools and applications. Pick-to: 6.0 Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-30 18:28:00 +00:00
function(_qt_internal_disable_static_default_plugins target)
set_target_properties(${target} PROPERTIES QT_DEFAULT_PLUGINS 0)
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
function(qt6_import_plugins target)
Match qt_import_plugin API with qt5's Some work was needed to make the plug-in types, and which plug-ins are available for each type in client code. Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-23 14:57:06 +00:00
cmake_parse_arguments(arg "NO_DEFAULT" "" "INCLUDE;EXCLUDE;INCLUDE_BY_TYPE;EXCLUDE_BY_TYPE" ${ARGN})
cmake: allow client apps to load static plug-ins Based in part on Kyle Edwards's implementation : https://codereview.qt-project.org/c/qt/qtbase/+/243731 Example : ``` cmake_minimum_required(VERSION 3.15) project(foo) add_executable(foo main.cpp) find_package(ICU COMPONENTS i18n uc data REQUIRED) find_package(Qt6 COMPONENTS Core Gui REQUIRED) target_link_libraries(foo Qt6::Core Qt6::Gui) qt_import_plugins(foo INCLUDE Qt6::qxcb EXCLUDE Qt6::qgtk3 Qt6::qeglfs-kms-integration Qt6::qjpeg ) ``` Change-Id: If7736c42f669f7d7f43052cae59c28fc7fcb4156 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-07 07:13:31 +00:00
Match qt_import_plugin API with qt5's Some work was needed to make the plug-in types, and which plug-ins are available for each type in client code. Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-23 14:57:06 +00:00
# Handle NO_DEFAULT
cmake: allow client apps to load static plug-ins Based in part on Kyle Edwards's implementation : https://codereview.qt-project.org/c/qt/qtbase/+/243731 Example : ``` cmake_minimum_required(VERSION 3.15) project(foo) add_executable(foo main.cpp) find_package(ICU COMPONENTS i18n uc data REQUIRED) find_package(Qt6 COMPONENTS Core Gui REQUIRED) target_link_libraries(foo Qt6::Core Qt6::Gui) qt_import_plugins(foo INCLUDE Qt6::qxcb EXCLUDE Qt6::qgtk3 Qt6::qeglfs-kms-integration Qt6::qjpeg ) ``` Change-Id: If7736c42f669f7d7f43052cae59c28fc7fcb4156 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-07 07:13:31 +00:00
if(${arg_NO_DEFAULT})
CMake: Disable static plugin imports for non-executable targets There is no point in generating cpp files containing Q_IMPORT_PLUGIN() macro calls for non-executable targets like modules, plugins and object libraries in a static Qt build. It causes unnecessary compiling of 10+ files for each of those targets. In a static Qt build, plugin imports should only be done for executables, tools and applications. Pick-to: 6.0 Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-11-30 18:28:00 +00:00
_qt_internal_disable_static_default_plugins("${target}")
cmake: allow client apps to load static plug-ins Based in part on Kyle Edwards's implementation : https://codereview.qt-project.org/c/qt/qtbase/+/243731 Example : ``` cmake_minimum_required(VERSION 3.15) project(foo) add_executable(foo main.cpp) find_package(ICU COMPONENTS i18n uc data REQUIRED) find_package(Qt6 COMPONENTS Core Gui REQUIRED) target_link_libraries(foo Qt6::Core Qt6::Gui) qt_import_plugins(foo INCLUDE Qt6::qxcb EXCLUDE Qt6::qgtk3 Qt6::qeglfs-kms-integration Qt6::qjpeg ) ``` Change-Id: If7736c42f669f7d7f43052cae59c28fc7fcb4156 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-07 07:13:31 +00:00
endif()
Match qt_import_plugin API with qt5's Some work was needed to make the plug-in types, and which plug-ins are available for each type in client code. Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-23 14:57:06 +00:00
# Handle INCLUDE
cmake: allow client apps to load static plug-ins Based in part on Kyle Edwards's implementation : https://codereview.qt-project.org/c/qt/qtbase/+/243731 Example : ``` cmake_minimum_required(VERSION 3.15) project(foo) add_executable(foo main.cpp) find_package(ICU COMPONENTS i18n uc data REQUIRED) find_package(Qt6 COMPONENTS Core Gui REQUIRED) target_link_libraries(foo Qt6::Core Qt6::Gui) qt_import_plugins(foo INCLUDE Qt6::qxcb EXCLUDE Qt6::qgtk3 Qt6::qeglfs-kms-integration Qt6::qjpeg ) ``` Change-Id: If7736c42f669f7d7f43052cae59c28fc7fcb4156 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-07 07:13:31 +00:00
foreach(plugin ${arg_INCLUDE})
_qt_import_plugin("${target}" "${plugin}")
endforeach()
Match qt_import_plugin API with qt5's Some work was needed to make the plug-in types, and which plug-ins are available for each type in client code. Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-23 14:57:06 +00:00
# Handle EXCLUDE
cmake: allow client apps to load static plug-ins Based in part on Kyle Edwards's implementation : https://codereview.qt-project.org/c/qt/qtbase/+/243731 Example : ``` cmake_minimum_required(VERSION 3.15) project(foo) add_executable(foo main.cpp) find_package(ICU COMPONENTS i18n uc data REQUIRED) find_package(Qt6 COMPONENTS Core Gui REQUIRED) target_link_libraries(foo Qt6::Core Qt6::Gui) qt_import_plugins(foo INCLUDE Qt6::qxcb EXCLUDE Qt6::qgtk3 Qt6::qeglfs-kms-integration Qt6::qjpeg ) ``` Change-Id: If7736c42f669f7d7f43052cae59c28fc7fcb4156 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-06-07 07:13:31 +00:00
foreach(plugin ${arg_EXCLUDE})
set_property(TARGET "${target}" APPEND PROPERTY QT_NO_PLUGINS "${plugin}")
endforeach()
Match qt_import_plugin API with qt5's Some work was needed to make the plug-in types, and which plug-ins are available for each type in client code. Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-23 14:57:06 +00:00
# Handle INCLUDE_BY_TYPE
set(_current_type "")
foreach(_arg ${arg_INCLUDE_BY_TYPE})
string(REGEX REPLACE "[-/]" "_" _plugin_type "${_arg}")
list(FIND QT_ALL_PLUGIN_TYPES_FOUND_VIA_FIND_PACKAGE "${_plugin_type}" _has_plugin_type)
if(${_has_plugin_type} GREATER_EQUAL 0)
set(_current_type "${_plugin_type}")
else()
if("${_current_type}" STREQUAL "")
message(FATAL_ERROR "qt_import_plugins: invalid syntax for INCLUDE_BY_TYPE")
endif()
Fix qt_import_plugins compatibility with Qt 5 Handle versionless plugin names passed to qt_import_plugins. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: Ic7fb6e54d2822c7eb58a7874b4a1c137f0c101d9 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-01-22 15:28:57 +00:00
# Check if passed plugin target name is a version-less one, and make a version-full
# one.
CMake: Resurrect test_import_plugins cmake build tests Now that we run tests for static Qt builds in the CI, it makes sense to restore the CMake build tests that check that static plugin importing works correctly. Resurrect the previously commented out test_import_plugins project and port the mockplugins qmake projects to CMake. mockplugins is a CMake project that uses the internal Qt CMake API to build and install some Qt modules and plugins. test_import_plugins depends on that test (via a CMake fixture) to build public projects that use those plugins. The installation of the mockplugins modules pollutes the Qt install prefix, but in the CI that only happens on the test VM, which means the release packages are not affected. Locally on a developer machine the Qt install path will be polluted, but it's not that much of a big deal. We could try and address that in a future change by using the QT_ADDITIONAL_PACKAGES_PREFIX_PATH functionality added for Conan to allow the installation of Qt packages into a non-standard prefix. Task-number: QTBUG-87580 Task-number: QTBUG-92933 Change-Id: I0841064a60a5ffba5118640d3197527a38ba6c30 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 14:38:53 +00:00
set_property(TARGET "${target}" APPEND PROPERTY "QT_PLUGINS_${_current_type}" "${_arg}")
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
set_property(TARGET "${target}" APPEND PROPERTY "_qt_plugins_by_type" "${_arg}")
Fix qt_import_plugins compatibility with Qt 5 Handle versionless plugin names passed to qt_import_plugins. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: Ic7fb6e54d2822c7eb58a7874b4a1c137f0c101d9 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-01-22 15:28:57 +00:00
_qt_get_plugin_name_with_version("${_arg}" qt_plugin_with_version)
CMake: Resurrect test_import_plugins cmake build tests Now that we run tests for static Qt builds in the CI, it makes sense to restore the CMake build tests that check that static plugin importing works correctly. Resurrect the previously commented out test_import_plugins project and port the mockplugins qmake projects to CMake. mockplugins is a CMake project that uses the internal Qt CMake API to build and install some Qt modules and plugins. test_import_plugins depends on that test (via a CMake fixture) to build public projects that use those plugins. The installation of the mockplugins modules pollutes the Qt install prefix, but in the CI that only happens on the test VM, which means the release packages are not affected. Locally on a developer machine the Qt install path will be polluted, but it's not that much of a big deal. We could try and address that in a future change by using the QT_ADDITIONAL_PACKAGES_PREFIX_PATH functionality added for Conan to allow the installation of Qt packages into a non-standard prefix. Task-number: QTBUG-87580 Task-number: QTBUG-92933 Change-Id: I0841064a60a5ffba5118640d3197527a38ba6c30 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-05-06 14:38:53 +00:00
# TODO: Do we really need this check? We didn't have it in Qt5, and plugin targets
# wrapped in genexes end up causing warnings, but we explicitly use GENEX_EVAL to
# support them.
if(NOT TARGET "${_arg}" AND NOT TARGET "${qt_plugin_with_version}")
Match qt_import_plugin API with qt5's Some work was needed to make the plug-in types, and which plug-ins are available for each type in client code. Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
2019-09-23 14:57:06 +00:00
message("Warning: plug-in ${_arg} is not known to the current Qt installation.")
endif()
endif()
endforeach()
# Handle EXCLUDE_BY_TYPE
foreach(_arg ${arg_EXCLUDE_BY_TYPE})
string(REGEX REPLACE "[-/]" "_" _plugin_type "${_arg}")
set_property(TARGET "${target}" PROPERTY "QT_PLUGINS_${_plugin_type}" "-")
endforeach()
endfunction()
Merge remote-tracking branch 'origin/wip/qt6' into wip/cmake Change-Id: I3a1d7673c3c20019ab12a2ea0a60f1619920a34c
2019-10-11 14:16:29 +00:00
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_import_plugins)
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(QT_DEFAULT_MAJOR_VERSION EQUAL 5)
qt5_import_plugins(${ARGV})
elseif(QT_DEFAULT_MAJOR_VERSION EQUAL 6)
qt6_import_plugins(${ARGV})
CMake: Add support for auto-importing plugins in CMake This commit adds transitive dependencies to the plugins, so that a sane set of default plugins get auto-imported when linking against a module. It also provides a new function, qt5_import_plugins(), which allows you to override the set of plugins that get imported. The decision of whether or not to import a specific plugin is based on several custom target properties and a very clever generator expression. Note that this change only imports plugins on static Qt builds. It does nothing on shared Qt builds, as the shared libraries already have their own plugin import mechanism. [ChangeLog][CMake] Added ability to auto-import non-qml plugins on CMake builds Task-number: QTBUG-38913 Task-number: QTBUG-76562 Change-Id: I2d6c8908b521cf6ba1ebbbc33a87cb7ddd9935cf Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2018-10-17 20:03:28 +00:00
endif()
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
CMake: Remove qt6_enable_object_libraries_finalizer_mode qt6_enable_object_libraries_finalizer_mode is not needed anymore now that static Qt builds require CMake 3.21 and thus CMake takes care of placing object library object files at the beginning of the link line. Rename qt6_enable_import_plugins_finalizer_mode to a more generic qt6_set_finalizer_mode that can enable or disable multiple different modes. For now the only available mode is "static_plugins" which handles the behavior of the old function name. The mode can be enabled by calling qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins") Note that the function is re-tagged as being in Technical Preview. Ideally we would not need it at all. But we need to provide some workaround for the limitations of linking Qt static plugins in CMake on Linux-y platforms that use bfd ld or ld.gold. The workaround does not work well with dependencies wrapped in generator expressions which is why we can't confidently advertise it as a proper solution. Our hope is that this can be fixed in future upstream CMake versions and the function can be removed. See 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 for details. Adjust the tests due to the renamed and removed functions. Amends 19e789bace887105badae83c0a79429bbf8e8221 Amends cdbb390c4a9b8d53cfcfd0884e6720423ce5e126 Amends a25027eecb3829a65543d0e8ab00c74e1b1a21c5 Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Amends a3c430f390b379d874916d4c9ff02af5323af1bd Pick-to: 6.2 Fixes: QTBUG-95169 Task-number: QTBUG-95601 Task-number: QTBUG-95603 Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-05 14:49:42 +00:00
# This function is currently in Technical Preview. It's signature may change or be removed entirely.
function(qt6_set_finalizer_mode target)
cmake_parse_arguments(arg "ENABLE;DISABLE" "" "MODES" ${ARGN})
if(NOT arg_ENABLE AND NOT arg_DISABLE)
message(FATAL_ERROR "No option was specified whether to enable or disable the modes.")
elseif(arg_ENABLE AND arg_DISABLE)
message(FATAL_ERROR "Both ENABLE and DISABLE options were specified.")
endif()
if(NOT arg_MODES)
message(FATAL_ERROR "No modes were specified in qt6_set_finalizer_mode() call.")
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
endif()
CMake: Remove qt6_enable_object_libraries_finalizer_mode qt6_enable_object_libraries_finalizer_mode is not needed anymore now that static Qt builds require CMake 3.21 and thus CMake takes care of placing object library object files at the beginning of the link line. Rename qt6_enable_import_plugins_finalizer_mode to a more generic qt6_set_finalizer_mode that can enable or disable multiple different modes. For now the only available mode is "static_plugins" which handles the behavior of the old function name. The mode can be enabled by calling qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins") Note that the function is re-tagged as being in Technical Preview. Ideally we would not need it at all. But we need to provide some workaround for the limitations of linking Qt static plugins in CMake on Linux-y platforms that use bfd ld or ld.gold. The workaround does not work well with dependencies wrapped in generator expressions which is why we can't confidently advertise it as a proper solution. Our hope is that this can be fixed in future upstream CMake versions and the function can be removed. See 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 for details. Adjust the tests due to the renamed and removed functions. Amends 19e789bace887105badae83c0a79429bbf8e8221 Amends cdbb390c4a9b8d53cfcfd0884e6720423ce5e126 Amends a25027eecb3829a65543d0e8ab00c74e1b1a21c5 Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Amends a3c430f390b379d874916d4c9ff02af5323af1bd Pick-to: 6.2 Fixes: QTBUG-95169 Task-number: QTBUG-95601 Task-number: QTBUG-95603 Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-05 14:49:42 +00:00
if(arg_ENABLE)
set(value "TRUE")
elseif(arg_DISABLE)
set(value "FALSE")
endif()
CMake: Introduce finalizer mode handling of static plugins Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-28 14:27:19 +00:00
CMake: Remove qt6_enable_object_libraries_finalizer_mode qt6_enable_object_libraries_finalizer_mode is not needed anymore now that static Qt builds require CMake 3.21 and thus CMake takes care of placing object library object files at the beginning of the link line. Rename qt6_enable_import_plugins_finalizer_mode to a more generic qt6_set_finalizer_mode that can enable or disable multiple different modes. For now the only available mode is "static_plugins" which handles the behavior of the old function name. The mode can be enabled by calling qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins") Note that the function is re-tagged as being in Technical Preview. Ideally we would not need it at all. But we need to provide some workaround for the limitations of linking Qt static plugins in CMake on Linux-y platforms that use bfd ld or ld.gold. The workaround does not work well with dependencies wrapped in generator expressions which is why we can't confidently advertise it as a proper solution. Our hope is that this can be fixed in future upstream CMake versions and the function can be removed. See 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 for details. Adjust the tests due to the renamed and removed functions. Amends 19e789bace887105badae83c0a79429bbf8e8221 Amends cdbb390c4a9b8d53cfcfd0884e6720423ce5e126 Amends a25027eecb3829a65543d0e8ab00c74e1b1a21c5 Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Amends a3c430f390b379d874916d4c9ff02af5323af1bd Pick-to: 6.2 Fixes: QTBUG-95169 Task-number: QTBUG-95601 Task-number: QTBUG-95603 Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-05 14:49:42 +00:00
foreach(mode ${arg_MODES})
__qt_internal_enable_finalizer_mode("${target}" "${mode}" "${value}")
endforeach()
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 17:46:24 +00:00
endfunction()
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_set_finalizer_mode)
CMake: Remove qt6_enable_object_libraries_finalizer_mode qt6_enable_object_libraries_finalizer_mode is not needed anymore now that static Qt builds require CMake 3.21 and thus CMake takes care of placing object library object files at the beginning of the link line. Rename qt6_enable_import_plugins_finalizer_mode to a more generic qt6_set_finalizer_mode that can enable or disable multiple different modes. For now the only available mode is "static_plugins" which handles the behavior of the old function name. The mode can be enabled by calling qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins") Note that the function is re-tagged as being in Technical Preview. Ideally we would not need it at all. But we need to provide some workaround for the limitations of linking Qt static plugins in CMake on Linux-y platforms that use bfd ld or ld.gold. The workaround does not work well with dependencies wrapped in generator expressions which is why we can't confidently advertise it as a proper solution. Our hope is that this can be fixed in future upstream CMake versions and the function can be removed. See 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 for details. Adjust the tests due to the renamed and removed functions. Amends 19e789bace887105badae83c0a79429bbf8e8221 Amends cdbb390c4a9b8d53cfcfd0884e6720423ce5e126 Amends a25027eecb3829a65543d0e8ab00c74e1b1a21c5 Amends 6fcc272ac9dcf1d6d65de1bdf3138722ba63a902 Amends a3c430f390b379d874916d4c9ff02af5323af1bd Pick-to: 6.2 Fixes: QTBUG-95169 Task-number: QTBUG-95601 Task-number: QTBUG-95603 Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-05 14:49:42 +00:00
qt6_set_finalizer_mode(${ARGV})
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
Implement propagation of object files to the end-point executable This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-19 17:46:24 +00:00
endif()
Generate metatypes dependency file Due to generator expression it is impossible to recursively evaluate the link dependencies of a target. This is required by QtDeclarative's qmltyperegistrar. To overcome this we generate a ${target}_metatypes_dep.txt file which contain lines with the following pattern: ${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt} This can be used to recursively evaluate the dependencies at run time. Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2020-01-27 13:56:40 +00:00
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
function(qt6_extract_metatypes target)
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
get_target_property(existing_meta_types_file ${target} INTERFACE_QT_META_TYPES_BUILD_FILE)
if (existing_meta_types_file)
return()
endif()
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
set(args_option
# TODO: Move this into a separate internal function, so it doesn't pollute the public one.
Add docs for qt_extract_metatypes() Also tidy up the inline TODO comments to reduce duplication and address some minor inconsistencies. Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: Ic0d27f3c0a356fd311bba95de967faaea05e0f0a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-23 07:42:06 +00:00
# When given, metatypes files will be installed into the default Qt
# metatypes folder. Only to be used by the Qt build.
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
__QT_INTERNAL_INSTALL
)
set(args_single
# TODO: Move this into a separate internal function, so it doesn't pollute the public one.
Add docs for qt_extract_metatypes() Also tidy up the inline TODO comments to reduce duplication and address some minor inconsistencies. Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: Ic0d27f3c0a356fd311bba95de967faaea05e0f0a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-23 07:42:06 +00:00
# Location where to install the metatypes file. Only used if
# __QT_INTERNAL_INSTALL is given. It defaults to the
# ${CMAKE_INSTALL_PREFIX}/${INSTALL_LIBDIR}/metatypes directory.
# Executable metatypes files are never installed.
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
__QT_INTERNAL_INSTALL_DIR
OUTPUT_FILES
)
set(args_multi
MANUAL_MOC_JSON_FILES
)
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
cmake_parse_arguments(arg
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
"${args_option}"
"${args_single}"
"${args_multi}" ${ARGN})
Generate metatypes dependency file Due to generator expression it is impossible to recursively evaluate the link dependencies of a target. This is required by QtDeclarative's qmltyperegistrar. To overcome this we generate a ${target}_metatypes_dep.txt file which contain lines with the following pattern: ${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt} This can be used to recursively evaluate the dependencies at run time. Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2020-01-27 13:56:40 +00:00
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
get_target_property(target_type ${target} TYPE)
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
if (target_type STREQUAL "INTERFACE_LIBRARY")
message(FATAL_ERROR "Meta types generation does not work on interface libraries")
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
return()
endif()
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
if (CMAKE_VERSION VERSION_LESS "3.16.0")
message(FATAL_ERROR "Meta types generation requires CMake >= 3.16")
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
return()
endif()
get_target_property(target_binary_dir ${target} BINARY_DIR)
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
set(type_list_file "${target_binary_dir}/meta_types/${target}_json_file_list.txt")
set(type_list_file_manual "${target_binary_dir}/meta_types/${target}_json_file_list_manual.txt")
get_target_property(uses_automoc ${target} AUTOMOC)
set(automoc_args)
set(automoc_dependencies)
CMake: Use default location for installing metatypes json files Previously configuring a standalone example that had no explicit INSTALL_DIR option for qt6_generate_meta_types_json_file would fail. When no explicit location is specified to qt6_generate_meta_types_json_file via INSTALL_DIR option, default to installing into a lib/metatypes location relative to the install prefix. This is required for supporting calling qt6_generate_meta_types_json_file when building standalone applications or libraries (not part of the Qt build). Make sure not to install the metatypes.json file for executables. Install it only for libraries (aka modules). Task-number: QTBUG-84403 Change-Id: Ie0dd75fca0cde71ccb4eb48030871e72d31d1725 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-25 16:52:16 +00:00
# Handle automoc generated data
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
if (uses_automoc)
# Tell automoc to output json files)
set_property(TARGET "${target}" APPEND PROPERTY
AUTOMOC_MOC_OPTIONS "--output-json"
)
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
CMake: Handle single- and multi-config differences more robustly Projects sometimes set both CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE regardless of what CMake generator they are using. They shouldn't, but it is common enough that we should protect against it. The GENERATOR_IS_MULTI_CONFIG global property is the only robust way to know which type of generator we are using, so switch to that for how we detect this. Pick-to: 6.2 Change-Id: If5d6568da0d2adb3275bbaf9a7d3bd3e033dc636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-13 01:05:52 +00:00
get_property(is_multi_config GLOBAL PROPERTY GENERATOR_IS_MULTI_CONFIG)
if(NOT is_multi_config)
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
set(cmake_autogen_cache_file
"${target_binary_dir}/CMakeFiles/${target}_autogen.dir/ParseCache.txt")
CMake: Handle single- and multi-config differences more robustly Projects sometimes set both CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE regardless of what CMake generator they are using. They shouldn't, but it is common enough that we should protect against it. The GENERATOR_IS_MULTI_CONFIG global property is the only robust way to know which type of generator we are using, so switch to that for how we detect this. Pick-to: 6.2 Change-Id: If5d6568da0d2adb3275bbaf9a7d3bd3e033dc636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-13 01:05:52 +00:00
set(multi_config_args
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
--cmake-autogen-include-dir-path "${target_binary_dir}/${target}_autogen/include"
)
else()
set(cmake_autogen_cache_file
"${target_binary_dir}/CMakeFiles/${target}_autogen.dir/ParseCache_$<CONFIG>.txt")
CMake: Handle single- and multi-config differences more robustly Projects sometimes set both CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE regardless of what CMake generator they are using. They shouldn't, but it is common enough that we should protect against it. The GENERATOR_IS_MULTI_CONFIG global property is the only robust way to know which type of generator we are using, so switch to that for how we detect this. Pick-to: 6.2 Change-Id: If5d6568da0d2adb3275bbaf9a7d3bd3e033dc636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-13 01:05:52 +00:00
set(multi_config_args
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
--cmake-autogen-include-dir-path "${target_binary_dir}/${target}_autogen/include_$<CONFIG>"
"--cmake-multi-config")
endif()
set(cmake_autogen_info_file
"${target_binary_dir}/CMakeFiles/${target}_autogen.dir/AutogenInfo.json")
CMake: Depend on automoc timestamp for metatypes extraction When using CMake 3.17 with any of the Ninja generators we can leverage a dependency on the timestamp file produced by CMake's automoc to avoid having a custom target run on every build. Change-Id: Ia70d2730cc8296d0a43642655fe69b555cb393c0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-04 14:58:59 +00:00
set (use_dep_files FALSE)
if (CMAKE_VERSION VERSION_GREATER_EQUAL "3.17") # Requires automoc changes present only in 3.17
if(CMAKE_GENERATOR STREQUAL "Ninja" OR CMAKE_GENERATOR STREQUAL "Ninja Multi-Config")
set(use_dep_files TRUE)
endif()
endif()
Fix dependency chain that collects the metatype json files cmake_automoc_parser has the logic preventing the run of moc with the --collect-json parameter if metatype json files are not changed. This logic only verify if the file list is changed but not their content. This change adds a timestamp file that contains the last metatype json file timestamp that was modified during the last cmake_automoc_parser run. The logic still prevents of running 'moc --collect-json' when the list of metatype json files is not changed, but also checks if their content is no changed. Another approach it to generate the depfile that can be utilized by CMake in add_custom_command as DEPFILE argument. But this concept only works from the second build attempt because of an issue related to dyndep. Pick-to: 6.2 Fixes: QTBUG-98532 Change-Id: I713f8bfa9ae769cefe0beac0b7fa19750b00a765 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-24 15:22:18 +00:00
set(cmake_automoc_parser_timestamp "${type_list_file}.timestamp")
CMake: Depend on automoc timestamp for metatypes extraction When using CMake 3.17 with any of the Ninja generators we can leverage a dependency on the timestamp file produced by CMake's automoc to avoid having a custom target run on every build. Change-Id: Ia70d2730cc8296d0a43642655fe69b555cb393c0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-04 14:58:59 +00:00
if (NOT use_dep_files)
CMake: Fix qt6_extract_metatypes to work with VS Generators CMake has an optimization where it skips creation of a ${target}_autogen target and instead uses PRE_BUILD events for AUTOMOC. That breaks qt6_extract_metatypes which expects the autogen target to always exist. Disable the optimization by generating a dummy header file and adding it as a source to the target. Pick-to: 6.2 Fixes: QTBUG-94944 Change-Id: Ic3d923cc6d3a149fea8c5c7b111576b64d19f608 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-07-02 15:43:58 +00:00
# When a project is configured with a Visual Studio generator, CMake's
# cmQtAutoGenInitializer::InitAutogenTarget() can take one of two code paths on how to
# handle AUTOMOC rules.
# It either creates a ${target}_autogen custom target or uses PRE_BUILD build events.
#
# The latter in considered an optimization and is used by CMake when possible.
# Unfortunately that breaks our add_dependency call because we expect on _autogen target
# to always exist.
#
# Ensure the PRE_BUILD path is not taken by generating a dummy header file and adding it
# as a source file to the target. This causes the file to be added to
# cmQtAutoGenInitializer::AutogenTarget.DependFiles, which disables the PRE_BUILD path.
if(CMAKE_GENERATOR MATCHES "Visual Studio")
# The file name should be target specific, but still short, so we don't hit path
# length issues.
string(MAKE_C_IDENTIFIER "ddf_${target}" dummy_dependency_file)
set(dummy_out_file "${CMAKE_CURRENT_BINARY_DIR}/${dummy_dependency_file}.h")
# The content shouldn't be empty so we don't trigger AUTOMOC warnings about it.
file(GENERATE OUTPUT "${dummy_out_file}" CONTENT "//")
set_source_files_properties("${dummy_out_file}" PROPERTIES
GENERATED TRUE
SKIP_AUTOGEN OFF)
target_sources("${target}" PRIVATE "${dummy_out_file}")
endif()
CMake: Depend on automoc timestamp for metatypes extraction When using CMake 3.17 with any of the Ninja generators we can leverage a dependency on the timestamp file produced by CMake's automoc to avoid having a custom target run on every build. Change-Id: Ia70d2730cc8296d0a43642655fe69b555cb393c0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-04 14:58:59 +00:00
add_custom_target(${target}_automoc_json_extraction
DEPENDS ${QT_CMAKE_EXPORT_NAMESPACE}::cmake_automoc_parser
Fix dependency chain that collects the metatype json files cmake_automoc_parser has the logic preventing the run of moc with the --collect-json parameter if metatype json files are not changed. This logic only verify if the file list is changed but not their content. This change adds a timestamp file that contains the last metatype json file timestamp that was modified during the last cmake_automoc_parser run. The logic still prevents of running 'moc --collect-json' when the list of metatype json files is not changed, but also checks if their content is no changed. Another approach it to generate the depfile that can be utilized by CMake in add_custom_command as DEPFILE argument. But this concept only works from the second build attempt because of an issue related to dyndep. Pick-to: 6.2 Fixes: QTBUG-98532 Change-Id: I713f8bfa9ae769cefe0beac0b7fa19750b00a765 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-24 15:22:18 +00:00
BYPRODUCTS
${type_list_file}
"${cmake_automoc_parser_timestamp}"
CMake: Depend on automoc timestamp for metatypes extraction When using CMake 3.17 with any of the Ninja generators we can leverage a dependency on the timestamp file produced by CMake's automoc to avoid having a custom target run on every build. Change-Id: Ia70d2730cc8296d0a43642655fe69b555cb393c0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-04 14:58:59 +00:00
COMMAND
${QT_CMAKE_EXPORT_NAMESPACE}::cmake_automoc_parser
--cmake-autogen-cache-file "${cmake_autogen_cache_file}"
--cmake-autogen-info-file "${cmake_autogen_info_file}"
--output-file-path "${type_list_file}"
Fix dependency chain that collects the metatype json files cmake_automoc_parser has the logic preventing the run of moc with the --collect-json parameter if metatype json files are not changed. This logic only verify if the file list is changed but not their content. This change adds a timestamp file that contains the last metatype json file timestamp that was modified during the last cmake_automoc_parser run. The logic still prevents of running 'moc --collect-json' when the list of metatype json files is not changed, but also checks if their content is no changed. Another approach it to generate the depfile that can be utilized by CMake in add_custom_command as DEPFILE argument. But this concept only works from the second build attempt because of an issue related to dyndep. Pick-to: 6.2 Fixes: QTBUG-98532 Change-Id: I713f8bfa9ae769cefe0beac0b7fa19750b00a765 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-24 15:22:18 +00:00
--timestamp-file-path "${cmake_automoc_parser_timestamp}"
CMake: Handle single- and multi-config differences more robustly Projects sometimes set both CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE regardless of what CMake generator they are using. They shouldn't, but it is common enough that we should protect against it. The GENERATOR_IS_MULTI_CONFIG global property is the only robust way to know which type of generator we are using, so switch to that for how we detect this. Pick-to: 6.2 Change-Id: If5d6568da0d2adb3275bbaf9a7d3bd3e033dc636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-13 01:05:52 +00:00
${multi_config_args}
CMake: Change some custom commands to mention the target name Pick-to: 6.2 Change-Id: I3a198c87ba2d71306478809095083694b65c7086 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-16 14:58:22 +00:00
COMMENT "Running AUTOMOC file extraction for target ${target}"
CMake: Depend on automoc timestamp for metatypes extraction When using CMake 3.17 with any of the Ninja generators we can leverage a dependency on the timestamp file produced by CMake's automoc to avoid having a custom target run on every build. Change-Id: Ia70d2730cc8296d0a43642655fe69b555cb393c0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-04 14:58:59 +00:00
COMMAND_EXPAND_LISTS
)
add_dependencies(${target}_automoc_json_extraction ${target}_autogen)
else()
set(cmake_autogen_timestamp_file
"${target_binary_dir}/${target}_autogen/timestamp"
)
add_custom_command(OUTPUT ${type_list_file}
DEPENDS ${QT_CMAKE_EXPORT_NAMESPACE}::cmake_automoc_parser
${cmake_autogen_timestamp_file}
Fix dependency chain that collects the metatype json files cmake_automoc_parser has the logic preventing the run of moc with the --collect-json parameter if metatype json files are not changed. This logic only verify if the file list is changed but not their content. This change adds a timestamp file that contains the last metatype json file timestamp that was modified during the last cmake_automoc_parser run. The logic still prevents of running 'moc --collect-json' when the list of metatype json files is not changed, but also checks if their content is no changed. Another approach it to generate the depfile that can be utilized by CMake in add_custom_command as DEPFILE argument. But this concept only works from the second build attempt because of an issue related to dyndep. Pick-to: 6.2 Fixes: QTBUG-98532 Change-Id: I713f8bfa9ae769cefe0beac0b7fa19750b00a765 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-24 15:22:18 +00:00
BYPRODUCTS "${cmake_automoc_parser_timestamp}"
CMake: Depend on automoc timestamp for metatypes extraction When using CMake 3.17 with any of the Ninja generators we can leverage a dependency on the timestamp file produced by CMake's automoc to avoid having a custom target run on every build. Change-Id: Ia70d2730cc8296d0a43642655fe69b555cb393c0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-04 14:58:59 +00:00
COMMAND
${QT_CMAKE_EXPORT_NAMESPACE}::cmake_automoc_parser
--cmake-autogen-cache-file "${cmake_autogen_cache_file}"
--cmake-autogen-info-file "${cmake_autogen_info_file}"
--output-file-path "${type_list_file}"
Fix dependency chain that collects the metatype json files cmake_automoc_parser has the logic preventing the run of moc with the --collect-json parameter if metatype json files are not changed. This logic only verify if the file list is changed but not their content. This change adds a timestamp file that contains the last metatype json file timestamp that was modified during the last cmake_automoc_parser run. The logic still prevents of running 'moc --collect-json' when the list of metatype json files is not changed, but also checks if their content is no changed. Another approach it to generate the depfile that can be utilized by CMake in add_custom_command as DEPFILE argument. But this concept only works from the second build attempt because of an issue related to dyndep. Pick-to: 6.2 Fixes: QTBUG-98532 Change-Id: I713f8bfa9ae769cefe0beac0b7fa19750b00a765 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-24 15:22:18 +00:00
--timestamp-file-path "${cmake_automoc_parser_timestamp}"
CMake: Handle single- and multi-config differences more robustly Projects sometimes set both CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE regardless of what CMake generator they are using. They shouldn't, but it is common enough that we should protect against it. The GENERATOR_IS_MULTI_CONFIG global property is the only robust way to know which type of generator we are using, so switch to that for how we detect this. Pick-to: 6.2 Change-Id: If5d6568da0d2adb3275bbaf9a7d3bd3e033dc636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-13 01:05:52 +00:00
${multi_config_args}
CMake: Change some custom commands to mention the target name Pick-to: 6.2 Change-Id: I3a198c87ba2d71306478809095083694b65c7086 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-16 14:58:22 +00:00
COMMENT "Running AUTOMOC file extraction for target ${target}"
CMake: Depend on automoc timestamp for metatypes extraction When using CMake 3.17 with any of the Ninja generators we can leverage a dependency on the timestamp file produced by CMake's automoc to avoid having a custom target run on every build. Change-Id: Ia70d2730cc8296d0a43642655fe69b555cb393c0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-04 14:58:59 +00:00
COMMAND_EXPAND_LISTS
Add VERBATIM option to add_custom_command calls Use VERBATIM option to prepare the correct command line for the add_custom_command. This especially sensitive when using build directories with names containing special symbols, that cannot be handled by shell correctly. Change-Id: I51d7041cb806411135fd59bf6273c04a3c695443 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-15 16:37:11 +00:00
VERBATIM
CMake: Depend on automoc timestamp for metatypes extraction When using CMake 3.17 with any of the Ninja generators we can leverage a dependency on the timestamp file produced by CMake's automoc to avoid having a custom target run on every build. Change-Id: Ia70d2730cc8296d0a43642655fe69b555cb393c0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-04 14:58:59 +00:00
)
endif()
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
set(automoc_args "@${type_list_file}")
set(automoc_dependencies "${type_list_file}")
endif()
set(manual_args)
set(manual_dependencies)
if(arg_MANUAL_MOC_JSON_FILES)
list(REMOVE_DUPLICATES arg_MANUAL_MOC_JSON_FILES)
file(GENERATE
OUTPUT ${type_list_file_manual}
CONTENT "$<JOIN:$<GENEX_EVAL:${arg_MANUAL_MOC_JSON_FILES}>,\n>"
)
list(APPEND manual_dependencies ${arg_MANUAL_MOC_JSON_FILES} ${type_list_file_manual})
set(manual_args "@${type_list_file_manual}")
endif()
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
if (NOT manual_args AND NOT automoc_args)
message(FATAL_ERROR "Metatype generation requires either the use of AUTOMOC or a manual list of generated json files")
endif()
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
CMake: Handle single- and multi-config differences more robustly Projects sometimes set both CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE regardless of what CMake generator they are using. They shouldn't, but it is common enough that we should protect against it. The GENERATOR_IS_MULTI_CONFIG global property is the only robust way to know which type of generator we are using, so switch to that for how we detect this. Pick-to: 6.2 Change-Id: If5d6568da0d2adb3275bbaf9a7d3bd3e033dc636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-13 01:05:52 +00:00
if (CMAKE_BUILD_TYPE AND NOT is_multi_config)
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
string(TOLOWER ${target}_${CMAKE_BUILD_TYPE} target_lowercase)
else()
Add initial support for CMake "Ninja Multi-Config" generator This allows doing debug_and_release builds with Ninja on all platforms. The "Ninja Multi-Config generator" is available starting with CMake 3.17. Desired configurations can be set via CMAKE_CONFIGURATION_TYPES. Possible values: "Release, Debug, RelWithDebInfo, MinRelSize". For example -DCMAKE_CONFIGURATION_TYPES="Release;Debug". The first configuration is the 'default' configuration which is built when calling ninja with no arguments. To build all targets of a certain configuration use "ninja all:Release" or "ninja all:Debug". To build all targets in all configurations use "ninja all:all". Note that the first configuration influences which configuration of tools will be used when building the libraries for all configurations. In simple terms, when configured with -DCMAKE_CONFIGURATION_TYPES="Release;Debug" the release version of moc is used by AUTOMOC. When configured with -DCMAKE_CONFIGURATION_TYPES="Debug;Release" the debug version of moc is used by AUTOMOC. Framework builds and Ninja Multi-Config don't currently work together due to multiple bugs in CMake, which ends up generating an invalid ninja file with duplicate rules. There are also issues with placement of the debug artifacts. This will be handled in a follow up patch after CMake is fixed. Task-number: QTBUG-76899 Change-Id: If224adc0b71b7d1d6606738101536146aa866cd7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2019-12-06 14:12:17 +00:00
string(TOLOWER ${target} target_lowercase)
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
endif()
Generate metatypes dependency file Due to generator expression it is impossible to recursively evaluate the link dependencies of a target. This is required by QtDeclarative's qmltyperegistrar. To overcome this we generate a ${target}_metatypes_dep.txt file which contain lines with the following pattern: ${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt} This can be used to recursively evaluate the dependencies at run time. Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2020-01-27 13:56:40 +00:00
set(metatypes_file_name "qt6${target_lowercase}_metatypes.json")
set(metatypes_file "${target_binary_dir}/meta_types/${metatypes_file_name}")
Refactor Metatypes dependency propagation Every metatypes.json files is now added as an INTERFACE source file to a target. This enables us later to correctly collect all the metatypes.json files from dependent targets. This information is also correctly exported via export()/install(). To avoid the metatypes.json appearing in every target's source list, the file path is wrapped in a generator expression which will only be evaluated when the consuming target has the property QT_CONSUMES_METATYPES set to true. At the moment this is limited to targets which need to interact with qmltyperegistrar. Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-07 13:12:27 +00:00
set(metatypes_file_gen "${target_binary_dir}/meta_types/${metatypes_file_name}.gen")
Generate metatypes dependency file Due to generator expression it is impossible to recursively evaluate the link dependencies of a target. This is required by QtDeclarative's qmltyperegistrar. To overcome this we generate a ${target}_metatypes_dep.txt file which contain lines with the following pattern: ${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt} This can be used to recursively evaluate the dependencies at run time. Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2020-01-27 13:56:40 +00:00
set(metatypes_dep_file_name "qt6${target_lowercase}_metatypes_dep.txt")
set(metatypes_dep_file "${target_binary_dir}/meta_types/${metatypes_dep_file_name}")
Refactor Metatypes dependency propagation Every metatypes.json files is now added as an INTERFACE source file to a target. This enables us later to correctly collect all the metatypes.json files from dependent targets. This information is also correctly exported via export()/install(). To avoid the metatypes.json appearing in every target's source list, the file path is wrapped in a generator expression which will only be evaluated when the consuming target has the property QT_CONSUMES_METATYPES set to true. At the moment this is limited to targets which need to interact with qmltyperegistrar. Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-07 13:12:27 +00:00
# Due to generated source file dependency rules being tied to the directory
# scope in which they are created it is not possible for other targets which
# are defined in a separate scope to see these rules. This leads to failures
# in locating the generated source files.
# To work around this we write a dummy file to disk to make sure targets
# which link against the current target do not produce the error. This dummy
# file is then replaced with the contents of the generated file during
# build.
if (NOT EXISTS ${metatypes_file})
file(MAKE_DIRECTORY "${target_binary_dir}/meta_types")
file(TOUCH ${metatypes_file})
endif()
CMake: Fix metatype file generation not to happen in the source dir When building qtdeclarative in a non-prefix configuration, metatypes.json files were created in the source dir. This happened because the default arg_INSTALL_DIR value is relative in qt6_generate_meta_types_json_file, and thus a file(TOUCH) with a relative path creats it in the source dir. The fix is to check if it's relative during a non-prefix build, and make it absolute (relative to the install prefix, which is the qtbase build dir). Change-Id: Ie9abbd5d93a64e79184d77655d8d8399e894fde5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
2020-03-20 09:03:59 +00:00
CMake: Fix qt6_extract_metatypes json file generation rule Change the copying of ${CMAKE_CURRENT_BINARY_DIR}/${target}_metatypes.json to ${prefix}/lib/metatypes/${target}_metatypes.json to happen as part of the command generating the file, rather than copying the file as part of a separate custom target or POST_BUILD event. This ensures that the custom commands in qt6_qml_type_registration that use those files as dependencies will cause them to be generated before the qml type registration happens, thus eliminating errors like Error 5 while parsing qtbase/lib/metatypes/qt6quick_metatypes.json: illegal value Pick-to: 6.1 6.2 Fixes: QTBUG-94942 Change-Id: Idddd73786d1a622984965c60ac9b4c3bc2c13ab5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-05 15:37:15 +00:00
add_custom_command(
OUTPUT
${metatypes_file_gen}
${metatypes_file}
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
DEPENDS ${QT_CMAKE_EXPORT_NAMESPACE}::moc ${automoc_dependencies} ${manual_dependencies}
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
COMMAND ${QT_CMAKE_EXPORT_NAMESPACE}::moc
Refactor Metatypes dependency propagation Every metatypes.json files is now added as an INTERFACE source file to a target. This enables us later to correctly collect all the metatypes.json files from dependent targets. This information is also correctly exported via export()/install(). To avoid the metatypes.json appearing in every target's source list, the file path is wrapped in a generator expression which will only be evaluated when the consuming target has the property QT_CONSUMES_METATYPES set to true. At the moment this is limited to targets which need to interact with qmltyperegistrar. Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-07 13:12:27 +00:00
-o ${metatypes_file_gen}
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
--collect-json ${automoc_args} ${manual_args}
Refactor Metatypes dependency propagation Every metatypes.json files is now added as an INTERFACE source file to a target. This enables us later to correctly collect all the metatypes.json files from dependent targets. This information is also correctly exported via export()/install(). To avoid the metatypes.json appearing in every target's source list, the file path is wrapped in a generator expression which will only be evaluated when the consuming target has the property QT_CONSUMES_METATYPES set to true. At the moment this is limited to targets which need to interact with qmltyperegistrar. Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-07 13:12:27 +00:00
COMMAND ${CMAKE_COMMAND} -E copy_if_different
${metatypes_file_gen}
${metatypes_file}
CMake: Change some custom commands to mention the target name Pick-to: 6.2 Change-Id: I3a198c87ba2d71306478809095083694b65c7086 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-16 14:58:22 +00:00
COMMENT "Running moc --collect-json for target ${target}"
Add VERBATIM option to add_custom_command calls Use VERBATIM option to prepare the correct command line for the add_custom_command. This especially sensitive when using build directories with names containing special symbols, that cannot be handled by shell correctly. Change-Id: I51d7041cb806411135fd59bf6273c04a3c695443 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-15 16:37:11 +00:00
VERBATIM
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
)
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
# We can't rely on policy CMP0118 since user project controls it
set(scope_args)
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.18")
set(scope_args TARGET_DIRECTORY ${target})
endif()
set_source_files_properties(${metatypes_file_gen} ${metatypes_file} ${scope_args}
PROPERTIES GENERATED TRUE
)
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
# We still need to add this file as a source of the target, otherwise the file
Refactor Metatypes dependency propagation Every metatypes.json files is now added as an INTERFACE source file to a target. This enables us later to correctly collect all the metatypes.json files from dependent targets. This information is also correctly exported via export()/install(). To avoid the metatypes.json appearing in every target's source list, the file path is wrapped in a generator expression which will only be evaluated when the consuming target has the property QT_CONSUMES_METATYPES set to true. At the moment this is limited to targets which need to interact with qmltyperegistrar. Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-07 13:12:27 +00:00
# rule above is not triggered. INTERFACE_SOURCES do not properly register
# as dependencies to build the current target.
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
# TODO: Can we pass ${metatypes_file} instead of ${metatypes_file_gen} as a source?
# TODO: Do we still need the _gen variant at all?
Refactor Metatypes dependency propagation Every metatypes.json files is now added as an INTERFACE source file to a target. This enables us later to correctly collect all the metatypes.json files from dependent targets. This information is also correctly exported via export()/install(). To avoid the metatypes.json appearing in every target's source list, the file path is wrapped in a generator expression which will only be evaluated when the consuming target has the property QT_CONSUMES_METATYPES set to true. At the moment this is limited to targets which need to interact with qmltyperegistrar. Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-07 13:12:27 +00:00
target_sources(${target} PRIVATE ${metatypes_file_gen})
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
set_source_files_properties(${metatypes_file} ${scope_args}
PROPERTIES HEADER_FILE_ONLY TRUE
)
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
set_target_properties(${target} PROPERTIES
Generate metatypes dependency file Due to generator expression it is impossible to recursively evaluate the link dependencies of a target. This is required by QtDeclarative's qmltyperegistrar. To overcome this we generate a ${target}_metatypes_dep.txt file which contain lines with the following pattern: ${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt} This can be used to recursively evaluate the dependencies at run time. Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2020-01-27 13:56:40 +00:00
INTERFACE_QT_MODULE_HAS_META_TYPES YES
CMake: Use default location for installing metatypes json files Previously configuring a standalone example that had no explicit INSTALL_DIR option for qt6_generate_meta_types_json_file would fail. When no explicit location is specified to qt6_generate_meta_types_json_file via INSTALL_DIR option, default to installing into a lib/metatypes location relative to the install prefix. This is required for supporting calling qt6_generate_meta_types_json_file when building standalone applications or libraries (not part of the Qt build). Make sure not to install the metatypes.json file for executables. Install it only for libraries (aka modules). Task-number: QTBUG-84403 Change-Id: Ie0dd75fca0cde71ccb4eb48030871e72d31d1725 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-25 16:52:16 +00:00
INTERFACE_QT_META_TYPES_BUILD_FILE "${metatypes_file}"
Generate metatypes dependency file Due to generator expression it is impossible to recursively evaluate the link dependencies of a target. This is required by QtDeclarative's qmltyperegistrar. To overcome this we generate a ${target}_metatypes_dep.txt file which contain lines with the following pattern: ${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt} This can be used to recursively evaluate the dependencies at run time. Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2020-01-27 13:56:40 +00:00
)
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
# Set up consumption of files via INTERFACE_SOURCES.
set(consumes_metatypes "$<BOOL:$<TARGET_PROPERTY:QT_CONSUMES_METATYPES>>")
set(metatypes_file_genex_build
"$<BUILD_INTERFACE:$<${consumes_metatypes}:${metatypes_file}>>"
)
target_sources(${target} INTERFACE ${metatypes_file_genex_build})
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
if(arg_OUTPUT_FILES)
Fix cases of output variables not being passed back to calling scope Some versionless wrappers were not passing back output variables to their calling scope. Ensure they always are. Fix qt6_extract_metatypes() to set its output variable in the parent scope (it was previously setting it erroneously in the local scope). Some functions had code paths that would not set output variables. This would allow situations where if the variables had an initial value set by a higher up parent scope, the output variable would still have that value in the caller's scope upon return. That could be misleading, so fix these code paths to explicitly set the output variable to an empty string instead. Task-number: QTBUG-96121 Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: I291775813f025cabdccd4372ac077cdfd3ec090e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-06 01:18:06 +00:00
set(${arg_OUTPUT_FILES} "${metatypes_file}" PARENT_SCOPE)
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
endif()
corelib: Fix typos in source code comments Pick-to: 6.2 Change-Id: Ic78afb67143112468c6f84677ac88f27a74b53aa Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2021-10-09 13:06:03 +00:00
# Check whether the generated json file needs to be installed.
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
# Executable metatypes.json files should not be installed. Qt non-prefix builds should also
# not install the files.
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
set(should_install FALSE)
if(NOT target_type STREQUAL "EXECUTABLE" AND arg___QT_INTERNAL_INSTALL)
set(should_install TRUE)
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
endif()
# Automatically fill default install args when not specified.
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
if(NOT arg___QT_INTERNAL_INSTALL_DIR)
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
# INSTALL_LIBDIR is not set when QtBuildInternals is not loaded (when not doing a Qt build).
# Default to a hardcoded location for user projects.
if(INSTALL_LIBDIR)
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
set(install_dir "${INSTALL_LIBDIR}/metatypes")
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
else()
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
set(install_dir "lib/metatypes")
Allow manually specification of moc.json files for metatype generation qt6_generate_meta_types_json_file() has been extended to allow the generated moc_....cpp.json files to be manually specified. This now enabled the metatype generation to be used without resorting to AUTOMOC. Additionally, Core_qobject declaration order has been temporarily moved as it otherwise does not produce the correct metatypes dependency file for Core. This will be fixed in a follow up patch. Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64 Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-03 15:52:18 +00:00
endif()
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
else()
set(install_dir "${arg___QT_INTERNAL_INSTALL_DIR}")
Generate metatypes dependency file Due to generator expression it is impossible to recursively evaluate the link dependencies of a target. This is required by QtDeclarative's qmltyperegistrar. To overcome this we generate a ${target}_metatypes_dep.txt file which contain lines with the following pattern: ${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt} This can be used to recursively evaluate the dependencies at run time. Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
2020-01-27 13:56:40 +00:00
endif()
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
if(should_install)
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
set(metatypes_file_install_path "${install_dir}/${metatypes_file_name}")
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
set(metatypes_file_install_path_genex "$<INSTALL_PREFIX>/${metatypes_file_install_path}")
set(metatypes_file_genex_install
"$<INSTALL_INTERFACE:$<${consumes_metatypes}:${metatypes_file_install_path_genex}>>"
)
target_sources(${target} INTERFACE ${metatypes_file_genex_install})
CMake: Don't install metatypes files for user projects Installing extracted metatypes json files for user projects was an oversight. We shouldn't install anything on behalf of user projects, but rather give them enough information so they can do it the themselves. Make all the install options of qt6_extract_metatypes internal, change the behavior not to install the files by default, unless __QT_INTERNAL_INSTALL is passed, which is used for the Qt build only. __QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from projects. This is behavior change for existing public API, but it's better to fix this now before 6.2.0 release. Introduce a new OUTPUT_FILES option to allow assigning the extracted metatype file paths into a variable that the project provides. The project can then install the files where they need them. [ChangeLog][CMake] qt6_extract_metatypes does not install metatypes files anymore. Instead the OUTPUT_FILES option can be provided to get the list of extracted files for further processing. Pick-to: 6.2 Task-number: QTBUG-95845 Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
2021-08-18 14:49:11 +00:00
install(FILES "${metatypes_file}" DESTINATION "${install_dir}")
CMake: Clean up and simplify qt6_extract_metatypes implementation Remove copying of json files in non-prefix builds. Previously, this was done to mimic the directory layout of prefix builds in a non-prefix build, but the extra complexity is not worth it. Keeping the files in the build directories of each repo in a non-prefix build should be good enough. As a result, we don't need to distinguish which file path should be passed in INTERFACE_SOURCES. Now we have only 2 paths to consider, the BUILD_INTERFACE one and the INSTALL_PREFIX one, rather than 3 different paths. Move the code that handles installation closer together. Rename the internal COPY_OVER_INSTALL option to ___QT_INTERNAL_NO_INSTALL. We might want to expose it as a public option later, but it depends on whether we will disable default installation for user projects. Remove assignment of some properties that are not used anymore. Amends c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Pick-to: 6.2 Task-number: QTBUG-94942 Change-Id: I3a26d1988987b2ce7c7d01d2311c13b3da3175a8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-12 14:19:31 +00:00
endif()
Collect Json Metatypes from CMake's Automoc This patch adds a new bootstrap tool which will read CMake's AutoGenInfo.json and ParseCache.txt to determine what the current list of json files is that needs to be passed to moc --collect-json option. Right now this is enabled for qt_add_module() with the option GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's CONFIG += metatypes and to generate the above option for modules. The implementation lives in Qt6CoreMacros so it can eventually be used in the public facing apis. The generated meta types file is saved under the target property QT_MODULE_META_TYPES_FILE. Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2019-11-26 09:10:55 +00:00
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_extract_metatypes)
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
qt6_extract_metatypes(${ARGV})
Fix cases of output variables not being passed back to calling scope Some versionless wrappers were not passing back output variables to their calling scope. Ensure they always are. Fix qt6_extract_metatypes() to set its output variable in the parent scope (it was previously setting it erroneously in the local scope). Some functions had code paths that would not set output variables. This would allow situations where if the variables had an initial value set by a higher up parent scope, the output variable would still have that value in the caller's scope upon return. That could be misleading, so fix these code paths to explicitly set the output variable to an empty string instead. Task-number: QTBUG-96121 Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: I291775813f025cabdccd4372ac077cdfd3ec090e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-06 01:18:06 +00:00
cmake_parse_arguments(PARSE_ARGV 0 arg "" "OUTPUT_FILES" "")
if(arg_OUTPUT_FILES)
set(${arg_OUTPUT_FILES} "${${arg_OUTPUT_FILES}}" PARENT_SCOPE)
endif()
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
CMake: Add Qt 5 backward compatible CMake API Create versionless function names, that coincide with the Qt 5 CMake API. Task-number: QTBUG-74137 Task-number: QTBUG-80477 Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-12-05 12:52:33 +00:00
endif()
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
# Generate Win32 RC files for a target. All entries in the RC file are generated
CMake: Fix Windows RC file generation for multi-config builds For Ninja Multi-Config we now generate RC files in a path matching the current config name. We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682 to add the generated config-dependent RC files to the target. But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the OriginalFilename entry in the generated resource will be wrong for all configurations but the main one. Cross fingers that this will be fixed upstream. In the meantime: ignore the issue. Drive-by changes: - Fix the function comment. - Surround the RC file name by double quotes in case there are spaces in the path. Fixes: QTBUG-83986 Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 19:55:40 +00:00
# from target properties:
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
#
# QT_TARGET_COMPANY_NAME: RC Company name
# QT_TARGET_DESCRIPTION: RC File Description
# QT_TARGET_VERSION: RC File and Product Version
# QT_TARGET_COPYRIGHT: RC LegalCopyright
# QT_TARGET_PRODUCT_NAME: RC ProductName
CMake: Add more entries for rc files As what we did for QMake. Amends commit 317383217baa280b7e7401a5adc4ce976320e272 Change-Id: Iab3b755193b5483362896da20a03fe2d59f37192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-11 15:04:21 +00:00
# QT_TARGET_COMMENTS: RC Comments
# QT_TARGET_ORIGINAL_FILENAME: RC Original FileName
# QT_TARGET_TRADEMARKS: RC LegalTrademarks
# QT_TARGET_INTERNALNAME: RC InternalName
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
# QT_TARGET_RC_ICONS: List of paths to icon files
#
CMake: Fix Windows RC file generation for multi-config builds For Ninja Multi-Config we now generate RC files in a path matching the current config name. We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682 to add the generated config-dependent RC files to the target. But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the OriginalFilename entry in the generated resource will be wrong for all configurations but the main one. Cross fingers that this will be fixed upstream. In the meantime: ignore the issue. Drive-by changes: - Fix the function comment. - Surround the RC file name by double quotes in case there are spaces in the path. Fixes: QTBUG-83986 Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 19:55:40 +00:00
# If you do not wish to auto-generate rc files, it's possible to provide your
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
# own RC file by setting the property QT_TARGET_WINDOWS_RC_FILE with a path to
# an existing rc file.
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
function(_qt_internal_generate_win32_rc_file target)
CMake: Do not generate RC files for STATIC and OBJECT libraries Those library types typically do not have Windows resources with version information. Change-Id: I1a385c2ae4e40d5c153ac6501c5ed826eaf75655 Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-06 05:54:37 +00:00
set(prohibited_target_types INTERFACE_LIBRARY STATIC_LIBRARY OBJECT_LIBRARY)
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
get_target_property(target_type ${target} TYPE)
CMake: Do not generate RC files for STATIC and OBJECT libraries Those library types typically do not have Windows resources with version information. Change-Id: I1a385c2ae4e40d5c153ac6501c5ed826eaf75655 Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-06 05:54:37 +00:00
if(target_type IN_LIST prohibited_target_types)
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
return()
endif()
get_target_property(target_binary_dir ${target} BINARY_DIR)
get_target_property(target_rc_file ${target} QT_TARGET_WINDOWS_RC_FILE)
get_target_property(target_version ${target} QT_TARGET_VERSION)
if (NOT target_rc_file AND NOT target_version)
return()
endif()
Suppress rc.exe default output Hide output like Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384 Copyright (C) Microsoft Corporation. All rights reserved. when building the auto-generated .rc files. Pick-to: 6.2 Fixes: QTBUG-97729 Change-Id: Id0c32c8015ec2ac0b47b3add52d5c0f8a7a1c203 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-25 11:23:47 +00:00
if(MSVC)
set(extra_rc_flags "/nologo")
else()
set(extra_rc_flags)
endif()
CMake: Fix Windows RC file generation for multi-config builds For Ninja Multi-Config we now generate RC files in a path matching the current config name. We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682 to add the generated config-dependent RC files to the target. But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the OriginalFilename entry in the generated resource will be wrong for all configurations but the main one. Cross fingers that this will be fixed upstream. In the meantime: ignore the issue. Drive-by changes: - Fix the function comment. - Surround the RC file name by double quotes in case there are spaces in the path. Fixes: QTBUG-83986 Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 19:55:40 +00:00
if (target_rc_file)
# Use the provided RC file
target_sources(${target} PRIVATE "${target_rc_file}")
Suppress rc.exe default output Hide output like Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384 Copyright (C) Microsoft Corporation. All rights reserved. when building the auto-generated .rc files. Pick-to: 6.2 Fixes: QTBUG-97729 Change-Id: Id0c32c8015ec2ac0b47b3add52d5c0f8a7a1c203 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-25 11:23:47 +00:00
set_property(SOURCE ${target_rc_file} PROPERTY COMPILE_FLAGS "${extra_rc_flags}")
CMake: Fix Windows RC file generation for multi-config builds For Ninja Multi-Config we now generate RC files in a path matching the current config name. We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682 to add the generated config-dependent RC files to the target. But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the OriginalFilename entry in the generated resource will be wrong for all configurations but the main one. Cross fingers that this will be fixed upstream. In the meantime: ignore the issue. Drive-by changes: - Fix the function comment. - Surround the RC file name by double quotes in case there are spaces in the path. Fixes: QTBUG-83986 Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 19:55:40 +00:00
else()
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
# Generate RC File
CMake: Fix Windows RC file generation for multi-config builds For Ninja Multi-Config we now generate RC files in a path matching the current config name. We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682 to add the generated config-dependent RC files to the target. But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the OriginalFilename entry in the generated resource will be wrong for all configurations but the main one. Cross fingers that this will be fixed upstream. In the meantime: ignore the issue. Drive-by changes: - Fix the function comment. - Surround the RC file name by double quotes in case there are spaces in the path. Fixes: QTBUG-83986 Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 19:55:40 +00:00
set(rc_file_output "${target_binary_dir}/")
if(QT_GENERATOR_IS_MULTI_CONFIG)
string(APPEND rc_file_output "$<CONFIG>/")
endif()
string(APPEND rc_file_output "${target}_resource.rc")
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
set(target_rc_file "${rc_file_output}")
set(company_name "")
get_target_property(target_company_name ${target} QT_TARGET_COMPANY_NAME)
if (target_company_name)
set(company_name "${target_company_name}")
endif()
set(file_description "")
get_target_property(target_description ${target} QT_TARGET_DESCRIPTION)
if (target_description)
set(file_description "${target_description}")
endif()
set(legal_copyright "")
get_target_property(target_copyright ${target} QT_TARGET_COPYRIGHT)
if (target_copyright)
set(legal_copyright "${target_copyright}")
endif()
set(product_name "")
get_target_property(target_product_name ${target} QT_TARGET_PRODUCT_NAME)
if (target_product_name)
set(product_name "${target_product_name}")
else()
set(product_name "${target}")
endif()
CMake: Add more entries for rc files As what we did for QMake. Amends commit 317383217baa280b7e7401a5adc4ce976320e272 Change-Id: Iab3b755193b5483362896da20a03fe2d59f37192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-11 15:04:21 +00:00
set(comments "")
get_target_property(target_comments ${target} QT_TARGET_COMMENTS)
if (target_comments)
set(comments "${target_comments}")
endif()
set(legal_trademarks "")
get_target_property(target_trademarks ${target} QT_TARGET_TRADEMARKS)
if (target_trademarks)
set(legal_trademarks "${target_trademarks}")
endif()
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
set(product_version "")
if (target_version)
if(target_version MATCHES "[0-9]+\\.[0-9]+\\.[0-9]+\\.[0-9]+")
# nothing to do
elseif(target_version MATCHES "[0-9]+\\.[0-9]+\\.[0-9]+")
set(target_version "${target_version}.0")
elseif(target_version MATCHES "[0-9]+\\.[0-9]+")
set(target_version "${target_version}.0.0")
elseif (target_version MATCHES "[0-9]+")
set(target_version "${target_version}.0.0.0")
else()
CMake: Introduce qt_internal_add_app This new function is meant to be used where load(qt_app) is used. It delegates functionality to qt_add_executable, while handling some additional behavior via a finalization function (mostly handling of macOS Info.plist files and icons, as well as Windows icons and resource files) It uses a new PlatformAppInternal interface target. Task-number: QTBUG-85757 Change-Id: I1a2d5851b137fcd4a6323e0e06fb154f91619800 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-07-27 08:17:04 +00:00
message(FATAL_ERROR "Invalid version format: '${target_version}'")
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
endif()
set(product_version "${target_version}")
else()
set(product_version "0.0.0.0")
endif()
set(file_version "${product_version}")
string(REPLACE "." "," version_comma ${product_version})
CMake: Add more entries for rc files As what we did for QMake. Amends commit 317383217baa280b7e7401a5adc4ce976320e272 Change-Id: Iab3b755193b5483362896da20a03fe2d59f37192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-11 15:04:21 +00:00
set(original_file_name "$<TARGET_FILE_NAME:${target}>")
get_target_property(target_original_file_name ${target} QT_TARGET_ORIGINAL_FILENAME)
if (target_original_file_name)
set(original_file_name "${target_original_file_name}")
endif()
set(internal_name "")
get_target_property(target_internal_name ${target} QT_TARGET_INTERNALNAME)
if (target_internal_name)
set(internal_name "${target_internal_name}")
endif()
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
set(icons "")
get_target_property(target_icons ${target} QT_TARGET_RC_ICONS)
if (target_icons)
set(index 1)
foreach( icon IN LISTS target_icons)
qmake: Remove the DISCARDABLE flag for icon resources According to [1] the DISCARDABLE attribute is for 16-bit Windows, and it is ignored. We can drop it. [1] https://docs.microsoft.com/en-us/windows/win32/menurc/common-resource-attributes Change-Id: I70e5b0441a9d20f6c76c3d7a84947f8bce5c8fbd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-11 13:49:28 +00:00
string(APPEND icons "IDI_ICON${index} ICON \"${icon}\"\n")
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
math(EXPR index "${index} +1")
endforeach()
endif()
CMake: Use correct file type Change-Id: Ie32a32bd1cc3e5885a6699e8ea2281982527e50e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-12 02:25:35 +00:00
set(target_file_type "VFT_DLL")
if(target_type STREQUAL "EXECUTABLE")
set(target_file_type "VFT_APP")
endif()
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
set(contents "#include <windows.h>
CMake: Fix icons in generated RC file Change-Id: Idb11bd2058f2ec3f258845aea0d314430ff7c578 Reviewed-by: Simon Hausmann <hausmann@gmail.com> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-06 05:56:45 +00:00
${icons}
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
VS_VERSION_INFO VERSIONINFO
FILEVERSION ${version_comma}
PRODUCTVERSION ${version_comma}
FILEFLAGSMASK 0x3fL
#ifdef _DEBUG
FILEFLAGS VS_FF_DEBUG
#else
FILEFLAGS 0x0L
#endif
qmake: Update the macro names I generated a rc file using VS2019 and I found that it's using other macros. According to [1], both of VOS_NT_WINDOWS32 and VOS__WINDOWS32 refers to "File was designed for 32-bit Windows", although they have different values, and 0x0L is the value of VFT2_UNKNOWN. So I think it's safe to update them. VS2019 is using them as the default template for rc files, after all. [1] https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource Change-Id: Ibaf91394668844492f1357da05b881b9d81aa15f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 08:51:01 +00:00
FILEOS VOS_NT_WINDOWS32
CMake: Use correct file type Change-Id: Ie32a32bd1cc3e5885a6699e8ea2281982527e50e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-12 02:25:35 +00:00
FILETYPE ${target_file_type}
qmake: Update the macro names I generated a rc file using VS2019 and I found that it's using other macros. According to [1], both of VOS_NT_WINDOWS32 and VOS__WINDOWS32 refers to "File was designed for 32-bit Windows", although they have different values, and 0x0L is the value of VFT2_UNKNOWN. So I think it's safe to update them. VS2019 is using them as the default template for rc files, after all. [1] https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource Change-Id: Ibaf91394668844492f1357da05b881b9d81aa15f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 08:51:01 +00:00
FILESUBTYPE VFT2_UNKNOWN
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
BEGIN
BLOCK \"StringFileInfo\"
BEGIN
BLOCK \"040904b0\"
BEGIN
VALUE \"CompanyName\", \"${company_name}\"
VALUE \"FileDescription\", \"${file_description}\"
VALUE \"FileVersion\", \"${file_version}\"
VALUE \"LegalCopyright\", \"${legal_copyright}\"
VALUE \"OriginalFilename\", \"${original_file_name}\"
VALUE \"ProductName\", \"${product_name}\"
VALUE \"ProductVersion\", \"${product_version}\"
CMake: Add more entries for rc files As what we did for QMake. Amends commit 317383217baa280b7e7401a5adc4ce976320e272 Change-Id: Iab3b755193b5483362896da20a03fe2d59f37192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-11 15:04:21 +00:00
VALUE \"Comments\", \"${comments}\"
VALUE \"LegalTrademarks\", \"${legal_trademarks}\"
VALUE \"InternalName\", \"${internal_name}\"
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
END
END
BLOCK \"VarFileInfo\"
BEGIN
VALUE \"Translation\", 0x0409, 1200
END
END
/* End of Version info */\n"
)
# We can't use the output of file generate as source so we work around
# this by generating the file under a different name and then copying
# the file in place using add custom command.
file(GENERATE OUTPUT "${rc_file_output}.tmp"
CONTENT "${contents}"
)
CMake: Fix Windows RC file generation for multi-config builds For Ninja Multi-Config we now generate RC files in a path matching the current config name. We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682 to add the generated config-dependent RC files to the target. But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the OriginalFilename entry in the generated resource will be wrong for all configurations but the main one. Cross fingers that this will be fixed upstream. In the meantime: ignore the issue. Drive-by changes: - Fix the function comment. - Surround the RC file name by double quotes in case there are spaces in the path. Fixes: QTBUG-83986 Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 19:55:40 +00:00
if(QT_GENERATOR_IS_MULTI_CONFIG)
set(cfgs ${CMAKE_CONFIGURATION_TYPES})
set(outputs "")
foreach(cfg ${cfgs})
string(REPLACE "$<CONFIG>" "${cfg}" expanded_rc_file_output "${rc_file_output}")
list(APPEND outputs "${expanded_rc_file_output}")
endforeach()
else()
set(cfgs "${CMAKE_BUILD_TYPE}")
set(outputs "${rc_file_output}")
endif()
CMake: Fix missing resources in Windows debug DLLs/EXEs When configuring a Windows build with NMC and "CMAKE_CONFIGURATION_TYPES=Release;Debug", then with CMake 3.18.4 only the targets of the main configuration would get the version resource compiled in. With 3.19.0 RC 2 the problem cannot be observed. Work-around the issue by revisiting our work-around of another CMake issue: use just one object library per target to embed win32 resources. This works with both tested CMake versions and seems cleaner anyways. Fixes: QTBUG-88267 Change-Id: I20f596ab669ae716c330d7aa60aa717b9e3e4aa7 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 11:50:21 +00:00
# We would like to do the following:
# target_sources(${target} PRIVATE "$<$<CONFIG:${cfg}>:${output}>")
CMake: Fix Windows -debug-and-release builds with CMake 3.21.0 CMake 3.21.0 introduced a regression where per-config sources can't be specified for object libs when building Qt with Ninja Multi-Config and cross-config mode on. We hit that in our Windows resource compiler handling. To work around the issue, pass the config-specific sources directly to the target rather than via an object library, when using CMake 3.20 or later. The original issue of not being able to do that has been fixed in 3.20. Amends ba6175eb731927f2489cdd7d899616a9889aba67 Amends a1ccedeb440216dce87fad01746935a89fd8715e Amends 657fa0462d552110e2ba14bcac46275e6066993f Pick-to: 6.2 Fixes: QTBUG-95229 Change-Id: Idea6d5bcc54b3124c66c45538c2e06e92f288f5f Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-07-16 16:22:35 +00:00
#
# However, https://gitlab.kitware.com/cmake/cmake/-/issues/20682 doesn't let us do that
# in CMake 3.19 and earlier.
# We can do it in CMake 3.20 and later.
# And we have to do it with CMake 3.21.0 to avoid a different issue
# https://gitlab.kitware.com/cmake/cmake/-/issues/22436
#
# So use the object lib work around for <= 3.19 and target_sources directly for later
# versions.
set(use_obj_lib FALSE)
set(end_target "${target}")
if(CMAKE_VERSION VERSION_LESS 3.20)
set(use_obj_lib TRUE)
set(end_target "${target}_rc")
add_library(${target}_rc OBJECT "${output}")
target_link_libraries(${target} PRIVATE $<TARGET_OBJECTS:${target}_rc>)
endif()
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
set(scope_args)
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.18")
set(scope_args TARGET_DIRECTORY ${end_target})
endif()
CMake: Fix Windows RC file generation for multi-config builds For Ninja Multi-Config we now generate RC files in a path matching the current config name. We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682 to add the generated config-dependent RC files to the target. But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the OriginalFilename entry in the generated resource will be wrong for all configurations but the main one. Cross fingers that this will be fixed upstream. In the meantime: ignore the issue. Drive-by changes: - Fix the function comment. - Surround the RC file name by double quotes in case there are spaces in the path. Fixes: QTBUG-83986 Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 19:55:40 +00:00
while(outputs)
list(POP_FRONT cfgs cfg)
list(POP_FRONT outputs output)
set(input "${output}.tmp")
add_custom_command(OUTPUT "${output}"
DEPENDS "${input}"
COMMAND ${CMAKE_COMMAND} -E copy_if_different "${input}" "${output}"
Add VERBATIM option to add_custom_command calls Use VERBATIM option to prepare the correct command line for the add_custom_command. This especially sensitive when using build directories with names containing special symbols, that cannot be handled by shell correctly. Change-Id: I51d7041cb806411135fd59bf6273c04a3c695443 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-15 16:37:11 +00:00
VERBATIM
CMake: Fix Windows RC file generation for multi-config builds For Ninja Multi-Config we now generate RC files in a path matching the current config name. We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682 to add the generated config-dependent RC files to the target. But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the OriginalFilename entry in the generated resource will be wrong for all configurations but the main one. Cross fingers that this will be fixed upstream. In the meantime: ignore the issue. Drive-by changes: - Fix the function comment. - Surround the RC file name by double quotes in case there are spaces in the path. Fixes: QTBUG-83986 Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 19:55:40 +00:00
)
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
# We can't rely on policy CMP0118 since user project controls it
Suppress rc.exe default output Hide output like Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384 Copyright (C) Microsoft Corporation. All rights reserved. when building the auto-generated .rc files. Pick-to: 6.2 Fixes: QTBUG-97729 Change-Id: Id0c32c8015ec2ac0b47b3add52d5c0f8a7a1c203 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-10-25 11:23:47 +00:00
set_source_files_properties(${output} ${scope_args} PROPERTIES
GENERATED TRUE
COMPILE_FLAGS "${extra_rc_flags}"
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
)
CMake: Fix Windows -debug-and-release builds with CMake 3.21.0 CMake 3.21.0 introduced a regression where per-config sources can't be specified for object libs when building Qt with Ninja Multi-Config and cross-config mode on. We hit that in our Windows resource compiler handling. To work around the issue, pass the config-specific sources directly to the target rather than via an object library, when using CMake 3.20 or later. The original issue of not being able to do that has been fixed in 3.20. Amends ba6175eb731927f2489cdd7d899616a9889aba67 Amends a1ccedeb440216dce87fad01746935a89fd8715e Amends 657fa0462d552110e2ba14bcac46275e6066993f Pick-to: 6.2 Fixes: QTBUG-95229 Change-Id: Idea6d5bcc54b3124c66c45538c2e06e92f288f5f Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-07-16 16:22:35 +00:00
target_sources(${end_target} PRIVATE "$<$<CONFIG:${cfg}>:${output}>")
CMake: Fix Windows RC file generation for multi-config builds For Ninja Multi-Config we now generate RC files in a path matching the current config name. We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682 to add the generated config-dependent RC files to the target. But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the OriginalFilename entry in the generated resource will be wrong for all configurations but the main one. Cross fingers that this will be fixed upstream. In the meantime: ignore the issue. Drive-by changes: - Fix the function comment. - Surround the RC file name by double quotes in case there are spaces in the path. Fixes: QTBUG-83986 Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-05-04 19:55:40 +00:00
endwhile()
endif()
CMake: Generate Win32 Resource Files Add support to generate win32 resources files through CMake. The functionality is implemented via qt6_generate_win32_rc_file() in Qt6CoreMacros.cmake. Currently qt_add_test(), qt_add_module() and add_qt_gui_executable() call the above function when building on windows. The function itself has been written as part of the public API so it can be called from other locations if required. Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 15:32:13 +00:00
endfunction()
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
function(__qt_get_relative_resource_path_for_file output_alias file)
get_property(alias SOURCE ${file} PROPERTY QT_RESOURCE_ALIAS)
if (NOT alias)
set(alias "${file}")
endif()
set(${output_alias} ${alias} PARENT_SCOPE)
endfunction()
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
# Performs linking and propagation of the specified objects via the target's usage requirements.
# The objects may be given as generator expression.
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
#
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
# Arguments:
# EXTRA_CONDITIONS
# Conditions to be checked before linking the object files to the end-point executable.
# EXTRA_TARGET_LINK_LIBRARIES_CONDITIONS
# Conditions for the target_link_libraries call.
# EXTRA_TARGET_SOURCES_CONDITIONS
# Conditions for the target_sources call.
function(__qt_internal_propagate_object_files target objects)
set(options "")
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
set(single_args "")
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
set(extra_conditions_args
EXTRA_CONDITIONS
EXTRA_TARGET_LINK_LIBRARIES_CONDITIONS
EXTRA_TARGET_SOURCES_CONDITIONS
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
)
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
set(multi_args ${extra_conditions_args})
cmake_parse_arguments(arg "${options}" "${single_args}" "${multi_args}" ${ARGN})
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
# Collect additional conditions.
foreach(arg IN LISTS extra_conditions_args)
string(TOLOWER "${arg}" lcvar)
if(arg_${arg})
list(JOIN arg_${arg} "," ${lcvar})
else()
set(${lcvar} "$<BOOL:TRUE>")
endif()
endforeach()
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
# Do not litter the static libraries
set(not_static_condition
"$<NOT:$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>>"
)
# Check if link order matters for the Platform.
set(platform_link_order_property
"$<TARGET_PROPERTY:${QT_CMAKE_EXPORT_NAMESPACE}::Platform,_qt_link_order_matters>"
)
set(platform_link_order_condition
"$<BOOL:${platform_link_order_property}>"
)
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 16:00:39 +00:00
# Check if link options are propagated according to CMP0099
# In user builds the _qt_cmp0099_policy_check is set to FALSE or $<TARGET_POLICY:CMP0099>
# depending on the used CMake version.
# See __qt_internal_check_cmp0099_available for details.
set(cmp0099_policy_check_property
"$<TARGET_PROPERTY:${QT_CMAKE_EXPORT_NAMESPACE}::Platform,_qt_cmp0099_policy_check>"
)
set(link_objects_using_link_options_condition
"$<BOOL:$<GENEX_EVAL:${cmp0099_policy_check_property}>>"
)
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
# Collect link conditions for the target_sources call.
string(JOIN "" target_sources_genex
"$<"
"$<AND:"
"${not_static_condition},"
"${platform_link_order_condition},"
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 16:00:39 +00:00
"$<NOT:${link_objects_using_link_options_condition}>,"
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
"${extra_target_sources_conditions},"
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
"${extra_conditions}"
">"
":${objects}>"
)
target_sources(${target} INTERFACE
"${target_sources_genex}"
)
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 16:00:39 +00:00
# Collect link conditions for the target_link_options call.
string(JOIN "" target_link_options_genex
"$<"
"$<AND:"
"${not_static_condition},"
"${platform_link_order_condition},"
"${link_objects_using_link_options_condition},"
"${extra_conditions}"
">"
":${objects}>"
)
# target_link_options works well since CMake 3.17 which has policy CMP0099 set to NEW for the
corelib: Fix typos in source code comments Pick-to: 6.2 Change-Id: Ic78afb67143112468c6f84677ac88f27a74b53aa Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
2021-10-09 13:06:03 +00:00
# minimum required CMake version greater than or equal to 3.17. The default is OLD. See
Use target_link_options to propagate object libraries target_link_options are placed by CMake at the beginning of a linker line. This gives us an opportunity to use the function to propagate object libraries. This change adds one more check in the root Config.cmake file. If CMP0099 policy is enabled, CMake enables propagating of the linking options when linking two static libraries using the PRIVATE linking visibility, so we can rely on the correct linking order and expect object libraries to be propagated. Note that on the platforms where cmake version is higher than 3.16 Qt uses CMP0099 NEW in functions like qt_add_executable. This means that at the moment of creating an executable target the TARGET_POLICY genex will also be NEW, so we do not take into the account the user defined CMP0099. If the CMP0099 policy is not available for a certain CMake version we skip the TARGET_POLICY check and simply disable propagation of the object libraries using target_link_options for both user and Qt libraries. This is applicable for the CMake versions 3.16 and less. Linking approaches have the following priorities(from higher to lower) after this change: - target_link_libraries - works if link order matters not or CMake version greater equal 3.21. - target_link_options - works if CMP0099 is set to NEW by user or if the CMake version is greater than or equal to 3.17 and an executable is created using Qt functions. - object library finalizer - works if CMake version is greater equal 3.19 or qt6_finalize_target is called explicitly. - target_sources - is used when all the other approaches could not be used. Amends a1fd4f51ada82854f35654158a334454e760a9f7 Amends 3329212815777e33dfb4697b748d10927d73f44c Pick-to: 6.2 Change-Id: I14f88caeb04e357191c840abeab89b03e210b796 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-29 16:00:39 +00:00
# https://cmake.org/cmake/help/git-master/policy/CMP0099.html for details.
# This provides yet another way of linking object libraries if user sets the policy to NEW
# before calling find_package(Qt...).
target_link_options(${target} INTERFACE
"${target_link_options_genex}"
)
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
# Collect link conditions for the target_link_libraries call.
string(JOIN "" target_link_libraries_genex
"$<"
"$<AND:"
"${not_static_condition},"
"$<NOT:${platform_link_order_condition}>,"
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
"${extra_target_link_libraries_conditions},"
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
"${extra_conditions}"
">"
":${objects}>"
)
target_link_libraries(${target} INTERFACE
"${target_link_libraries_genex}"
)
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
endfunction()
# Performs linking and propagation of the object library via the target's usage requirements.
# Arguments:
# NO_LINK_OBJECT_LIBRARY_REQUIREMENTS_TO_TARGET skip linking of ${object_library} to ${target}, only
# propagate $<TARGET_OBJECTS:${object_library}> by linking it to ${target}. It's useful in case
# if ${object_library} depends on the ${target}. E.g. resource libraries depend on the Core
# library so linking them back to Core will cause a CMake error.
#
# EXTRA_CONDITIONS object library specific conditions to be checked before link the object library
# to the end-point executable.
function(__qt_internal_propagate_object_library target object_library)
set(options NO_LINK_OBJECT_LIBRARY_REQUIREMENTS_TO_TARGET)
set(single_args "")
set(multi_args EXTRA_CONDITIONS)
cmake_parse_arguments(arg "${options}" "${single_args}" "${multi_args}" ${ARGN})
get_target_property(is_imported ${object_library} IMPORTED)
if(NOT is_imported)
target_link_libraries(${object_library} PRIVATE ${QT_CMAKE_EXPORT_NAMESPACE}::Platform)
_qt_internal_copy_dependency_properties(${object_library} ${target} PRIVATE_ONLY)
endif()
# After internal discussion we decided to not rely on the linker order that CMake
# offers, until CMake provides the guaranteed linking order that suites our needs in a
# future CMake version.
# All object libraries mark themselves with the _is_qt_propagated_object_library property.
# Using a finalizer approach we walk through the target dependencies and look for libraries
# using the _is_qt_propagated_object_library property. Then, objects of the collected libraries
# are moved to the beginning of the linker line using target_sources.
#
# Note: target_link_libraries works well with linkers other than ld. If user didn't enforce
# a finalizer we rely on linker to resolve circular dependencies between objects and static
# libraries.
set_property(TARGET ${object_library} PROPERTY _is_qt_propagated_object_library TRUE)
if(NOT is_imported)
set_property(TARGET ${object_library} APPEND PROPERTY
EXPORT_PROPERTIES _is_qt_propagated_object_library
)
endif()
# Keep the implicit linking if finalizers are not used.
set(not_finalizer_mode_condition
"$<NOT:$<BOOL:$<TARGET_PROPERTY:_qt_object_libraries_finalizer_mode>>>"
)
# Use TARGET_NAME to have the correct namespaced name in the exports.
set(objects "$<TARGET_OBJECTS:$<TARGET_NAME:${object_library}>>")
__qt_internal_propagate_object_files(${target} ${objects}
EXTRA_CONDITIONS ${arg_EXTRA_CONDITIONS}
EXTRA_TARGET_SOURCES_CONDITIONS ${not_finalizer_mode_condition}
EXTRA_TARGET_LINK_LIBRARIES_CONDITIONS ${not_finalizer_mode_condition}
)
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
if(NOT arg_NO_LINK_OBJECT_LIBRARY_REQUIREMENTS_TO_TARGET)
# It's necessary to link the object library target, since we want to pass the object library
# dependencies to the 'target'. Interface linking doesn't add the objects of the library to
# the end-point linker line but propagates all the dependencies of the object_library added
# before or AFTER the line below.
target_link_libraries(${target} INTERFACE ${object_library})
endif()
endfunction()
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
function(__qt_propagate_generated_resource target resource_name generated_source_code output_generated_target)
get_target_property(type ${target} TYPE)
if(type STREQUAL STATIC_LIBRARY)
CMake: Improve long paths handling for static builds Use number-based naming of object libraries produced for generated resources. This reduces path length of subdirectories for object library targets. Amends 08eb485a006dc2baca42eb280ae60e9f0fc00dff Pick-to: 6.0 Change-Id: I1a449290e8a9b969601a1cc1abc6fdcfc0cd9454 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-26 16:13:49 +00:00
get_target_property(resource_count ${target} _qt_generated_resource_target_count)
if(NOT resource_count)
set(resource_count "0")
endif()
math(EXPR resource_count "${resource_count} + 1")
set_target_properties(${target} PROPERTIES _qt_generated_resource_target_count ${resource_count})
set(resource_target "${target}_resources_${resource_count}")
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
add_library("${resource_target}" OBJECT "${generated_source_code}")
Add missing compile definitions to the resource object library The resource object library must be compiled with the definitions specified in Qt::Core. Missing the required definitions causes linker problems when QT_NAMESPACE is defined. Change-Id: If0ca20604e251822279e0d4906c47b94d3b4ceb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-29 14:46:19 +00:00
target_compile_definitions("${resource_target}" PRIVATE
"$<TARGET_PROPERTY:${QT_CMAKE_EXPORT_NAMESPACE}::Core,INTERFACE_COMPILE_DEFINITIONS>"
)
CMake: Use correct MSVC runtime library for Qt object libraries If Qt was configured with -static-runtime which implies MultiThreaded -MT flag, the plugin initializer object libraries were still compiled with the default -MD flag. When an application linked to Qt, that caused linking to fail with mismatched symbol errors between the application symbols and the plugin initializer object library symbols. Make sure to set the MSVC_RUNTIME_LIBRARY property on both plugin initializer and resource object libraries, depending on the value of QT_FEATURE_static_runtime. We did set the property for resources added by qt_internal_add_resource, but not for the resource created by the public qt6_add_resources counterpart. Pick-to: 6.2 Fixes: QTBUG-95043 Change-Id: Ia543cd0241db94a12080be2655ad420fe9ad3f24 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-07-08 12:01:59 +00:00
_qt_internal_set_up_static_runtime_library("${resource_target}")
Compile resource objects of the static library using same options Introduce the function that appends the specified properties of the one target to the another. It's possible to copy the standard property set that affects a compilation only or pass some specific properties that need to copy. You may also control the visibily of properties that need to copy by passing the PRIVATE_ONLY or INTERFACE_ONLY option. The function is used to compile the resource targets with the same property set as the main target. Also link the Qt::Platform interface library to collect platform specific properties. Pick-to: 6.1 Change-Id: I727fd0a4bc52c4f5128f28ce796d7a5f3005bb30 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-23 14:23:36 +00:00
Fix linking order of the resource objects The generated object resource library depends on the Qt::Core library because uses the functions defined in qresource.cpp. Dummy linking of the Qt::Core to an object library has an effect only when the object library is linked directly to the executable as a target. If we link the object library as INTERFACE library we miss out all the objects that need to be linked to the executable. This behavior is explained here: https://bit.ly/3sFWKvI Thus, the only option to link the object library objects to the endpoint executable is to use TARGET_OBJECTS property in genex, as it's already done. But that means we are losing all profits that target actually has, especially linking the object library dependencies. The combination of both of the above methods does the job. The only thing that looks fragile so far is order. Currently, the order we use in the target_link_library call applies to the linker command line. This means the object library objects must always appear before the object library target. Change-Id: If1f0e35e0445d5e96a1f2249ab44114cd36630e9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-29 13:28:16 +00:00
# Special handling is required for the Core library resources. The linking of the Core
# library to the resources adds a circular dependency. This leads to the wrong
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
# objects/library order in the linker command line, since the Core library target is
# resolved first.
Fix linking order of the resource objects The generated object resource library depends on the Qt::Core library because uses the functions defined in qresource.cpp. Dummy linking of the Qt::Core to an object library has an effect only when the object library is linked directly to the executable as a target. If we link the object library as INTERFACE library we miss out all the objects that need to be linked to the executable. This behavior is explained here: https://bit.ly/3sFWKvI Thus, the only option to link the object library objects to the endpoint executable is to use TARGET_OBJECTS property in genex, as it's already done. But that means we are losing all profits that target actually has, especially linking the object library dependencies. The combination of both of the above methods does the job. The only thing that looks fragile so far is order. Currently, the order we use in the target_link_library call applies to the linker command line. This means the object library objects must always appear before the object library target. Change-Id: If1f0e35e0445d5e96a1f2249ab44114cd36630e9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-29 13:28:16 +00:00
if(NOT target STREQUAL "Core")
target_link_libraries(${resource_target} INTERFACE ${QT_CMAKE_EXPORT_NAMESPACE}::Core)
endif()
CMake: Fix resource_name variable name in __qt_propagate_generated_resource __qt_propagate_generated_resource used resourceName variable from parent scope instead of one passed to function. Pick-to: 6.0.0 6.0 Change-Id: I18ce8a9f9c01bcfdbab532def55af4e2780d7753 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-20 11:49:53 +00:00
set_property(TARGET ${resource_target} APPEND PROPERTY _qt_resource_name ${resource_name})
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
CMake: Fix resource object file paths in prl files for prefix builds Before this change, the prl files always assumed that resource object files are installed into $qt_prefix/lib when doing a prefix build. That was true for qt_internal_add_resource calls, but not for qt6_add_qml_module and qt6_target_qml_files. Change qt_internal_record_rcc_object_files to take a new required INSTALL_LOCATION argument. The argument takes a path relative to CMAKE_INSTALL_PREFIX. Modify __qt_propagate_generated_resource to save the relative path of the generated resource source file, which will be used in the computation of the final resource object file location. This is needed because the Qml resource functions place the source files in a different directory layout, e.g. .rcc vs .qmlcache Modify qt_generate_prl_file to prepend $$[QT_INSTALL_PREFIX]/ instead of $$[QT_INSTALL_LIBS]/ for the resource install paths. A follow up patch is done in qtdeclarative to pass the new INSTALL_LOCATION argument from the Qml CMake functions. Amends f9dcade5e795a631b9a2d93c855aa8198d58e24e Task-number: QTBUG-87702 Task-number: QTBUG-88425 Change-Id: Id17bb517b4cb5d00911bfd10a728ba4e0d44871b Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 54d0ca93bca78f8fd31b6761f078e7a96283f183) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2020-11-25 16:54:53 +00:00
# Save the path to the generated source file, relative to the the current build dir.
# The path will be used in static library prl file generation to ensure qmake links
# against the installed resource object files.
# Example saved path:
# .rcc/qrc_qprintdialog.cpp
file(RELATIVE_PATH generated_cpp_file_relative_path
"${CMAKE_CURRENT_BINARY_DIR}"
"${generated_source_code}")
set_property(TARGET ${resource_target} APPEND PROPERTY
_qt_resource_generated_cpp_relative_path "${generated_cpp_file_relative_path}")
Move the linking logic of the object libraries to a common function The linking logic of object libraries should be reusable outside of the resource context. This introduces a __qt_internal_propagate_object_library function that prepares all the necessary genexes to link and propagate the object library to the end-point executable. Rename resource object finalizer API to make the naming more generic to object libraries of any kind. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-15 11:09:57 +00:00
if(target STREQUAL "Core")
set(skip_direct_linking NO_LINK_OBJECT_LIBRARY_REQUIREMENTS_TO_TARGET)
endif()
__qt_internal_propagate_object_library(${target} ${resource_target}
${skip_direct_linking}
Check the impact of static link order for user projects For user projects we run the static link order check once 'find_package(Qt6 ...)' is called. If linker can resolve circular dependencies between static libraries and object files we set the _qt_link_order_matters property of the Qt::Platform target. This indicates the use of finalizers is not required and we may rely on CMake-base propagation of resource libraries and resource object files. If linker could not resolve circular dependencies depending on the _qt_resource_objects_finalizer_mode value: - Finalizer will be called and collected resource objects will be linked to the target directly. - Finalizer will be omitted and resource objects will be linked using the target_sources function implicitly. This only propagates resource one level up if consumer links the static library PUBLICly, but all symbols will be resolved correctly since object files are placed in the beginning of the linker line. In the CMake version 3.21 we expect that CMake will take care about the order of the resource object files in a linker line, it's expected that all object files are located at the beginning of the linker line. TODO: Need to confirm that the CMake 3.21 meets the expectations. Amends 4e901a2f99cbfda3b479253ea54b16f02e1c3aa5 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-10 17:01:35 +00:00
)
Add the check for linker capabilities to resolve circular dependencies 'ld' only capable to resolve circular dependencies by wrapping the suspected static libraries and objects using --start/end-group arguments. We want to detect if linker is 'ld' at configure time to decide how to link the resource objects if finalizers are not enabled. The qt_config_compile_test function is extended with an extra argument since it's required to pass custom cmake flags to the ld-related test. Pick-to: 6.2 Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-03 11:51:48 +00:00
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
set(${output_generated_target} "${resource_target}" PARENT_SCOPE)
else()
set(${output_generated_target} "" PARENT_SCOPE)
target_sources(${target} PRIVATE ${generated_source_code})
endif()
endfunction()
CMake: Expose resource source files to IDEs Add fake targets for .qml/.js and other files added using qt6_add_resources Task-number: QTBUG-87642 Change-Id: I690b223711afe96ea7fdb4cf11b8e3317ed9bbe6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-05 16:05:44 +00:00
# Creates fake targets and adds resource files to IDE's tree
Don't create ${target}_qml_files target any more The qml files should now always be added via dedicated functions provided by the qtdeclarative repo. Those functions take care of adding the files to targets so that they will show up in IDE file lists, so we should not add them to a separate target as well. This will also remove one unnecessary build target, which will reduce visual noise in some IDEs. Pick-to: 6.2 Change-Id: I79bf1ea8fb8a2f15643e052d50ac582a91bdff1a Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-12 11:38:42 +00:00
# FIXME: We shouldn't need to create a separate target for this, the files
# should be added to the actual target instead.
CMake: Expose resource source files to IDEs Add fake targets for .qml/.js and other files added using qt6_add_resources Task-number: QTBUG-87642 Change-Id: I690b223711afe96ea7fdb4cf11b8e3317ed9bbe6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-05 16:05:44 +00:00
function(_qt_internal_expose_source_file_to_ide target file)
Don't create ${target}_qml_files target any more The qml files should now always be added via dedicated functions provided by the qtdeclarative repo. Those functions take care of adding the files to targets so that they will show up in IDE file lists, so we should not add them to a separate target as well. This will also remove one unnecessary build target, which will reduce visual noise in some IDEs. Pick-to: 6.2 Change-Id: I79bf1ea8fb8a2f15643e052d50ac582a91bdff1a Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-12 11:38:42 +00:00
set(ide_target ${target}_other_files)
CMake: Expose resource source files to IDEs Add fake targets for .qml/.js and other files added using qt6_add_resources Task-number: QTBUG-87642 Change-Id: I690b223711afe96ea7fdb4cf11b8e3317ed9bbe6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-05 16:05:44 +00:00
if(NOT TARGET ${ide_target})
add_custom_target(${ide_target} SOURCES "${file}")
CMake: Fix adding generated resources on iOS with CMake and Xcode When adding resources generated via a custom command, the project fails to configure when targeting iOS with CMake and Xcode with the error: CMake Error in src/CMakeLists.txt: The custom command generating src/.qsb/TestShader.frag.qsb is attached to multiple targets: TestApp_other_files TestApp but none of these is a common dependency of the other(s). This is not allowed by the Xcode "new build system". This happens e.g. when using qt6_add_shaders, which adds a custom command to generate the qsb files. Or by simply adding resources via qt6_add_resources, which depend on a custom command. The problem is that qt6_add_resources also adds the resource to a second "fake" target ${target}_other_files via _qt_internal_process_resource and _qt_internal_expose_source_file_to_ide. See c7d1874cd16ce86dfbab319e44fe3a387378fdff. Since these targets do not have a common dependency CMake fails to configure the project. So lets fix it similar to change 1bd0a5ce02352a600367beb5a5421c8f8332e1fe and let the ${target}_other_files depend in the main ${target}. Pick-to: 6.2 Task-number: QTBUG-95763 Change-Id: Iecdb40993a91da8bfbf6553892f9b0722d2e886c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-30 18:54:16 +00:00
# The new Xcode build system requires a common target to drive the generation of files,
# otherwise project configuration fails.
# By adding ${target} as a dependency of ${target}_other_files,
# it becomes the common target, so project configuration succeeds.
if(CMAKE_GENERATOR STREQUAL "Xcode")
add_dependencies(${ide_target} ${target})
endif()
CMake: Expose resource source files to IDEs Add fake targets for .qml/.js and other files added using qt6_add_resources Task-number: QTBUG-87642 Change-Id: I690b223711afe96ea7fdb4cf11b8e3317ed9bbe6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-05 16:05:44 +00:00
else()
set_property(TARGET ${ide_target} APPEND PROPERTY SOURCES "${file}")
endif()
CMake: Fix Xcode common dependency issues for other_files IDE target A generated file can be added to a resource target, which in turn adds it to the other_files target. With the Xcode generator, this can lead to errors like The custom command generating foo.txt is attached to multiple targets: foo_other_files foo_resources_1 but none of these is a common dependency of the other(s). This is not allowed by the Xcode "new build system". Neither of the targets depend on each other because logically they shouldn't depend on each other. And yet XCode wants that each generated file is attached only to one target, which will be a common dependency for the other targets. Make sure _qt_internal_expose_source_file_to_ide extracts and uses that common target dependency just like qt_add_resources -> _qt_internal_process_resource already does. One case of a common target dependency is the _lrelease target in qttools which was added in 5b0e765ab0dddba86662925cb44aeac748a286b7 Another case is in qt_add_shaders in qtshadertools. I expect we might encounter other cases where we need to introduce a common driving target. Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-103723 Change-Id: Ideff023718a6ce109a4b3eefa01bffa79d1c6a3e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-06-14 15:28:54 +00:00
set(scope_args)
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.18")
set(scope_args TARGET_DIRECTORY "${target}")
endif()
get_source_file_property(
target_dependency "${file}" ${scope_args} _qt_resource_target_dependency)
if(target_dependency)
if(NOT TARGET "${target_dependency}")
message(FATAL_ERROR "Target dependency on source file ${file} is not a cmake target.")
endif()
add_dependencies(${ide_target} ${target_dependency})
endif()
CMake: Expose resource source files to IDEs Add fake targets for .qml/.js and other files added using qt6_add_resources Task-number: QTBUG-87642 Change-Id: I690b223711afe96ea7fdb4cf11b8e3317ed9bbe6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-05 16:05:44 +00:00
endfunction()
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
#
# Process resources via file path instead of QRC files. Behind the
Remove code paths no longer used after QML CMake API refactoring QT6_ADD_RESOURCE_DECLARATIVE_EXTENSIONS is never defined now. All qml files are expected to be added via dedicated functions provided by the qtdeclarative repo rather than being given to qt_add_resources() directly. Pick-to: 6.2 Change-Id: I44feca84a2e3d4ef8ecc0140f88625ff192bfdfd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2021-07-12 11:36:13 +00:00
# scenes, it will generate a qrc file.
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
#
# The QRC Prefix is set via the PREFIX parameter.
#
# Alias settings for files need to be set via the QT_RESOURCE_ALIAS property
Remove code paths no longer used after QML CMake API refactoring QT6_ADD_RESOURCE_DECLARATIVE_EXTENSIONS is never defined now. All qml files are expected to be added via dedicated functions provided by the qtdeclarative repo rather than being given to qt_add_resources() directly. Pick-to: 6.2 Change-Id: I44feca84a2e3d4ef8ecc0140f88625ff192bfdfd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2021-07-12 11:36:13 +00:00
# via the set_source_files_properties() command.
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
#
# When using this command with static libraries, one or more special targets
# will be generated. Should you wish to perform additional processing on these
# targets pass a value to the OUTPUT_TARGETS parameter.
#
CMake: Clean up the public API a bit Add some missing versionless functions. Rename some functions that are not meant to be public API, and their usages. Task-number: QTBUG-86827 Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-01 08:58:02 +00:00
function(_qt_internal_process_resource target resourceName)
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
cmake_parse_arguments(rcc "BIG_RESOURCES"
"PREFIX;LANG;BASE;OUTPUT_TARGETS;DESTINATION" "FILES;OPTIONS" ${ARGN})
CMake: Add support for -binary option for generated resources Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:18:49 +00:00
if("${rcc_OPTIONS}" MATCHES "-binary")
set(isBinary TRUE)
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
if(arg_BIG_RESOURCES)
message(FATAL_ERROR "BIG_RESOURCES cannot be used together with the -binary option.")
endif()
endif()
if(arg_BIG_RESOURCES AND CMAKE_GENERATOR STREQUAL "Xcode" AND IOS)
message(WARNING
"Due to CMake limitations, the BIG_RESOURCES option can't be used when building "
"for iOS. "
"See https://bugreports.qt.io/browse/QTBUG-103497 for details. "
"Falling back to using regular resources. "
)
set(arg_BIG_RESOURCES OFF)
endif()
if(arg_BIG_RESOURCES AND CMAKE_VERSION VERSION_LESS "3.17")
message(WARNING
"The BIG_RESOURCES option does not work reliably with CMake < 3.17. "
"Consider upgrading to a more recent CMake version or disable the BIG_RESOURCES "
"option for older CMake versions."
)
CMake: Add support for -binary option for generated resources Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:18:49 +00:00
endif()
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
string(REPLACE "/" "_" resourceName ${resourceName})
string(REPLACE "." "_" resourceName ${resourceName})
Strip the ending slashes for resource folders Setting a value for the QT_RESOURCE_ALIAS source file property on a path ending with a slash (a directory) is not handled properly by CMake. This leads to unpredictable values being set for multiple directories. Fix this by stripping the the final slash from the file path, which makes CMake think it's a file rather than a directory. Change-Id: I7a39be68e6f58bf2726c80108da9947057e7add6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-02-10 11:58:41 +00:00
set(resource_files "")
# Strip the ending slashes from the file_path. If paths contain slashes in the end
# set/get source properties works incorrect and may have the same QT_RESOURCE_ALIAS
# for two different paths. See https://gitlab.kitware.com/cmake/cmake/-/issues/23212
# for details.
foreach(file_path IN LISTS rcc_FILES)
if(file_path MATCHES "(.+)/$")
set(file_path "${CMAKE_MATCH_1}")
endif()
list(APPEND resource_files ${file_path})
endforeach()
Remove legacy code path from qt_add_resource All repos use the updated version of qt_add_resource, and we can remove the legacy code path. Change-Id: I15ba64a08c3fad9712a5cf05715594b1ee755bfc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-06-07 07:34:43 +00:00
if(NOT "${rcc_BASE}" STREQUAL "")
get_filename_component(abs_base "${rcc_BASE}" ABSOLUTE)
foreach(file_path IN LISTS resource_files)
get_source_file_property(alias "${file_path}" QT_RESOURCE_ALIAS)
if(alias STREQUAL "NOTFOUND")
get_filename_component(abs_file "${file_path}" ABSOLUTE)
file(RELATIVE_PATH rel_file "${abs_base}" "${abs_file}")
set_property(SOURCE "${file_path}" PROPERTY QT_RESOURCE_ALIAS "${rel_file}")
endif()
endforeach()
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
endif()
Collect QT_QML_ROOT_PATH based from the project resources Use the _qt_internal_collect_qml_root_paths function to collect qml files from the resources. The function is called only if Qml module is found. Pick-to: 6.2 Task-number: QTBUG-93340 Change-Id: I2b5f51e3d7fb8aa82f46e88b2aac5e52bf0930d5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
2021-08-17 18:15:11 +00:00
if(ANDROID)
if(COMMAND _qt_internal_collect_qml_root_paths)
_qt_internal_collect_qml_root_paths(${target} ${resource_files})
endif()
endif()
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
if(NOT rcc_PREFIX)
get_target_property(rcc_PREFIX ${target} QT_RESOURCE_PREFIX)
if (NOT rcc_PREFIX)
CMake: Clean up the public API a bit Add some missing versionless functions. Rename some functions that are not meant to be public API, and their usages. Task-number: QTBUG-86827 Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-01 08:58:02 +00:00
message(FATAL_ERROR "_qt_internal_process_resource() was called without a PREFIX and the target does not provide QT_RESOURCE_PREFIX. Please either add a PREFIX or make the target ${target} provide a default.")
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
endif()
endif()
Remove code paths no longer used after QML CMake API refactoring QT6_ADD_RESOURCE_DECLARATIVE_EXTENSIONS is never defined now. All qml files are expected to be added via dedicated functions provided by the qtdeclarative repo rather than being given to qt_add_resources() directly. Pick-to: 6.2 Change-Id: I44feca84a2e3d4ef8ecc0140f88625ff192bfdfd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2021-07-12 11:36:13 +00:00
if (NOT resource_files)
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
if (rcc_OUTPUT_TARGETS)
Clean up output target handling left behind by earlier changes Previous work removed the no-longer-used code path that could add targets from qml compiler features. The variable that code path would populate was not fully cleaned up in that removal. Clean it up now and move the variables related to output target handling closer to the only remaining area where they could be generated. Also ensure that we set the variable named by OUTPUT_TARGETS even if isBinary ends up being true. We should explicitly set that variable to an empty string in that case. Amends 363df5cd709762c3c014132c1670fdd715233620 Pick-to: 6.2 Change-Id: I17de9788b390aac9a7aedb29ab9bdfee99c305af Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-02 04:40:46 +00:00
set(${rcc_OUTPUT_TARGETS} "" PARENT_SCOPE)
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
endif()
return()
endif()
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
set(generatedResourceFile "${CMAKE_CURRENT_BINARY_DIR}/.rcc/${resourceName}.qrc")
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
# Generate .qrc file:
# <RCC><qresource ...>
set(qrcContents "<RCC>\n <qresource")
if (rcc_PREFIX)
string(APPEND qrcContents " prefix=\"${rcc_PREFIX}\"")
endif()
if (rcc_LANG)
string(APPEND qrcContents " lang=\"${rcc_LANG}\"")
endif()
string(APPEND qrcContents ">\n")
set(resource_dependencies)
Remove code paths no longer used after QML CMake API refactoring QT6_ADD_RESOURCE_DECLARATIVE_EXTENSIONS is never defined now. All qml files are expected to be added via dedicated functions provided by the qtdeclarative repo rather than being given to qt_add_resources() directly. Pick-to: 6.2 Change-Id: I44feca84a2e3d4ef8ecc0140f88625ff192bfdfd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2021-07-12 11:36:13 +00:00
foreach(file IN LISTS resource_files)
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
__qt_get_relative_resource_path_for_file(file_resource_path ${file})
if (NOT IS_ABSOLUTE ${file})
set(file "${CMAKE_CURRENT_SOURCE_DIR}/${file}")
endif()
### FIXME: escape file paths to be XML conform
# <file ...>...</file>
string(APPEND qrcContents " <file alias=\"${file_resource_path}\">")
string(APPEND qrcContents "${file}</file>\n")
list(APPEND files "${file}")
CMake: Change QT_RESOURCE_TARGET_DEPENDENCY property to be internal Rename the property to _qt_resource_target_dependency and make sure we also consider which scope we are getting the source file property from if the CMake version is recent enough. Pick-to: 6.3 Task-number: QTBUG-103470 Change-Id: I755413c91bc0bc9033760a888927b60c470c562b Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-13 17:14:20 +00:00
set(scope_args)
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.18")
set(scope_args TARGET_DIRECTORY ${target})
endif()
get_source_file_property(
target_dependency ${file} ${scope_args} _qt_resource_target_dependency)
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
if (NOT target_dependency)
list(APPEND resource_dependencies ${file})
else()
if (NOT TARGET ${target_dependency})
message(FATAL_ERROR "Target dependency on resource file ${file} is not a cmake target.")
endif()
list(APPEND resource_dependencies ${target_dependency})
endif()
CMake: Expose resource source files to IDEs Add fake targets for .qml/.js and other files added using qt6_add_resources Task-number: QTBUG-87642 Change-Id: I690b223711afe96ea7fdb4cf11b8e3317ed9bbe6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-05 16:05:44 +00:00
_qt_internal_expose_source_file_to_ide(${target} "${file}")
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
endforeach()
# </qresource></RCC>
string(APPEND qrcContents " </qresource>\n</RCC>\n")
CMake: Fix unnecessary rebuilding upon reconfiguration The following MR in upstream CMake makes sure that the autogen targets depend on the CMakeLists.txt file associated with the autogen target, as well as any files it includes. https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5166 When doing a no-op reconfiguration in the build dir (call 'cmake .') we used file(WRITE) to prepare the contents of a file to be used with configure_file() for creation of a .qrc resource file. Because this file was always rewritten on reconfiguration, its timestamp was newer than then autogen target's timestamp which caused the autogen targets to-be rerun, as well as some compilation and relinking. To avoid this, instead of using file(WRITE) ship a template file next to the Qt6CoreMacros.cmake file, and use it as a template for the qrc configure_file() call. This ensures that a reconfiguration doesn't necessarily rebuild things it shouldn't rebuild. Amends 113f1ad324202ea2b861a3dbdec2ee7ef716c283 Task-number: QTBUG-88004 Change-Id: Icd95b28ca3642434cf21e5c49dcbd1ec65d76252 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-10-30 15:46:40 +00:00
set(template_file "${__qt_core_macros_module_base_dir}/Qt6CoreConfigureFileTemplate.in")
set(qt_core_configure_file_contents "${qrcContents}")
configure_file("${template_file}" "${generatedResourceFile}")
CMake: Generate qrc files at configure time and make them traceable Having the qrc files at configure time allows qmlimportscanner to scan them when invoked with -qrcFiles argument. The traceability part is done via _qt_generated_qrc_files property. Task-number: QTBUG-85994 Change-Id: I75c252a987cd1c1f49ba73ec9d100edc73c23486 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-10-14 14:04:44 +00:00
Remove code paths no longer used after QML CMake API refactoring QT6_ADD_RESOURCE_DECLARATIVE_EXTENSIONS is never defined now. All qml files are expected to be added via dedicated functions provided by the qtdeclarative repo rather than being given to qt_add_resources() directly. Pick-to: 6.2 Change-Id: I44feca84a2e3d4ef8ecc0140f88625ff192bfdfd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2021-07-12 11:36:13 +00:00
set(rccArgs --name "${resourceName}" "${generatedResourceFile}")
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
set(rccArgsAllPasses "")
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
if(rcc_OPTIONS)
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
list(APPEND rccArgsAllPasses ${rcc_OPTIONS})
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
endif()
# When cross-building, we use host tools to generate target code. If the host rcc was compiled
# with zstd support, it expects the target QtCore to be able to decompress zstd compressed
# content. This might be true with qmake where host tools are built as part of the
# cross-compiled Qt, but with CMake we build tools separate from the cross-compiled Qt.
# If the target does not support zstd (feature is disabled), tell rcc not to generate
# zstd related code.
if(NOT QT_FEATURE_zstd)
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
list(APPEND rccArgsAllPasses "--no-zstd")
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
endif()
CMake: Add support for -binary option for generated resources Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:18:49 +00:00
set_property(SOURCE "${generatedResourceFile}" PROPERTY SKIP_AUTOGEN ON)
# Set output file name for rcc command
if(isBinary)
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
set(generatedOutfile "${CMAKE_CURRENT_BINARY_DIR}/${resourceName}.rcc")
CMake: Add support for -binary option for generated resources Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:18:49 +00:00
if(rcc_DESTINATION)
# Add .rcc suffix if it's not specified by user
get_filename_component(destinationRccExt "${rcc_DESTINATION}" LAST_EXT)
if("${destinationRccExt}" STREQUAL ".rcc")
set(generatedOutfile "${rcc_DESTINATION}")
else()
set(generatedOutfile "${rcc_DESTINATION}.rcc")
endif()
endif()
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
elseif(rcc_BIG_RESOURCES)
set(generatedOutfile "${CMAKE_CURRENT_BINARY_DIR}/.rcc/qrc_${resourceName}_tmp.cpp")
CMake: Add support for -binary option for generated resources Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:18:49 +00:00
else()
Remove code paths no longer used after QML CMake API refactoring QT6_ADD_RESOURCE_DECLARATIVE_EXTENSIONS is never defined now. All qml files are expected to be added via dedicated functions provided by the qtdeclarative repo rather than being given to qt_add_resources() directly. Pick-to: 6.2 Change-Id: I44feca84a2e3d4ef8ecc0140f88625ff192bfdfd Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2021-07-12 11:36:13 +00:00
set(generatedOutfile "${CMAKE_CURRENT_BINARY_DIR}/.rcc/qrc_${resourceName}.cpp")
CMake: Add support for -binary option for generated resources Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:18:49 +00:00
endif()
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
set(pass_msg)
if(rcc_BIG_RESOURCES)
list(PREPEND rccArgs --pass 1)
set(pass_msg " pass 1")
endif()
CMake: Add support for -binary option for generated resources Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:18:49 +00:00
list(PREPEND rccArgs --output "${generatedOutfile}")
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
# Process .qrc file:
CMake: Add support for -binary option for generated resources Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:18:49 +00:00
add_custom_command(OUTPUT "${generatedOutfile}"
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
COMMAND "${QT_CMAKE_EXPORT_NAMESPACE}::rcc" ${rccArgs} ${rccArgsAllPasses}
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
DEPENDS
${resource_dependencies}
${generatedResourceFile}
"${QT_CMAKE_EXPORT_NAMESPACE}::rcc"
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
COMMENT "Running rcc${pass_msg} for resource ${resourceName}"
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
VERBATIM)
CMake: Add support for -binary option for generated resources Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-11-10 14:18:49 +00:00
if(isBinary)
# Add generated .rcc target to 'all' set
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
add_custom_target(binary_resource_${resourceName} ALL DEPENDS "${generatedOutfile}")
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
return()
endif()
# We can't rely on policy CMP0118 since user project controls it.
# We also want SKIP_AUTOGEN known in the target's scope, where we can.
set(scope_args)
if(CMAKE_VERSION VERSION_GREATER_EQUAL "3.18")
set(scope_args TARGET_DIRECTORY ${target})
endif()
set_source_files_properties(${generatedOutfile} ${scope_args} PROPERTIES
SKIP_AUTOGEN TRUE
GENERATED TRUE
SKIP_UNITY_BUILD_INCLUSION TRUE
SKIP_PRECOMPILE_HEADERS TRUE
)
get_target_property(target_source_dir ${target} SOURCE_DIR)
if(NOT target_source_dir STREQUAL CMAKE_CURRENT_SOURCE_DIR)
# We have to create a separate target in this scope that depends on
# the generated file, otherwise the original target won't have the
# required dependencies in place to ensure correct build order.
add_custom_target(${target}_${resourceName} DEPENDS ${generatedOutfile})
add_dependencies(${target} ${target}_${resourceName})
endif()
if(rcc_BIG_RESOURCES)
set(pass1OutputFile ${generatedOutfile})
set(generatedOutfile
"${CMAKE_CURRENT_BINARY_DIR}/.rcc/qrc_${resourceName}${CMAKE_CXX_OUTPUT_EXTENSION}")
_qt_internal_add_rcc_pass2(
RESOURCE_NAME ${resourceName}
RCC_OPTIONS ${rccArgsAllPasses}
OBJECT_LIB ${target}_${resourceName}_obj
QRC_FILE ${generatedResourceFile}
PASS1_OUTPUT_FILE ${pass1OutputFile}
OUT_OBJECT_FILE ${generatedOutfile}
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
)
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
get_target_property(type ${target} TYPE)
if(type STREQUAL STATIC_LIBRARY)
# Create a custom target to trigger the generation of ${generatedOutfile}
set(pass2_target ${target}_${resourceName}_pass2)
add_custom_target(${pass2_target} DEPENDS ${generatedOutfile})
add_dependencies(${target} ${pass2_target})
# Propagate the object files to the target.
__qt_internal_propagate_object_files(${target} "${generatedOutfile}")
else()
target_sources(${target} PRIVATE ${generatedOutfile})
Fix dependencies on sources generated in a different scope to target In certain situations, a file generated by add_custom_command(OUTPUT) may be added as a source to a target defined in a different directory scope. That makes its GENERATED source property not visible to the target for CMake versions before 3.20. For 3.20 and later, policy CMP0118 can make the generated state of a source file global, but that policy is under the control of the user project, since its value at the end of the target's directory scope is what is used. Therefore we can force that global visibility using CMP0118. With CMake 3.18 or later, we can set source properties in arbitrary scopes, which allows us to force visibility in the scopes we need it. Use that for all CMake versions 3.18 and later to make the source file properties visible to the target. Making the generated state of a source file visible to the target isn't enough on its own. In the scope that the file is generated, there must be a target that depends on the file or else CMake won't set up the necessary dependencies to ensure that generation happens before the target tries to use it. Add targets in the generated file's own scope where we currently might not do that. Task-number: QTBUG-95200 Pick-to: 6.2 Change-Id: Ic1dfca1a193041de01d7f903b79473b9d47f1d1d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-09-07 05:51:18 +00:00
endif()
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
else()
__qt_propagate_generated_resource(${target} ${resourceName} "${generatedOutfile}"
output_targets)
Clean up output target handling left behind by earlier changes Previous work removed the no-longer-used code path that could add targets from qml compiler features. The variable that code path would populate was not fully cleaned up in that removal. Clean it up now and move the variables related to output target handling closer to the only remaining area where they could be generated. Also ensure that we set the variable named by OUTPUT_TARGETS even if isBinary ends up being true. We should explicitly set that variable to an empty string in that case. Amends 363df5cd709762c3c014132c1670fdd715233620 Pick-to: 6.2 Change-Id: I17de9788b390aac9a7aedb29ab9bdfee99c305af Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-02 04:40:46 +00:00
endif()
CMake: Support big resources in qt_add_resources [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-14 15:23:15 +00:00
set_property(TARGET ${target}
APPEND PROPERTY _qt_generated_qrc_files "${generatedResourceFile}")
Clean up output target handling left behind by earlier changes Previous work removed the no-longer-used code path that could add targets from qml compiler features. The variable that code path would populate was not fully cleaned up in that removal. Clean it up now and move the variables related to output target handling closer to the only remaining area where they could be generated. Also ensure that we set the variable named by OUTPUT_TARGETS even if isBinary ends up being true. We should explicitly set that variable to an empty string in that case. Amends 363df5cd709762c3c014132c1670fdd715233620 Pick-to: 6.2 Change-Id: I17de9788b390aac9a7aedb29ab9bdfee99c305af Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-02 04:40:46 +00:00
if (rcc_OUTPUT_TARGETS)
set(${rcc_OUTPUT_TARGETS} "${output_targets}" PARENT_SCOPE)
CMake: Move Resources API into Qt6CoreMacros Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra config file step. Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-17 12:36:09 +00:00
endif()
endfunction()
CMake: Add qt6_add_plugin public API This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-21 11:28:57 +00:00
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
macro(_qt_internal_get_add_plugin_keywords option_args single_args multi_args)
set(${option_args}
STATIC
CMake: Choose better defaults for qt_add_plugin STATIC/SHARED There was a recent behavior change where the public CMake API qt_add_plugin API took into account the value of BUILD_SHARED_LIBS to decide whether the plugin should be a static or shared library. Instead, use the following new behavior - If no explicit option STATIC / SHARED option is passed, default to whatever flavor Qt was built as. Aka if Qt was configured with -shared, qt_add_plugin defaults to creating shared plugins. If it's a -static Qt, create static plugins. - If an explicit STATIC / SHARED option is set, override the default computed value with the given value. As a result BUILD_SHARED_LIBS does not affect Qt plugins anymore. This is more in line with Qt expectations. Add SHARED as a new valid option to pass to qt_add_plugin (it wasn't before). Add tests to check for the above behavior. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Pick-to: 6.1 Fixes: QTBUG-92361 Task-number: QTBUG-88763 Change-Id: Iae806024ddd5cf10cfe58ddbcebd2818084b0bd7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-06 11:06:11 +00:00
SHARED
CMake: Create plugin initializers for static user plugins Previously we only created object library static plugin initializers for Qt plugins only, not user-project plugins. The reason was that if a user tried to install the plugin target via an export set, CMake would error out saying that the _init library is not part of the same export set. Introduce an OUTPUT_TARGETS option that would allow projects to get the name of the generated _init target, so they can install it if needed. This was already done for qt6_add_qml_module, so we just introduce the same option for qt6_add_plugin. Now user static plugins will have an _init target created, which will be propagated to consumers whenever the consumers link against the plugin itself. We also need an internal option to disable this propagation, because it's handled a bit differently for Qt plugins which can be linked either via finalizers or via usage requirements. Amends 91c65dd80cdd2de666448c14202c0c63718152b6 As a result of the implementation change, cleanup example projects to ensure that they build successfully (the important part is specifying the CLASS_NAME). Only plugandpaint works properly with both shared and static Qt builds. echoplugin works with a shared Qt build, but not a static one due to some assumptions in the C++ code about shared plugins. styleplugin doesn't seem to work properly neither with shared Qt builds nor static Qt builds, at least on macOS. But it builds fine. For some reason even if the plugin is found, the style is not applied. Amends 4caac1feea025b0ad496141e8f16ab88c04c2caa Pick-to: 6.2 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb 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-08-19 09:42:12 +00:00
__QT_INTERNAL_NO_PROPAGATE_PLUGIN_INITIALIZER
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
)
set(${single_args}
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
# TODO: For backward compatibility / transitional use only, remove once all repos no longer
# use it
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
TYPE
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
Add docs for qt_add_plugin() Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: Ifdc10c7714e91f6211a52bd5c46b3140485bbb43 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2021-09-21 07:44:03 +00:00
PLUGIN_TYPE # Internal use only, may be changed or removed
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
CLASS_NAME
Add docs for qt_add_plugin() Task-number: QTBUG-95712 Pick-to: 6.2 6.2.0 Change-Id: Ifdc10c7714e91f6211a52bd5c46b3140485bbb43 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2021-09-21 07:44:03 +00:00
OUTPUT_NAME # Internal use only, may be changed or removed
CMake: Create plugin initializers for static user plugins Previously we only created object library static plugin initializers for Qt plugins only, not user-project plugins. The reason was that if a user tried to install the plugin target via an export set, CMake would error out saying that the _init library is not part of the same export set. Introduce an OUTPUT_TARGETS option that would allow projects to get the name of the generated _init target, so they can install it if needed. This was already done for qt6_add_qml_module, so we just introduce the same option for qt6_add_plugin. Now user static plugins will have an _init target created, which will be propagated to consumers whenever the consumers link against the plugin itself. We also need an internal option to disable this propagation, because it's handled a bit differently for Qt plugins which can be linked either via finalizers or via usage requirements. Amends 91c65dd80cdd2de666448c14202c0c63718152b6 As a result of the implementation change, cleanup example projects to ensure that they build successfully (the important part is specifying the CLASS_NAME). Only plugandpaint works properly with both shared and static Qt builds. echoplugin works with a shared Qt build, but not a static one due to some assumptions in the C++ code about shared plugins. styleplugin doesn't seem to work properly neither with shared Qt builds nor static Qt builds, at least on macOS. But it builds fine. For some reason even if the plugin is found, the style is not applied. Amends 4caac1feea025b0ad496141e8f16ab88c04c2caa Pick-to: 6.2 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb 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-08-19 09:42:12 +00:00
OUTPUT_TARGETS
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
)
set(${multi_args})
endmacro()
CMake: Add qt6_add_plugin public API This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-21 11:28:57 +00:00
function(qt6_add_plugin target)
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
_qt_internal_get_add_plugin_keywords(opt_args single_args multi_args)
cmake_parse_arguments(PARSE_ARGV 1 arg "${opt_args}" "${single_args}" "${multi_args}")
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
# Handle the inconsistent TYPE/PLUGIN_TYPE keyword naming between commands
if(arg_TYPE)
if(arg_PLUGIN_TYPE AND NOT arg_TYPE STREQUAL arg_PLUGIN_TYPE)
message(FATAL_ERROR
"Both TYPE and PLUGIN_TYPE were given and were different. "
"Only one of the two should be used."
)
endif()
message(AUTHOR_WARNING
"The TYPE keyword is deprecated and will be removed soon. Please use PLUGIN_TYPE instead.")
set(arg_PLUGIN_TYPE "${arg_TYPE}")
unset(arg_TYPE)
endif()
CMake: Choose better defaults for qt_add_plugin STATIC/SHARED There was a recent behavior change where the public CMake API qt_add_plugin API took into account the value of BUILD_SHARED_LIBS to decide whether the plugin should be a static or shared library. Instead, use the following new behavior - If no explicit option STATIC / SHARED option is passed, default to whatever flavor Qt was built as. Aka if Qt was configured with -shared, qt_add_plugin defaults to creating shared plugins. If it's a -static Qt, create static plugins. - If an explicit STATIC / SHARED option is set, override the default computed value with the given value. As a result BUILD_SHARED_LIBS does not affect Qt plugins anymore. This is more in line with Qt expectations. Add SHARED as a new valid option to pass to qt_add_plugin (it wasn't before). Add tests to check for the above behavior. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Pick-to: 6.1 Fixes: QTBUG-92361 Task-number: QTBUG-88763 Change-Id: Iae806024ddd5cf10cfe58ddbcebd2818084b0bd7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-06 11:06:11 +00:00
if(arg_STATIC AND arg_SHARED)
message(FATAL_ERROR
"Both STATIC and SHARED options were given. Only one of the two should be used."
)
endif()
# Explicit option takes priority over the computed default.
if(arg_STATIC)
set(create_static_plugin TRUE)
elseif(arg_SHARED)
set(create_static_plugin FALSE)
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 10:35:18 +00:00
else()
# If no explicit STATIC/SHARED option is set, default to the flavor of the Qt build.
if(QT6_IS_SHARED_LIBS_BUILD)
set(create_static_plugin FALSE)
else()
set(create_static_plugin TRUE)
endif()
CMake: Choose better defaults for qt_add_plugin STATIC/SHARED There was a recent behavior change where the public CMake API qt_add_plugin API took into account the value of BUILD_SHARED_LIBS to decide whether the plugin should be a static or shared library. Instead, use the following new behavior - If no explicit option STATIC / SHARED option is passed, default to whatever flavor Qt was built as. Aka if Qt was configured with -shared, qt_add_plugin defaults to creating shared plugins. If it's a -static Qt, create static plugins. - If an explicit STATIC / SHARED option is set, override the default computed value with the given value. As a result BUILD_SHARED_LIBS does not affect Qt plugins anymore. This is more in line with Qt expectations. Add SHARED as a new valid option to pass to qt_add_plugin (it wasn't before). Add tests to check for the above behavior. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Pick-to: 6.1 Fixes: QTBUG-92361 Task-number: QTBUG-88763 Change-Id: Iae806024ddd5cf10cfe58ddbcebd2818084b0bd7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-06 11:06:11 +00:00
endif()
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 10:35:18 +00:00
# The default of _qt_internal_add_library creates SHARED in a shared Qt build, so we need to
# be explicit about the MODULE.
if(create_static_plugin)
set(type_to_create STATIC)
CMake: Add qt6_add_plugin public API This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-21 11:28:57 +00:00
else()
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 10:35:18 +00:00
set(type_to_create MODULE)
endif()
CMake: Let qt6_add_plugin accept sources The commands qt6_add_executable and qt6_add_library both accept a list of sources that get automatically added to the created target. Extend qt6_add_plugin to also accept sources for consistency. Fixes: QTBUG-104189 Change-Id: Iad5d8c5b31551663be155d068d55e770e1a91b27 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-06-22 15:05:23 +00:00
_qt_internal_add_library(${target} ${type_to_create} ${arg_UNPARSED_ARGUMENTS})
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 10:35:18 +00:00
get_target_property(target_type "${target}" TYPE)
if (target_type STREQUAL "STATIC_LIBRARY")
target_compile_definitions(${target} PRIVATE QT_STATICPLUGIN)
CMake: Add qt6_add_plugin public API This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-21 11:28:57 +00:00
endif()
set(output_name ${target})
if (arg_OUTPUT_NAME)
set(output_name ${arg_OUTPUT_NAME})
endif()
set_property(TARGET "${target}" PROPERTY OUTPUT_NAME "${output_name}")
if (ANDROID)
set_target_properties(${target}
PROPERTIES
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
LIBRARY_OUTPUT_NAME "plugins_${arg_PLUGIN_TYPE}_${output_name}"
CMake: Add qt6_add_plugin public API This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-21 11:28:57 +00:00
)
endif()
Set QT_PLUGIN_CLASS_NAME also on public plugins ... and update handling of CLASS_NAME in qt_internal_add_plugin Change-Id: Iec8e5f9f80df02c9ba21648535872988839f4b64 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-28 12:07:29 +00:00
# Derive the class name from the target name if it's not explicitly specified.
set(plugin_class_name "")
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
if (NOT "${arg_PLUGIN_TYPE}" STREQUAL "qml_plugin")
Refactor qt_internal_add_plugin() and qt6_add_plugin() Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-03-23 04:48:56 +00:00
if (NOT arg_CLASS_NAME)
set(plugin_class_name "${target}")
else()
set(plugin_class_name "${arg_CLASS_NAME}")
endif()
CMake: Set the plugin class name for qml plugins This is needed for a change in qtdeclarative to allow building the Q_IMPORT_PLUGIN-containing object library initializer of a qml plugin. Show an error if the qml plugin has no class name, it's needed for plugin initialization so it's mandatory to have a class name. Show an error if a class name is not found when computing the import macro for a plugin (both for a regular qt plugin and a qml plugin). When querying for the class name of a target, query both a Qt6:: prefixed target as well as a non-prefixed one, with the Qt one taking precedence. This is to allow querying the class name of user project created qml plugins. Currently regular qt user plugins don't use the object library initializer approach. This will likely be revisited in the future. Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I46417471a7d8b49651e6821f7b28e7a9d44c2557 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-11 15:02:45 +00:00
else()
# Make sure to set any passed-in class name for qml plugins as well, because it's used for
# building the qml plugin foo_init object libraries.
if(arg_CLASS_NAME)
set(plugin_class_name "${arg_CLASS_NAME}")
else()
message(FATAL_ERROR "Qml plugin target has no CLASS_NAME specified: '${target}'")
endif()
Set QT_PLUGIN_CLASS_NAME also on public plugins ... and update handling of CLASS_NAME in qt_internal_add_plugin Change-Id: Iec8e5f9f80df02c9ba21648535872988839f4b64 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-28 12:07:29 +00:00
endif()
CMake: Set the plugin class name for qml plugins This is needed for a change in qtdeclarative to allow building the Q_IMPORT_PLUGIN-containing object library initializer of a qml plugin. Show an error if the qml plugin has no class name, it's needed for plugin initialization so it's mandatory to have a class name. Show an error if a class name is not found when computing the import macro for a plugin (both for a regular qt plugin and a qml plugin). When querying for the class name of a target, query both a Qt6:: prefixed target as well as a non-prefixed one, with the Qt one taking precedence. This is to allow querying the class name of user project created qml plugins. Currently regular qt user plugins don't use the object library initializer approach. This will likely be revisited in the future. Pick-to: 6.2 Task-number: QTBUG-92933 Change-Id: I46417471a7d8b49651e6821f7b28e7a9d44c2557 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-06-11 15:02:45 +00:00
Set QT_PLUGIN_CLASS_NAME also on public plugins ... and update handling of CLASS_NAME in qt_internal_add_plugin Change-Id: Iec8e5f9f80df02c9ba21648535872988839f4b64 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-28 12:07:29 +00:00
set_target_properties(${target} PROPERTIES QT_PLUGIN_CLASS_NAME "${plugin_class_name}")
CMake: Create plugin initializers for static user plugins Previously we only created object library static plugin initializers for Qt plugins only, not user-project plugins. The reason was that if a user tried to install the plugin target via an export set, CMake would error out saying that the _init library is not part of the same export set. Introduce an OUTPUT_TARGETS option that would allow projects to get the name of the generated _init target, so they can install it if needed. This was already done for qt6_add_qml_module, so we just introduce the same option for qt6_add_plugin. Now user static plugins will have an _init target created, which will be propagated to consumers whenever the consumers link against the plugin itself. We also need an internal option to disable this propagation, because it's handled a bit differently for Qt plugins which can be linked either via finalizers or via usage requirements. Amends 91c65dd80cdd2de666448c14202c0c63718152b6 As a result of the implementation change, cleanup example projects to ensure that they build successfully (the important part is specifying the CLASS_NAME). Only plugandpaint works properly with both shared and static Qt builds. echoplugin works with a shared Qt build, but not a static one due to some assumptions in the C++ code about shared plugins. styleplugin doesn't seem to work properly neither with shared Qt builds nor static Qt builds, at least on macOS. But it builds fine. For some reason even if the plugin is found, the style is not applied. Amends 4caac1feea025b0ad496141e8f16ab88c04c2caa Pick-to: 6.2 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb 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-08-19 09:42:12 +00:00
# Create a plugin initializer object library for static plugins.
# It contains a Q_IMPORT_PLUGIN(QT_PLUGIN_CLASS_NAME) call.
# Project targets will automatically link to the plugin initializer whenever they link to the
# plugin target.
# The plugin init target name is stored in OUTPUT_TARGETS, so projects may install them.
# Qml plugin inits are handled in Qt6QmlMacros.
if(NOT "${arg_PLUGIN_TYPE}" STREQUAL "qml_plugin"
AND target_type STREQUAL "STATIC_LIBRARY")
__qt_internal_add_static_plugin_init_object_library("${target}" plugin_init_target)
if(arg_OUTPUT_TARGETS)
set(${arg_OUTPUT_TARGETS} ${plugin_init_target} PARENT_SCOPE)
endif()
# We don't automatically propagate the plugin init library for Qt provided plugins, because
# there are 2 other code paths that take care of that, one involving finalizers and the
# other regular usage requirements.
if(NOT arg___QT_INTERNAL_NO_PROPAGATE_PLUGIN_INITIALIZER)
__qt_internal_propagate_object_library("${target}" "${plugin_init_target}")
endif()
Fix cases of output variables not being passed back to calling scope Some versionless wrappers were not passing back output variables to their calling scope. Ensure they always are. Fix qt6_extract_metatypes() to set its output variable in the parent scope (it was previously setting it erroneously in the local scope). Some functions had code paths that would not set output variables. This would allow situations where if the variables had an initial value set by a higher up parent scope, the output variable would still have that value in the caller's scope upon return. That could be misleading, so fix these code paths to explicitly set the output variable to an empty string instead. Task-number: QTBUG-96121 Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: I291775813f025cabdccd4372ac077cdfd3ec090e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-06 01:18:06 +00:00
else()
if(arg_OUTPUT_TARGETS)
set(${arg_OUTPUT_TARGETS} "" PARENT_SCOPE)
endif()
CMake: Create plugin initializers for static user plugins Previously we only created object library static plugin initializers for Qt plugins only, not user-project plugins. The reason was that if a user tried to install the plugin target via an export set, CMake would error out saying that the _init library is not part of the same export set. Introduce an OUTPUT_TARGETS option that would allow projects to get the name of the generated _init target, so they can install it if needed. This was already done for qt6_add_qml_module, so we just introduce the same option for qt6_add_plugin. Now user static plugins will have an _init target created, which will be propagated to consumers whenever the consumers link against the plugin itself. We also need an internal option to disable this propagation, because it's handled a bit differently for Qt plugins which can be linked either via finalizers or via usage requirements. Amends 91c65dd80cdd2de666448c14202c0c63718152b6 As a result of the implementation change, cleanup example projects to ensure that they build successfully (the important part is specifying the CLASS_NAME). Only plugandpaint works properly with both shared and static Qt builds. echoplugin works with a shared Qt build, but not a static one due to some assumptions in the C++ code about shared plugins. styleplugin doesn't seem to work properly neither with shared Qt builds nor static Qt builds, at least on macOS. But it builds fine. For some reason even if the plugin is found, the style is not applied. Amends 4caac1feea025b0ad496141e8f16ab88c04c2caa Pick-to: 6.2 Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: I6f631cda9566229b7a63992b23d7d7fa50303eeb 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-08-19 09:42:12 +00:00
endif()
CMake: Add qt6_add_plugin public API This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-21 11:28:57 +00:00
target_compile_definitions(${target} PRIVATE
QT_PLUGIN
QT_DEPRECATED_WARNINGS
)
Make sure that all plugin targets are built before deploying to Android We need to make sure that all plugin targets are built and present on the file system before running androiddeployqt. This especially important when building executables that depend on qml modules that are built in the project tree. This adds meta target that collects all the plugin targets as dependencies and adds this meta target as the dependency for the custom target that executes androiddeployqt. TODO: We should also take into account MODULE libraries that were added using the CMake add_library call, but since qt6_finalize_project is not a part of 6.2 API, this will be added in follow up commit. Pick-to: 6.2 Task-number: QTBUG-94714 Task-number: QTBUG-88841 Change-Id: I4b4596eb8ed364dbe80e2cfb0ce31cec32e7c03f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-11-04 15:08:34 +00:00
if(target_type STREQUAL "MODULE_LIBRARY")
if(NOT TARGET qt_internal_plugins)
add_custom_target(qt_internal_plugins)
endif()
add_dependencies(qt_internal_plugins ${target})
endif()
CMake: Add qt6_add_plugin public API This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-21 11:28:57 +00:00
endfunction()
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_add_plugin)
CMake: Fix qt_add_plugin to be a proper public API function When configuring an example like widgets/tools/plugandpaint/plugins/basictools outside of a Qt build, the configuration fails because it tries to call the internal function instead of the public one. This was needed some time ago to facilitate moving from qt_add_plugin to qt_internal_add_plugin, so some compatibility code was added. But we've now migrated to qt_internal_add_plugin across most repos, so we should remove the compatibility code to allow examples to configure successfully. Amends 6fbeef4c6b2323fc4b7856520c0f38f8139c9c54 Fixes: QTBUG-86858 Change-Id: Ib15f50351a8742c44d7a8be84be4e576cb48bddb Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-15 15:09:29 +00:00
qt6_add_plugin(${ARGV})
Fix cases of output variables not being passed back to calling scope Some versionless wrappers were not passing back output variables to their calling scope. Ensure they always are. Fix qt6_extract_metatypes() to set its output variable in the parent scope (it was previously setting it erroneously in the local scope). Some functions had code paths that would not set output variables. This would allow situations where if the variables had an initial value set by a higher up parent scope, the output variable would still have that value in the caller's scope upon return. That could be misleading, so fix these code paths to explicitly set the output variable to an empty string instead. Task-number: QTBUG-96121 Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: I291775813f025cabdccd4372ac077cdfd3ec090e Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-09-06 01:18:06 +00:00
cmake_parse_arguments(PARSE_ARGV 1 arg "" "OUTPUT_TARGETS" "")
if(arg_OUTPUT_TARGETS)
set(${arg_OUTPUT_TARGETS} ${${arg_OUTPUT_TARGETS}} PARENT_SCOPE)
endif()
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
CMake: Add qt6_add_plugin public API This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-21 11:28:57 +00:00
endif()
CMake: Enable default usage of utf8 sources for Qt consumers And enable the same default when building Qt itself (it's implicit). Allow opting out on a target-by-target basis, by using the public qt_disable_utf8_sources() API call. Change-Id: Ifc19a744d57b96b1c74a6926a0c6628c2a820464 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-12 12:57:23 +00:00
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 10:35:18 +00:00
# Creates a library by forwarding arguments to add_library, applies some Qt naming file name naming
# conventions and ensures the execution of Qt specific finalizers.
function(qt6_add_library target)
cmake_parse_arguments(PARSE_ARGV 1 arg "MANUAL_FINALIZATION" "" "")
_qt_internal_add_library("${target}" ${arg_UNPARSED_ARGUMENTS})
if(arg_MANUAL_FINALIZATION)
# Caller says they will call qt6_finalize_target() themselves later
return()
endif()
# Defer the finalization if we can. When the caller's project requires
# CMake 3.19 or later, this makes the calls to this function concise while
# still allowing target property modification before finalization.
if(CMAKE_VERSION VERSION_GREATER_EQUAL 3.19)
# Need to wrap in an EVAL CODE or else ${target} won't be evaluated
# due to special behavior of cmake_language() argument handling
cmake_language(EVAL CODE "cmake_language(DEFER CALL qt6_finalize_target ${target})")
else()
set_target_properties("${target}" PROPERTIES _qt_is_immediately_finalized TRUE)
qt6_finalize_target("${target}")
endif()
endfunction()
# Creates a library target by forwarding the arguments to add_library.
#
# Applies some Qt specific behaviors:
# - If no type option is specified, rather than defaulting to STATIC it defaults to STATIC or SHARED
# depending on the Qt configuration.
# - Applies Qt specific prefixes and suffixes to file names depending on platform.
function(_qt_internal_add_library target)
set(opt_args
STATIC
SHARED
MODULE
INTERFACE
OBJECT
)
set(single_args "")
set(multi_args "")
cmake_parse_arguments(PARSE_ARGV 1 arg "${opt_args}" "${single_args}" "${multi_args}")
set(option_type_count 0)
if(arg_STATIC)
set(type_to_create STATIC)
math(EXPR option_type_count "${option_type_count}+1")
elseif(arg_SHARED)
set(type_to_create SHARED)
math(EXPR option_type_count "${option_type_count}+1")
elseif(arg_MODULE)
set(type_to_create MODULE)
math(EXPR option_type_count "${option_type_count}+1")
elseif(arg_INTERFACE)
set(type_to_create INTERFACE)
math(EXPR option_type_count "${option_type_count}+1")
elseif(arg_OBJECT)
set(type_to_create OBJECT)
math(EXPR option_type_count "${option_type_count}+1")
endif()
if(option_type_count GREATER 1)
message(FATAL_ERROR
"Multiple type options were given. Only one should be used."
)
endif()
# If no explicit type option is set, default to the flavor of the Qt build.
# This in contrast to CMake which defaults to STATIC.
if(NOT arg_STATIC AND NOT arg_SHARED AND NOT arg_MODULE AND NOT arg_INTERFACE
AND NOT arg_OBJECT)
if(QT6_IS_SHARED_LIBS_BUILD)
set(type_to_create SHARED)
else()
set(type_to_create STATIC)
endif()
endif()
add_library(${target} ${type_to_create} ${arg_UNPARSED_ARGUMENTS})
Use correct MSVC runtime library for targets created by qt_add_*() Use _qt_internal_set_up_static_runtime_library() to set correct MSVC runtime library for targets created by qt_add_executable(), qt_add_library(), qt_add_plugin() and qt_add_big_resources(), to bring convenience to user projects. Pick-to: 6.2 Change-Id: Ia49f1e90989c464820824be3e1eef3df1351cdcf Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-07-29 09:53:03 +00:00
_qt_internal_set_up_static_runtime_library(${target})
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 10:35:18 +00:00
CMake: Don't apply invalid infixes to INTERFACE libraries And object libraries. Setting properties like IMPORT_SUFFIX on them doesn't make sense and can cause configuration issues. Amends 1bd408d6f7eac7908c77a0129e0173c280fce55b Change-Id: Ie91d1fbc7ba130816854d50c5b00ef793e4bad1f Reviewed-by: Martin Storsjö <martin@martin.st> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-26 09:27:11 +00:00
if(NOT type_to_create STREQUAL "INTERFACE" AND NOT type_to_create STREQUAL "OBJECT")
_qt_internal_apply_win_prefix_and_suffix("${target}")
endif()
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 10:35:18 +00:00
if(arg_MODULE AND APPLE)
# CMake defaults to using .so extensions for loadable modules, aka plugins,
# but Qt plugins are actually suffixed with .dylib.
set_property(TARGET "${target}" PROPERTY SUFFIX ".dylib")
endif()
if(ANDROID)
qt6_android_apply_arch_suffix("${target}")
endif()
endfunction()
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_add_library)
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 10:35:18 +00:00
qt6_add_library(${ARGV})
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
CMake: Introduce a public qt_add_library function Internally it uses a new _qt_internal_add_library function (similar how we have qt_add_executable and _qt_internal_add_executable) as well as finalizer code line the executable case. _qt_internal_add_library forwards arguments to add_library with some Qt specific adjustments to the selected default target type (based on whether Qt is configured as static or shared). The new _qt_internal_add_library is now used in qt_add_plugin as well as some internal library creating functions like qt_internal_add_module. This reduces some duplication of file name adjustments across functions and creates a central point for creation of Qt-like libraries (for some definition of Qt-like). Change-Id: Id9a31fe6bf278c8c3bb1e61e00a9febf7f1a2664 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-05-19 10:35:18 +00:00
endif()
CMake: Deduce install prefix of example in qt_internal_add_example We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:27:58 +00:00
# TODO: Remove once all repositories use qt_internal_add_example instead of add_subdirectory.
macro(_qt_internal_override_example_install_dir_to_dot)
# Set INSTALL_EXAMPLEDIR to ".".
# This overrides the install destination of unclean Qt example projects to install directly
# to CMAKE_INSTALL_PREFIX.
if(QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT)
set(INSTALL_EXAMPLEDIR ".")
CMake: Fix install destination of in-tree examples Previously we called _qt_internal_override_example_install_dir_to_dot in Qt6CoreConfigExtras.cmake as part of a find_package(Qt6 COMPONENTS Core) call, and we assumed that the Extras file would always be included in each example project. But our package dependencies handling code skips calling find_package(Qt6Core) if Qt6Core_FOUND is already set to TRUE, which will definitely happen due to root-scope find_package calls when configuring other repos. That means we wouldn't override INSTALL_EXAMPLEDIR to "." and the install destination would end up being something like ${CMAKE_INSTALL_PREFIX}/example_relative_path/example_relative_path aka a double nested path. Make sure we call the _qt_internal_override_example_install_dir_to_dot function in Qt6ConfigConfig.cmake in addition to Qt6CoreConfig.cmake. That way, even if Qt6Core is skipped during dependency resolution, it's still handled by the Qt6 package itself. Because the function is defined in the Core package, guard the call with an if(COMMAND) and only call the function if it wasn't previously called within the current or ancestor scopes. Amends ac4a913f333561803003650817de453f43be924d Pick-to: 6.2 6.3 6.4 Fixes: QTBUG-102879 Change-Id: Id47e3ce06faec6d156ae1473942dae0f9b90cb46 Reviewed-by: Christophe Giboudeaux <christophe@krop.fr> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-26 13:51:02 +00:00
set(_qt_internal_example_dir_set_to_dot TRUE)
CMake: Deduce install prefix of example in qt_internal_add_example We want to get rid of the INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR code in each example project. This was an internal workaround to ensure examples are installed into a relative path somewhere under $qt_prefix/examples and not in $qt_prefix/bin or similar. To achieve that we do two things. First, deduce the install prefix for each example in the implementation of qt_internal_add_example (our add_subdirectory wrapper) and assign it to CMAKE_INSTALL_PREFIX before calling add_subdirectory. We need to make sure to remove the default value of CMAKE_INSTALL_PREFIX in the generated cmake_install.cmake file. Second, we set an internal variable called QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT before the add_subdirectory call, which will be checked whenever find_package(Qt6Core) is called in an example project. If the variable is set, the INSTALL_EXAMPLEDIR var is set to "." in the scope of where Qt6Core is found. This ensures that the hardcoded INSTALL_EXAMPLEDIR values in our example projects are changed to ".". With both changes, our example project install(TARGET DESTINATION) calls will now install to "${CMAKE_INSTALL_PREFIX}/examples/${example_relative_dir}/." Once all repositories are updated to use qt_internal_add_example instead of add_subdirectory, we can get rid of the QT_INTERNAL_SET_EXAMPLE_INSTALL_DIR_TO_DOT workaround. For repositories that still don't use qt_internal_add_example, the install prefix rewriting will not happen, but the examples will still be installed to the proper place because they use their own hardcoded INSTALL_EXAMPLEDIR value. Amends d97fd7af2bc5c89a0ad9e5fac080041b78d01179 Pick-to: 6.2 6.3 Task-number: QTBUG-96232 Task-number: QTBUG-98545 Change-Id: I78c118e10c41b519c570c7d87529afd15aeed900 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2021-12-14 15:27:58 +00:00
endif()
endmacro()
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
function(qt6_allow_non_utf8_sources target)
CMake: Enable default usage of utf8 sources for Qt consumers And enable the same default when building Qt itself (it's implicit). Allow opting out on a target-by-target basis, by using the public qt_disable_utf8_sources() API call. Change-Id: Ifc19a744d57b96b1c74a6926a0c6628c2a820464 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-12 12:57:23 +00:00
set_target_properties("${target}" PROPERTIES QT_NO_UTF8_SOURCE TRUE)
endfunction()
CMake: Don't use std=gnu++11 when building Qt internal targets The logic is a bit involved in qmake. The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies to qt modules, qt plugins, qml plugins, qt helper libs, winmain and qt_apps, qt_tools, but NOT tests (which is important because the tests on Windows MinGW fail to build without the GNU extensions). Then default_post.prf checks for the strict_c++ value and either uses the strict or non-strict C++ standard flags. default_post.prf is loaded for all qmake projects, not just the Qt internal ones. Now CMake doesn't provide a transitive based option to disable C++ GNU extensions with a mechanism similar to target_compile_features. It only provides the CXX_EXTENSIONS property and it's associated CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a directory scope, because that is too coarse grained. So we rely on setting the property via a function in every relevant qt_add_<target> function. Now the naming of the function is weird. We name the function as qt_internal_<...>, because it's not meant to be used by Qt users. We prepend an underscore to the name because we need to place it in Qt6CoreMacros, so that the function can be called by qt_add_qml_module which IS a public function. That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 + CMake we decided to make qt_add_qml_module() as public API. Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-06-04 09:29:00 +00:00
CMake: Clean up the public API a bit Add some missing versionless functions. Rename some functions that are not meant to be public API, and their usages. Task-number: QTBUG-86827 Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-01 08:58:02 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_allow_non_utf8_sources)
CMake: Rename some public API functions Some of them have a different (hopefully better) name now. Some are marked as Technical Preview. Some are renamed to be internal. Marking add_qt_gui_executable as TP with the intention to un-TP it after we rename it and change its behavior as discussed in the API review meeting. Additional changes to add_qt_gui_executable and qt6_add_resources have been filed as separate tasks that will be worked on separately. See comments on PS1 for details. Task-number: QTBUG-86827 Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-14 11:20:55 +00:00
qt6_allow_non_utf8_sources(${ARGV})
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
CMake: Clean up the public API a bit Add some missing versionless functions. Rename some functions that are not meant to be public API, and their usages. Task-number: QTBUG-86827 Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-10-01 08:58:02 +00:00
endif()
CMake: Don't use std=gnu++11 when building Qt internal targets The logic is a bit involved in qmake. The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies to qt modules, qt plugins, qml plugins, qt helper libs, winmain and qt_apps, qt_tools, but NOT tests (which is important because the tests on Windows MinGW fail to build without the GNU extensions). Then default_post.prf checks for the strict_c++ value and either uses the strict or non-strict C++ standard flags. default_post.prf is loaded for all qmake projects, not just the Qt internal ones. Now CMake doesn't provide a transitive based option to disable C++ GNU extensions with a mechanism similar to target_compile_features. It only provides the CXX_EXTENSIONS property and it's associated CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a directory scope, because that is too coarse grained. So we rely on setting the property via a function in every relevant qt_add_<target> function. Now the naming of the function is weird. We name the function as qt_internal_<...>, because it's not meant to be used by Qt users. We prepend an underscore to the name because we need to place it in Qt6CoreMacros, so that the function can be called by qt_add_qml_module which IS a public function. That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 + CMake we decided to make qt_add_qml_module() as public API. Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-06-04 09:29:00 +00:00
function(_qt_internal_apply_strict_cpp target)
# Disable C, Obj-C and C++ GNU extensions aka no "-std=gnu++11".
# Similar to mkspecs/features/default_post.prf's CONFIG += strict_cpp.
# Allow opt-out via variable.
if(NOT QT_ENABLE_CXX_EXTENSIONS)
get_target_property(target_type "${target}" TYPE)
if(NOT target_type STREQUAL "INTERFACE_LIBRARY")
set_target_properties("${target}" PROPERTIES
CXX_EXTENSIONS OFF
C_EXTENSIONS OFF
OBJC_EXTENSIONS OFF
OBJCXX_EXTENSIONS OFF)
endif()
endif()
endfunction()
Compile resource objects of the static library using same options Introduce the function that appends the specified properties of the one target to the another. It's possible to copy the standard property set that affects a compilation only or pass some specific properties that need to copy. You may also control the visibily of properties that need to copy by passing the PRIVATE_ONLY or INTERFACE_ONLY option. The function is used to compile the resource targets with the same property set as the main target. Also link the Qt::Platform interface library to collect platform specific properties. Pick-to: 6.1 Change-Id: I727fd0a4bc52c4f5128f28ce796d7a5f3005bb30 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-23 14:23:36 +00:00
Add _qt_internal_wrap_tool_command to replace QT_TOOL_PATH_SETUP_COMMAND QT_TOOL_PATH_SETUP_COMMAND is used in COMMAND list when call add_custom_command/add_custom_target. This is necessary to setup the necessary environment for the tool to run correctly. This approach is weak according to CMake documentation: "If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script." This change introduces the _qt_internal_wrap_tool_command function that uses a wrapping script that setups necessary environment for the tool and runs it in a single shell. The script is generated by the _qt_generate_tool_command_wrapper function. Change-Id: Id5270b91619b607a0c1e3a19b8c706edec43f388 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-15 10:35:46 +00:00
# Wraps a tool command with a script that contains the necessary environment for the tool to run
# correctly.
# _qt_internal_wrap_tool_command(var <SET|APPEND> <command> [args...])
# Arguments:
# APPEND Selects the 'append' mode for the out_variable argument.
# SET Selects the 'set' mode for the out_variable argument.
function(_qt_internal_wrap_tool_command out_variable action)
set(append FALSE)
if(action STREQUAL "APPEND")
set(append TRUE)
elseif(NOT action STREQUAL "SET")
message(FATAL_ERROR "Invalid action specified ${action}. Supported actions: SET, APPEND")
endif()
set(cmd COMMAND ${QT_TOOL_COMMAND_WRAPPER_PATH} ${ARGN})
if(append)
list(APPEND ${out_variable} ${cmd})
else()
set(${out_variable} ${cmd})
endif()
set(${out_variable} "${${out_variable}}" PARENT_SCOPE)
endfunction()
Compile resource objects of the static library using same options Introduce the function that appends the specified properties of the one target to the another. It's possible to copy the standard property set that affects a compilation only or pass some specific properties that need to copy. You may also control the visibily of properties that need to copy by passing the PRIVATE_ONLY or INTERFACE_ONLY option. The function is used to compile the resource targets with the same property set as the main target. Also link the Qt::Platform interface library to collect platform specific properties. Pick-to: 6.1 Change-Id: I727fd0a4bc52c4f5128f28ce796d7a5f3005bb30 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-23 14:23:36 +00:00
# Copies properties of the dependency to the target.
# Arguments:
# PROPERTIES list of properties to copy. If not specified the following properties are copied
# by default: INCLUDE_DIRECTORIES SYSTEM_INCLUDE_DIRECTORIES COMPILE_DEFINITIONS
# COMPILE_OPTIONS COMPILE_FEATURES
# PRIVATE_ONLY copy only private properties (without INTERFACE analogues). Optional.
# INTERFACE_ONLY copy only interface properties (without non-prefixed analogues). Optional.
# Note: Not all properties have INTERFACE properties analogues.
# See https://cmake.org/cmake/help/latest/prop_tgt/EXPORT_PROPERTIES.html for details.
#
# PRIVATE_ONLY and INTERFACE_ONLY in the same call are not allowed. Omit these options to copy
# both sets.
function(_qt_internal_copy_dependency_properties target dependency)
cmake_parse_arguments(arg "INTERFACE_ONLY;PRIVATE_ONLY" "" "PROPERTIES" ${ARGN})
if(arg_PRIVATE_ONLY AND arg_INTERFACE_ONLY)
message("Both PRIVATE_ONLY and INTERFACE_ONLY options are set.\
Please use _qt_internal_copy_dependency_properties without these options to copy a set of
properties of both types."
)
endif()
if(arg_PROPERTIES)
set(common_props_to_set ${arg_PROPERTIES})
else()
set(common_props_to_set
INCLUDE_DIRECTORIES SYSTEM_INCLUDE_DIRECTORIES
COMPILE_DEFINITIONS COMPILE_OPTIONS
COMPILE_FEATURES
)
endif()
set(props_to_set "")
if(NOT arg_INTERFACE_ONLY)
set(props_to_set ${common_props_to_set})
endif()
if(NOT arg_PRIVATE_ONLY)
list(TRANSFORM common_props_to_set PREPEND INTERFACE_
OUTPUT_VARIABLE interface_properties)
list(APPEND props_to_set ${interface_properties})
endif()
foreach(prop ${props_to_set})
set_property(TARGET
"${target}" APPEND PROPERTY
${prop} "$<TARGET_PROPERTY:${dependency},${prop}>"
)
endforeach()
endfunction()
Enable UNICODE for all Qt targets and Qt consumers by default After discussion we decided to opt-out the UNICODE definintion behavior. To disable UNICODE in user projects the qt6_disable_unicode_defines function could be used. Amends 5b64e5950cf984abb7d47e0802bcb4b5a21e06fa [ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on WIN32 platforms by default for all cmake projects to reflect the qmake behavior. Use qt6_disable_unicode_defines function to disable the default unicode definitions. Pick-to: 6.1 Fixes: QTBUG-93895 Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-21 08:22:04 +00:00
function(qt6_disable_unicode_defines target)
set_target_properties(${target} PROPERTIES QT_NO_UNICODE_DEFINES TRUE)
endfunction()
Support deploying of libraries from a build tree when building android apk If the project consists of an executable and multiple libraries that are linked to the executable, currently you need to specify them manually using QT_ANDROID_EXTRA_LIBS target property. This automates deploying of the libraries that are a part of the project build tree. _qt_internal_collect_target_apk_dependencies collects all the known non-imported shared libraries from the project build tree. When running androiddeployqt we specify extra library directories that point to the collected library locations in build tree, to help androiddeployqt resolve shared libraries that are build as a part of the project. The described procedure is running automatically if CMake version is greater than or equal to 3.18 is. For the CMake versions less than 3.18 users need to call a new public qt_finalize_project function at the end of project's top-level CMakeLists.txt Task-number: QTBUG-94714 Change-Id: I400ca4e49e940cfc25ae90d65372e79825bee55a Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-08-17 14:25:03 +00:00
# Finalizer function for the top-level user projects.
#
# This function is currently in Technical Preview.
# Its signature and behavior might change.
function(qt6_finalize_project)
if(NOT CMAKE_CURRENT_SOURCE_DIR STREQUAL CMAKE_SOURCE_DIR)
message("qt6_finalize_project is called not in the top-level CMakeLists.txt.")
endif()
if(ANDROID)
Collect the apk dependencies regardless of target _qt_internal_collect_target_apk_dependencies function is common for all targets, but its signature was telling that it's target-specific. This also causes an issue when we had more than one target in tree that produce apk, since only first target got the property after respective finalizer was executed. This change generalize the function and uses _qt_internal_apk_dependencies target to store the extra library directories from the build tree. _qt_internal_add_android_deployment_list_property signature is also changed to support reading values from multiple lists of multiple targets. Amends d20f4ae706559fb7de8db9dd4845f7ce3936061a Pick-to: 6.3 Change-Id: I5b40fa96a0eb73348c0029e2b13c63a9465cb520 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-12-27 16:45:39 +00:00
_qt_internal_collect_apk_dependencies()
Support deploying of libraries from a build tree when building android apk If the project consists of an executable and multiple libraries that are linked to the executable, currently you need to specify them manually using QT_ANDROID_EXTRA_LIBS target property. This automates deploying of the libraries that are a part of the project build tree. _qt_internal_collect_target_apk_dependencies collects all the known non-imported shared libraries from the project build tree. When running androiddeployqt we specify extra library directories that point to the collected library locations in build tree, to help androiddeployqt resolve shared libraries that are build as a part of the project. The described procedure is running automatically if CMake version is greater than or equal to 3.18 is. For the CMake versions less than 3.18 users need to call a new public qt_finalize_project function at the end of project's top-level CMakeLists.txt Task-number: QTBUG-94714 Change-Id: I400ca4e49e940cfc25ae90d65372e79825bee55a Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-08-17 14:25:03 +00:00
endif()
endfunction()
Enable UNICODE for all Qt targets and Qt consumers by default After discussion we decided to opt-out the UNICODE definintion behavior. To disable UNICODE in user projects the qt6_disable_unicode_defines function could be used. Amends 5b64e5950cf984abb7d47e0802bcb4b5a21e06fa [ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on WIN32 platforms by default for all cmake projects to reflect the qmake behavior. Use qt6_disable_unicode_defines function to disable the default unicode definitions. Pick-to: 6.1 Fixes: QTBUG-93895 Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-21 08:22:04 +00:00
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
Support deploying of libraries from a build tree when building android apk If the project consists of an executable and multiple libraries that are linked to the executable, currently you need to specify them manually using QT_ANDROID_EXTRA_LIBS target property. This automates deploying of the libraries that are a part of the project build tree. _qt_internal_collect_target_apk_dependencies collects all the known non-imported shared libraries from the project build tree. When running androiddeployqt we specify extra library directories that point to the collected library locations in build tree, to help androiddeployqt resolve shared libraries that are build as a part of the project. The described procedure is running automatically if CMake version is greater than or equal to 3.18 is. For the CMake versions less than 3.18 users need to call a new public qt_finalize_project function at the end of project's top-level CMakeLists.txt Task-number: QTBUG-94714 Change-Id: I400ca4e49e940cfc25ae90d65372e79825bee55a Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2021-08-17 14:25:03 +00:00
function(qt_finalize_project)
if(QT_DEFAULT_MAJOR_VERSION EQUAL 6)
qt6_finalize_project()
else()
message(FATAL_ERROR "qt_finalize_project() is only available in Qt 6.")
endif()
endfunction()
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
function(qt_disable_unicode_defines)
Enable UNICODE for all Qt targets and Qt consumers by default After discussion we decided to opt-out the UNICODE definintion behavior. To disable UNICODE in user projects the qt6_disable_unicode_defines function could be used. Amends 5b64e5950cf984abb7d47e0802bcb4b5a21e06fa [ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on WIN32 platforms by default for all cmake projects to reflect the qmake behavior. Use qt6_disable_unicode_defines function to disable the default unicode definitions. Pick-to: 6.1 Fixes: QTBUG-93895 Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-21 08:22:04 +00:00
qt6_disable_unicode_defines(${ARGV})
Revert "Ensure versionless wrappers do not introduce a new variable scope" This reverts commit 08180e76e6116f0ef66476ca00b2b676b3aa50da. Macros add another level of escaping that functions do not. The conversion of the versionless wrappers to macros may alter the behavior, so revert that change. Task-number: QTBUG-96219 Pick-to: 6.2 Change-Id: Ic5dcff3081123d957888584ba1d76ae0580d9083 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-08-31 05:56:00 +00:00
endfunction()
Enable UNICODE for all Qt targets and Qt consumers by default After discussion we decided to opt-out the UNICODE definintion behavior. To disable UNICODE in user projects the qt6_disable_unicode_defines function could be used. Amends 5b64e5950cf984abb7d47e0802bcb4b5a21e06fa [ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on WIN32 platforms by default for all cmake projects to reflect the qmake behavior. Use qt6_disable_unicode_defines function to disable the default unicode definitions. Pick-to: 6.1 Fixes: QTBUG-93895 Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-21 08:22:04 +00:00
endif()
Add CMake deployment support Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-29 23:29:34 +00:00
function(_qt_internal_get_deploy_impl_dir var)
set(${var} "${CMAKE_BINARY_DIR}/.qt" PARENT_SCOPE)
endfunction()
function(_qt_internal_add_deploy_support deploy_support_file)
get_filename_component(deploy_support_file "${deploy_support_file}" REALPATH)
set(target ${QT_CMAKE_EXPORT_NAMESPACE}::Core)
get_target_property(aliased_target ${target} ALIASED_TARGET)
if(aliased_target)
set(target ${aliased_target})
endif()
get_property(scripts TARGET ${target} PROPERTY _qt_deploy_support_files)
if(NOT "${deploy_support_file}" IN_LIST scripts)
set_property(TARGET ${target} APPEND PROPERTY
_qt_deploy_support_files "${deploy_support_file}"
)
endif()
endfunction()
# Sets up the commands for use at install/deploy time
function(_qt_internal_setup_deploy_support)
get_property(cmake_role GLOBAL PROPERTY CMAKE_ROLE)
if(NOT cmake_role STREQUAL "PROJECT")
return()
endif()
# Always set QT_DEPLOY_SUPPORT in the caller's scope, even if we've generated
# the deploy support file in a previous call. The project may be calling
# find_package() from sibling directories with separate variable scopes.
_qt_internal_get_deploy_impl_dir(deploy_impl_dir)
get_cmake_property(is_multi_config GENERATOR_IS_MULTI_CONFIG)
if(is_multi_config)
set(QT_DEPLOY_SUPPORT "${deploy_impl_dir}/QtDeploySupport-$<CONFIG>.cmake")
else()
set(QT_DEPLOY_SUPPORT "${deploy_impl_dir}/QtDeploySupport.cmake")
endif()
set(QT_DEPLOY_SUPPORT "${QT_DEPLOY_SUPPORT}" PARENT_SCOPE)
get_property(have_generated_file GLOBAL PROPERTY _qt_have_generated_deploy_support)
if(have_generated_file)
return()
endif()
set_property(GLOBAL PROPERTY _qt_have_generated_deploy_support TRUE)
include(GNUInstallDirs)
set(target ${QT_CMAKE_EXPORT_NAMESPACE}::Core)
get_target_property(aliased_target ${target} ALIASED_TARGET)
if(aliased_target)
set(target ${aliased_target})
endif()
# Make sure to look under the Qt bin dir with find_program, rather than randomly picking up
# a deployqt tool in the system.
# QT6_INSTALL_PREFIX is not set during Qt build, so add the hints conditionally.
set(find_program_hints)
if(QT6_INSTALL_PREFIX)
set(find_program_hints HINTS ${QT6_INSTALL_PREFIX}/${QT6_INSTALL_BINS})
endif()
# In the generator expression logic below, we need safe_target_file because
# CMake evaluates expressions in both the TRUE and FALSE branches of $<IF:...>.
# We still need a target to give to $<TARGET_FILE:...> when we have no deploy
# tool, so we cannot use something like $<TARGET_FILE:macdeployqt> directly.
if(APPLE AND NOT IOS)
find_program(MACDEPLOYQT_EXECUTABLE macdeployqt
${find_program_hints})
set(fallback "$<$<BOOL:${MACDEPLOYQT_EXECUTABLE}>:${MACDEPLOYQT_EXECUTABLE}>")
set(target_if_exists "$<TARGET_NAME_IF_EXISTS:${QT_CMAKE_EXPORT_NAMESPACE}::macdeployqt>")
set(have_deploy_tool "$<BOOL:${target_if_exists}>")
set(safe_target_file
"$<TARGET_FILE:$<IF:${have_deploy_tool},${target_if_exists},${target}>>")
set(__QT_DEPLOY_TOOL "$<IF:${have_deploy_tool},${safe_target_file},${fallback}>")
elseif(WIN32)
find_program(WINDEPLOYQT_EXECUTABLE windeployqt
${find_program_hints})
set(fallback "$<$<BOOL:${WINDEPLOYQT_EXECUTABLE}>:${WINDEPLOYQT_EXECUTABLE}>")
set(target_if_exists "$<TARGET_NAME_IF_EXISTS:${QT_CMAKE_EXPORT_NAMESPACE}::windeployqt>")
set(have_deploy_tool "$<BOOL:${target_if_exists}>")
set(safe_target_file
"$<TARGET_FILE:$<IF:${have_deploy_tool},${target_if_exists},${target}>>")
set(__QT_DEPLOY_TOOL "$<IF:${have_deploy_tool},${safe_target_file},${fallback}>")
else()
# Android is handled as a build target, not via this install-based approach.
# Therefore, we don't consider androiddeployqt here.
set(__QT_DEPLOY_TOOL "")
endif()
_qt_internal_add_deploy_support("${CMAKE_CURRENT_LIST_DIR}/Qt6CoreDeploySupport.cmake")
file(GENERATE OUTPUT "${QT_DEPLOY_SUPPORT}" CONTENT
"cmake_minimum_required(VERSION 3.16...3.21)
# These are part of the public API. Projects should use them to provide a
# consistent set of prefix-relative destinations.
if(NOT QT_DEPLOY_BIN_DIR)
set(QT_DEPLOY_BIN_DIR \"${CMAKE_INSTALL_BINDIR}\")
endif()
if(NOT QT_DEPLOY_LIB_DIR)
set(QT_DEPLOY_LIB_DIR \"${CMAKE_INSTALL_LIBDIR}\")
endif()
if(NOT QT_DEPLOY_PLUGINS_DIR)
set(QT_DEPLOY_PLUGINS_DIR \"plugins\")
endif()
if(NOT QT_DEPLOY_QML_DIR)
set(QT_DEPLOY_QML_DIR \"qml\")
endif()
if(NOT QT_DEPLOY_PREFIX)
set(QT_DEPLOY_PREFIX \"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}\")
endif()
if(QT_DEPLOY_PREFIX STREQUAL \"\")
set(QT_DEPLOY_PREFIX .)
endif()
# These are internal implementation details. They may be removed at any time.
set(__QT_DEPLOY_SYSTEM_NAME \"${CMAKE_SYSTEM_NAME}\")
set(__QT_DEPLOY_IS_SHARED_LIBS_BUILD \"${QT6_IS_SHARED_LIBS_BUILD}\")
set(__QT_DEPLOY_TOOL \"${__QT_DEPLOY_TOOL}\")
set(__QT_DEPLOY_IMPL_DIR \"${deploy_impl_dir}\")
set(__QT_DEPLOY_VERBOSE \"${QT_ENABLE_VERBOSE_DEPLOYMENT}\")
set(__QT_CMAKE_EXPORT_NAMESPACE \"${QT_CMAKE_EXPORT_NAMESPACE}\")
set(__QT_DEPLOY_GENERATOR_IS_MULTI_CONFIG \"${is_multi_config}\")
set(__QT_DEPLOY_ACTIVE_CONFIG \"$<CONFIG>\")
CMake: Clean up qt_deploy_qt_conf for 6.3 Ensure both versioned and versionless functions are available. Document that the first argument should be an absolute path and check that in the code. Move the low-level warning to the top, after the TP message. Use a few more options in the doc snippet. Mention what the default values are. Pick-to: 6.3 Fixes: QTBUG-100922 Change-Id: I0d852733e51750f4c8f15721b707cb1d27dfee9a Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-02-17 14:19:11 +00:00
set(__QT_NO_CREATE_VERSIONLESS_FUNCTIONS \"${QT_NO_CREATE_VERSIONLESS_FUNCTIONS}\")
set(__QT_DEFAULT_MAJOR_VERSION \"${QT_DEFAULT_MAJOR_VERSION}\")
Add CMake deployment support Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-29 23:29:34 +00:00
# Define the CMake commands to be made available during deployment.
set(__qt_deploy_support_files
\"$<JOIN:$<TARGET_PROPERTY:${target},_qt_deploy_support_files>,\"
\">\"
)
foreach(__qt_deploy_support_file IN LISTS __qt_deploy_support_files)
include(\"\${__qt_deploy_support_file}\")
endforeach()
unset(__qt_deploy_support_file)
unset(__qt_deploy_support_files)
")
endfunction()
# Note this needs to be a macro because it sets variables intended for the
# calling scope.
macro(qt6_standard_project_setup)
# A parent project might want to prevent child projects pulled in with
# add_subdirectory() from changing the parent's preferred arrangement.
# They can set this variable to true to effectively disable this function.
if(NOT QT_NO_STANDARD_PROJECT_SETUP)
# All changes below this point should not result in a change to an
# existing value, except for CMAKE_INSTALL_RPATH which may append new
# values (but no duplicates).
# Use standard install locations, provided by GNUInstallDirs. All
# platforms should have this included so that we know the
# CMAKE_INSTALL_xxxDIR variables will be set.
include(GNUInstallDirs)
if(WIN32)
# Windows has no RPATH support, so we need all non-plugin DLLs in
# the same directory as application executables if we want to be
# able to run them without having to augment the PATH environment
# variable. Don't discard an existing value in case the project has
# already set this to somewhere else. Our setting is somewhat
# opinionated, so make it easy for projects to choose something else.
if(NOT CMAKE_RUNTIME_OUTPUT_DIRECTORY)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
endif()
elseif(NOT APPLE)
# Apart from Windows and Apple, most other platforms support RPATH
# and $ORIGIN. Make executables and non-static libraries use an
# install RPATH that allows them to find library dependencies if the
# project installs things to the directories defined by the
# CMAKE_INSTALL_xxxDIR variables (which is what CMake's defaults
# are based on).
file(RELATIVE_PATH __qt_relDir
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_INSTALL_BINDIR}
${CMAKE_CURRENT_BINARY_DIR}/${CMAKE_INSTALL_LIBDIR}
)
list(APPEND CMAKE_INSTALL_RPATH $ORIGIN $ORIGIN/${__qt_relDir})
list(REMOVE_DUPLICATES CMAKE_INSTALL_RPATH)
unset(__qt_reldir)
endif()
# Turn these on by default, unless they are already set. Projects can
# always turn off any they really don't want after we return.
qt6_standard_project_setup: Don't enable AUTORCC We discourage using AUTORCC, so don't make it the default for our "standard project setup". Pick-to: 6.3 Task-number: QTBUG-87643 Task-number: QTBUG-100209 Change-Id: I2715ec561266bfed5ea4ac7722ab1f1c8b982788 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-01-26 09:20:27 +00:00
foreach(auto_set IN ITEMS MOC UIC)
Add CMake deployment support Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-29 23:29:34 +00:00
if(NOT DEFINED CMAKE_AUTO${auto_set})
set(CMAKE_AUTO${auto_set} TRUE)
endif()
endforeach()
endif()
endmacro()
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
macro(qt_standard_project_setup)
qt6_standard_project_setup(${ARGV})
endmacro()
endif()
CMake: Mark the new deployment API as being in Technical Preview Amends 22c92f39670d0376478cc2e73a17307508f86692 Task-number: QTBUG-98545 Change-Id: Ifaa7e4884f0eb1caa6d3d4906a2701f8fa5e43c2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-12-09 11:23:27 +00:00
# This function is currently in Technical Preview.
# Its signature and behavior might change.
Add CMake deployment support Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-29 23:29:34 +00:00
function(qt6_generate_deploy_app_script)
# We use a TARGET keyword option instead of taking the target as the first
# positional argument. This is to keep open the possibility of deploying
# an app for which we don't have a target (e.g. an application from a
# third party project that the caller may want to include in their own
# package). We would add an EXECUTABLE keyword for that, which would be
# mutually exclusive with the TARGET keyword.
set(no_value_options
NO_UNSUPPORTED_PLATFORM_ERROR
)
set(single_value_options
TARGET
FILENAME_VARIABLE
)
set(multi_value_options "")
cmake_parse_arguments(PARSE_ARGV 0 arg
"${no_value_options}" "${single_value_options}" "${multi_value_options}"
)
if(arg_UNPARSED_ARGUMENTS)
message(FATAL_ERROR "Unexpected arguments: ${arg_UNPARSED_ARGUMENTS}")
endif()
if(NOT arg_TARGET)
message(FATAL_ERROR "TARGET must be specified")
endif()
if(NOT arg_FILENAME_VARIABLE)
message(FATAL_ERROR "FILENAME_VARIABLE must be specified")
endif()
# Create a file name that will be unique for this target and the combination
# of arguments passed to this command. This allows the project to call us
# multiple times with different arguments for the same target (e.g. to
# create deployment scripts for different scenarios).
string(MAKE_C_IDENTIFIER "${arg_TARGET}" target_id)
string(SHA1 args_hash "${ARGV}")
string(SUBSTRING "${args_hash}" 0 10 short_hash)
_qt_internal_get_deploy_impl_dir(deploy_impl_dir)
set(file_name "${deploy_impl_dir}/deploy_${target_id}_${short_hash}")
get_cmake_property(is_multi_config GENERATOR_IS_MULTI_CONFIG)
if(is_multi_config)
string(APPEND file_name "-$<CONFIG>")
endif()
set(${arg_FILENAME_VARIABLE} "${file_name}" PARENT_SCOPE)
if(QT6_IS_SHARED_LIBS_BUILD)
set(qt_build_type_string "shared Qt libs")
else()
set(qt_build_type_string "static Qt libs")
endif()
if(APPLE AND NOT IOS AND QT6_IS_SHARED_LIBS_BUILD)
# TODO: Handle non-bundle applications if possible.
get_target_property(is_bundle ${arg_TARGET} MACOSX_BUNDLE)
if(NOT is_bundle)
message(FATAL_ERROR
"Executable targets have to be app bundles to use this command "
"on Apple platforms."
)
endif()
file(GENERATE OUTPUT "${file_name}" CONTENT "
include(${QT_DEPLOY_SUPPORT})
CMake: Clean up qt_deploy_runtime_dependencies for 6.3 Ensure both versioned and versionless functions are available. Use the versioned function in the implementation of qt6_generate_deploy_app_script. Move the low-level warning to the top of the documentation page, after the TP message. Clarify documentation of the EXECUTABLE and ADDITIONAL_ options, that they take relative paths and can use generator expressions, but can't reference raw target names. Adjust documentation snippet to cover mac / windows cases. This mostly coincides with the internal implementation of qt_generate_deploy_app_script. Also adjust it to show case more options, like installation of a helper app and its dependencies. Output the working directory when executing the deploy tool. Remove the MACOS_BUNDLE option, it serves no good purpose at the moment, we already detect bundles by checking if the dir name has an '.app' suffix. Pick-to: 6.3 Fixes: QTBUG-100923 Change-Id: If7e5d65ce920eb69fd45f004aa4c5bad800c7ba9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-02-17 15:14:09 +00:00
qt6_deploy_runtime_dependencies(
Add CMake deployment support Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-29 23:29:34 +00:00
EXECUTABLE $<TARGET_FILE_NAME:${arg_TARGET}>.app
)
")
elseif(WIN32 AND QT6_IS_SHARED_LIBS_BUILD)
file(GENERATE OUTPUT "${file_name}" CONTENT "
include(${QT_DEPLOY_SUPPORT})
CMake: Clean up qt_deploy_runtime_dependencies for 6.3 Ensure both versioned and versionless functions are available. Use the versioned function in the implementation of qt6_generate_deploy_app_script. Move the low-level warning to the top of the documentation page, after the TP message. Clarify documentation of the EXECUTABLE and ADDITIONAL_ options, that they take relative paths and can use generator expressions, but can't reference raw target names. Adjust documentation snippet to cover mac / windows cases. This mostly coincides with the internal implementation of qt_generate_deploy_app_script. Also adjust it to show case more options, like installation of a helper app and its dependencies. Output the working directory when executing the deploy tool. Remove the MACOS_BUNDLE option, it serves no good purpose at the moment, we already detect bundles by checking if the dir name has an '.app' suffix. Pick-to: 6.3 Fixes: QTBUG-100923 Change-Id: If7e5d65ce920eb69fd45f004aa4c5bad800c7ba9 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-02-17 15:14:09 +00:00
qt6_deploy_runtime_dependencies(
CMake: Clean up qt_generate_deploy_app_script for 6.3 Mention in the docs that qt_generate_deploy_app_script does not currently support cross-build scenarios. Use the value of QT_DEPLOY_BIN_DIR instead of CMAKE_INSTALL_PREFIX in the qt_deploy_runtime_dependencies call done by qt6_generate_deploy_app_script. This matches what we say to do in the documentation of qt_deploy_runtime_dependencies. Pick-to: 6.3 Task-number: QTBUG-98545 Fixes: QTBUG-100921 Change-Id: Ie9bfddeaf503d3efe7a73b2e4148bbf0601d693e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-02-17 14:03:21 +00:00
EXECUTABLE \${QT_DEPLOY_BIN_DIR}/$<TARGET_FILE_NAME:${arg_TARGET}>
Add CMake deployment support Task-number: QTBUG-98545 Change-Id: I581c1173cdfc92c09fd2cf0bbe7ec6bc8d52b868 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-11-29 23:29:34 +00:00
GENERATE_QT_CONF
)")
elseif(NOT arg_NO_UNSUPPORTED_PLATFORM_ERROR AND NOT QT_INTERNAL_NO_UNSUPPORTED_PLATFORM_ERROR)
# Currently we don't deploy runtime dependencies if cross-compiling or using a static Qt.
# We also don't do it if targeting Linux, but we could provide an option to do
# so if we had a deploy tool or purely CMake-based deploy implementation.
# Error out by default unless the project opted out of the error.
# This provides us a migration path in the future without breaking compatibility promises.
message(FATAL_ERROR
"Support for installing runtime dependencies is not implemented for "
"this target platform (${CMAKE_SYSTEM_NAME}, ${qt_build_type_string})."
)
else()
file(GENERATE OUTPUT "${file_name}" CONTENT "
include(${QT_DEPLOY_SUPPORT})
_qt_internal_show_skip_runtime_deploy_message(\"${qt_build_type_string}\")
")
endif()
endfunction()
if(NOT QT_NO_CREATE_VERSIONLESS_FUNCTIONS)
macro(qt_generate_deploy_app_script)
qt6_generate_deploy_app_script(${ARGV})
endmacro()
endif()